IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > What are monitor models? > Monitor details models
Monitoring contexts
A monitoring context definition defines all of the data that should be collected about an entity (such as a process, customer order, or the stock level of an item in a warehouse) as the system is running.
Each of the runtime instances of a monitoring context ( monitoring context instances) use incoming events to monitor a particular (real or abstract) entity, such as a particular process execution, the state of a particular order, or the stock level of an item in a warehouse. They collect information which, individually or in combination, is useful for making business decisions. The information is extracted from the data carried by inbound events, and is held in metrics, counters, and stopwatches, which represent the business measures that a monitoring context collects.
A monitoring context can be thought of as a shadow image of an entity to be monitored, which is used to group the business measures associated with that entity. A monitoring context performs the following tasks:
- Subscribes to events reporting state changes of the entity
- Uses information extracted from these events to update the business measures describing the entity's observed state
Stated differently, Business Monitor captures events to keep shadow images of entities synchronized with their real or abstract counterparts, and to allow their observation on a business dashboard. These shadow images are called monitoring contexts because they provide a context, within Business Monitor, to receive and correlate events from the observed entity, to build up-to-date state information about it, and to detect business situations of the entity that might require action.
The monitor details model contains definitions of monitoring contexts. Business Monitor creates a different instance of a monitoring context definition for each instance of the corresponding observed entity.
For example, to monitor a network of ATM machines, you would create one monitoring context definition for ATM entities that would be instantiated as many times as there are ATMs to be monitored. The resulting monitoring contexts (the instances) are in one-one correspondence with the observed ATMs. Consequently, each monitoring context should contain a key to relate it to the corresponding instance. In the ATM example, this might be the ATM machine number. For a process execution, this key might be the process instance ID; for a purchase order, the order number; and for a warehouse item, a stock keeping unit (SKU) number. Keys can also have multiple parts: for example, if an airline wants to monitor flights, each flight might be identified by an airline code, flight number, and departure date.
Monitoring context creation typically occurs as a result of the first inbound event from the monitored entity. Termination occurs when the monitoring context instance or the entity has reached a final state.
For example, if the order that was being monitored has been fulfilled or the transaction being monitored with an ATM has been completed, the monitoring context instance representing that order or ATM transaction could be terminated. Some monitoring context instances, for example, one monitoring an ATM, might never be terminated. Monitoring contexts can form a hierarchy, and, when a monitoring context instance is terminated, any descendant context is terminated as well.
Monitoring context hierarchies
Monitoring context definitions can be nested to form hierarchies.
For example, you might want to track individual task instances within a given process instance. If a particular task can run more than once within a given process instance, you can monitor the task using a nested monitoring context to track each instance of the task separately. At run time, each instance of a nested monitoring context definition (or child context) must be subordinate to an instance of the nesting monitoring context definition (its parent context). In other words, the instances of nested monitoring context definitions form a tree structure.
The following two fundamental rules about control flow (as shown in the Monitoring Flow view) and data references (that is, references to data fields in expressions) apply to this tree structure and are enforced by the validation in the model:
- Control flow can stay only in the same monitoring context or move upwards to an ancestor (parent, parent's parent, and so on).
- Expressions can reference only fields in the monitoring context from which their evaluation is triggered, or its ancestors.
If an expression (in a map, trigger condition, or filter) has more than one evaluation trigger, the second rule must apply for each of these. Therefore, maps that do not have a trigger (but instead run when any input changes) and that have any dependency in their own monitoring context cannot reference fields in any other monitoring context. For simplicity, this is a general rule; that is, maps without triggers cannot take input from another monitoring context.
If you must pass control, data, or both to subordinate monitoring contexts, use outbound events that are emitted in a higher-level monitoring context and received in a lower-level context or contexts. The correlation expression of the inbound event definition must evaluate to true for each lower-level context that should receive the event, and the setting for multiple matching monitoring context instances must specify that the event be delivered to all instances.
It is a recommended practice to create only one monitoring context at the root level. In the monitor model editor, you can create peer contexts at the root level, but event sequencing can be a problem and correlation errors can result, especially if the peer root level contexts process the same events. To avoid this problem, put the peer root level contexts in different monitor models.
Quality of service
Rather than relying on the standard Common Base Event fields, you can specify the location of important configuration information (event sequence path, event creation time, and global instance ID) inside your events. Using quality of service properties to provide the location of this information increases the semantic content and robustness of your monitor model.
If you know that events are likely to arrive out of order at run time, you can use the Quality of Service section to specify an event sequence path. The path is an XML Path Language (XPath) expression pointing to an event attribute in each inbound event that indicates the order in which inbound events should be processed.
If you specify this path at the monitoring context level, the path is used for all contained and descendant inbound events. You can override it for individual inbound events by specifying a path to an event attribute for the inbound event. For more information about event sequence paths, see Event sequence paths.
You can also use the Quality of Service section to specify the creation time of the event. The Monitor server uses this attribute to indicate the instance creation time, for example to determine the stop and start times of a stopwatch, or to determine which instances should be included when calculating historical KPI values. By default, the value used at run time is the path to the Common Base Event creationTime attribute, which contains the time at which the event is created, in UTC. Alternatively, you might want to use a more business-relevant creation time from the event payload.
For example, for a purchase order instance, you could choose the date and time that a purchase order was placed, thereby ensuring that the KPIs based on the purchase order would be calculated relative to the time of the purchase order rather than relative to an arbitrary system time from the Common Base Event.
You can also use the Quality of Service section to specify the path to the global instance ID. This ID is used to relate the problem determination message to a specific event when there is an error at run time, for example in the WebSphere Application Server log. By default, the value used at run time is the path to the Common Base Event globalInstanceId, which is an automatically generated identifier to uniquely identify the event.
Application elements
When a monitoring context is generated from a Process Server application, the monitoring context is associated with the application element that it is monitoring.
For example, a monitoring context could be associated with a particular Business Process Execution Language (BPEL) process or activity, a Service Component Architecture component, or a business state machine. Collectively, this set of elements within the application that can be associated with monitoring contexts is known as application elements (or sometimes event sources). The application element is the source of events for the monitoring context.
Generally, a monitoring context is associated with a single application element, but it is also possible for a monitoring context to collect events coming from more than one application element.
In addition, a given application element within a Process Server can be represented by more than one monitoring context within a monitor model. As a result, you can monitor a given application element in two different ways.
For example, you might want to monitor a particular BPEL process at the level of each individual process instance, and also monitor the process at the module-instance level. You can use multiple monitoring contexts, each of which is associated with the same BPEL process application element.