IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > What are monitor models? > Monitor details models

Inbound events

A monitoring-enabled application generates a series of events. To indicate the events that are of interest to the monitoring context, you define inbound events in the Monitor Model editor. These are actually subscription points or entry points for inbound events in a monitoring context. Business Monitor subscribes to the events you specify, and delivers them to all event entry points with a matching event subscription.

Because the events are being generated elsewhere and Business Monitor is simply monitoring them, typically you will have imported the definitions of the inbound events from somewhere else.

For example, if you are monitoring process executions, the events you subscribe to might be predefined by the workflow engine running those processes.

Each inbound event refers to a particular event definition that defines its structure. Event definitions can be found in XML Schema Definition (.xsd), Common Base Event, or Web Services Description Language (wsdl) files, or a combination. See Common Base Event and XML Schema Definition event definitions and Event parts for more information.


Filter conditions

You can define a filter condition for each inbound event subscription. The filter condition combines with the extension name (if one is provided) so that the events of interest for this particular subscription point are filtered. The Common Event Infrastructure (CEI) server decides where to forward the event based on the filter condition.

For example, an ATM machine might emit many events of type ATM_StatusEvent. These events might have a severity field that could indicate a severe error condition. An inbound event subscription for severe error conditions would specify ATM_StatusEvent as its event type, and add a filter that checks the severity field for the event code indicating a severe error.

The filter is an expression that evaluates to true or false based on the attributes of the event, for example, the order cost must be greater than $500, the date must fall within a certain period, or both. If the filter condition is not met, the event is ignored by this inbound-event subscription point (although it might still be detected by other subscription points in the same or a different monitoring context). Unlike the correlation expression (see the next section), which compares event attributes with state information in existing monitoring contexts, a filter condition depends on inbound event attributes only, and thus can be evaluated quickly. Defining efficient filters can help improve the performance of a monitor model at run time.


Correlation expressions

After the inbound event has passed the filter condition and been accepted, the correlation expression of the event is evaluated for each of the monitoring context instances.

The correlation expression, like the filter, is a condition. It often is simply attempting to match an event attribute with the monitoring context key and can resemble this line: 

 eventAttribute = key
For example, an event reporting that an order has been canceled must be delivered to the monitoring context instance that is tracking that particular order. The correlation expression would thus compare the order number carried in the cancellation event with the order number (or key) of the monitoring context instance tracking this order.

However, a correlation expression is not required to use a key.

For example, if a cancellation event reports cancellation of all orders from a particular customer, it might be looking for a customer name.

You could use a specific customer's loan number to find the monitoring context instance for that customer's loan. For Business Process Execution Language (BPEL) processes, you can also make use of the fact that each Common Base Event issued by the process engine contains a BPEL process instance ID that can be used to find the monitoring context instance tracking this process instance. You could correlate the inbound event with the correct monitoring context instance by using either the loan number or the process ID. You could have metrics called customerLoanNumber and processInstanceID. Either of them might have been declared the monitoring context key.

For a particular inbound event, the correlation expression can evaluate to true for zero, one, or several monitoring context instances. In each case, the model-defined settings determine the action. The possibilities include the following actions:

The first time that an inbound event arrives from a new real-world entity to be monitored (such as a new order that just arrived from a customer or a new ATM that was added to the network), there are typically no matching monitoring context instances. You can instruct the monitor to create a new monitoring context instance to accept the event.

In general, you specify an action for each of these cases:

After the monitor has determined which monitoring context instances should receive the event, it delivers the event to all qualifying monitoring context instances.


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.

Monitor details models