Event processing
To understand the event re-sequencing (reordering) mechanism available in IBM® Business Monitor, it is helpful to first understand how the server processes events.
- First, the events are processed by the event stream moderator, a part of the server that temporarily caches and stages the events.
- Second, the events are processed by the model logic, which represents the monitor model you have created.
The event stream moderator maintains a set of active event stream instance groups, each identified by a unique instance ID. That is, the moderator groups together events that should be processed relative to one another. These events are associated together by the same unique instance ID. An example is an online order entry system. As Bill adds items to his order, the instance of the business process he is using generates events, and those events are associated with the same unique instance ID. As Sue adds items to her order, her instance of the same business process generates events that are associated with a different unique instance ID. This way, Bill's events are grouped together and Sue's events are grouped together, separate from one another. If Bill and Sue are entering orders at the same time, their events typically arrive at the server interwoven in time. If there are hundreds of people actively placing orders online, the event stream contains events from all of them, all interwoven with one another.
As events arrive, each event is registered into its unique event group (or batch) of messages corresponding to its unique instance ID. When the event stream moderator decides that a batch of events for a particular instance ID is ready to be processed (the decision is based on how many events are in the group, when the events arrived, and how long the events have been held in the group), the batch of events is submitted as a work request to the monitor model logic module to be processed.
While a batch of events is being processed for a given instance ID, the event stream moderator continues to register newly arrived events in a new batch for the same instance ID that is being processed. Hence, events are cached in the next batch as the current batch of events is being processed by the model logic. To ensure that events are processed sequentially, only one work request for a given instance ID is ever submitted to the model logic for processing at a time. An active work request for an instance ID must be complete before another work request for that same instance ID is sent to the monitor model logic module (and only if the new batch of events is ready to be processed). Many work requests can be processed concurrently, but not for the same instance ID. Saying this a bit differently, the model logic can be processing batches of events from many unique instance IDs at the same time.