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

Event sequence paths

Business Monitor can process events from many event producers at the same time.

For example, a business process can have several running instances, a bank can monitor transactions at several ATMs, and a manufacturer can monitor concurrent procurement orders. If events must be processed in order, define an event sequence path.

Events sent by different producers are typically processed in different monitoring contexts and their relative ordering is therefore not important. Events sent by the same producer, such as the same instance of a process, however, must often be processed in the order in which they were produced.

Events can arrive out of order for the following reasons:

If you know that events are likely to arrive out of order at run time, you can enable event reordering for inbound events in Business Monitor. To enable event reordering:

  1. Define an event sequence path for each inbound event. You can define the path either at the monitoring context or KPI context level, or for each individual inbound event definition.

  2. For inbound events in a monitoring context, ensure that each of the inbound events has a correlation expression that compares the key of the top-level monitoring context with an attribute in the event. (KPI contexts do not require this expression.)


Setting event sequence paths

The event sequence path expression is used to identify the order of the events relative to one another when they come from the same producer (for example, the same process instance). The expression is evaluated by Business Monitor and builds a string from inbound event attributes. The resulting string (the event sequence indicator) identifies the relative position of the event among other related events. As events arrive, the event sequence indicator of each related inbound event is compared to the others lexicographically to determine how to reorder the events.

The resulting event sequence indicator can contain any characters (such as letters, numbers, spaces, and so on) but all the strings must be the same length so that they can be compared correctly. If several events have the same event sequence indicator, those events are processed in the order that they are received. You typically want each event to have a unique event sequence indicator. If all of the event sequence indicators for a monitoring context hierarchy are integers, the resultant values are padded on the left with zeros to 16 characters so that the resulting numeric string values can be compared correctly.

For example, 12 becomes 0000000000000012 and 2 becomes 0000000000000002. Lexicographically, 12 comes before 2, but with the padding, 0000000000000002 comes before 0000000000000012, which is correct. Because of this numeric padding, positive integers will sort as expected, but negative ones will not. Do not use negative numbers.

The event sequence path expression, which indicates how to build the event sequence indicator from inbound event attributes, can be different for each kind of inbound event; as a result, you can define a separate event sequence path expression for each inbound event definition. Often the expression is simply a path to an attribute that contains a sequence number or time stamp. If a common expression can be used for some or all of the events that a monitoring context or KPI context subscribes to, you can define the expression at the monitoring context or KPI context level and it will serve as the default for all inbound event definitions that do not override it.

To define the event sequence path expression for a monitoring context, KPI context, or individual inbound event definition, use the Event Sequence Path field in the Monitor Model editor. You can define an expression that references any constant, function, or event attribute. The following examples illustrate this definition: 

UpdateClaim/extendedData/ClaimRequestNumber
OrderReceivedEvent/OrderDataEventPart/ord:orderNumber 
*/predefinedData/creationTime

The last example, starting with */, shows how to reference inbound event attributes in event sequence path expressions that are specified at the monitoring context or KPI context level. Since these paths must be used with different inbound event definitions, they cannot start with a specific inbound event definition ID like the first two examples. When this path is used, the leading asterisk (*) is replaced by the ID of the current inbound event definition. The result must always be a valid path in the context of each inbound event definition that uses it, as in this example. (Every inbound event contains the predefined creationTime attribute.)


Use correlation expressions to group events by producer

The correlation expression provides a way of identifying events from the same producer (such as the same process instance).

For example, Sue starts up an order entry application. As she enters her order line items, the underlying order entry process generates events that are being monitored. All of the events created on behalf of Sue's process have the same process instance ID. However, when Bill logs into the same order entry application and enters his line items, events generated on Bill's behalf have a different instance ID. The monitor model must specify where in the events the process instance ID can be found.

Typically the correlation expression uses a key to identify the event producer. Besides a process instance ID, possible keys are a transaction identifier or an order number. To support event reordering, you must include a key in the top-level monitoring context, and all the inbound events that are candidates for event reordering must compare this key with an attribute in the event in their correlation expressions.

Similarly, if you are going to run the monitor model multithreaded in a cluster, you must include a key in the top-level monitoring context, and all the inbound events that are candidates for event reordering must compare this key with an attribute in the event in their correlation expressions. See "Event sequencing" and "Processing strategies" for more information.