BPM voices: Joachim Frank: Behind the scenes of WebSphere Business Monitor event processing

Confused by how event processing works in WebSphere® Business Monitor? Just what are filter expressions, correlation predicates, and monitoring contexts, and how do they cooperate to ensure that the right events update the correct metrics, so that your business can react quickly? In this article, Joachim Frank peels back the curtain to show you what's going on behind the scenes and how it all comes together to ensure your business gets the information it needs, where and when it needs it. This content is part of the IBM Business Process Management Journal.


Joachim (Jim) H. Frank (jhfrank@us.ibm.com), Senior Software Architect, IBM

Joachim (Jim) Frank photoJoachim (Jim) H. Frank is a Senior Software Architect with IBM. He provided technical leadership for the design and development of WebSphere Business Modeler and WebSphere Business Monitor. You can reach Jim at jhfrank@us.ibm.com.

developerWorks Contributing author

06 October 2010 (First published 04 December 2008)

Also available in Chinese Russian Portuguese

Users of WebSphere Business Monitor (Monitor) sometimes tell us that its event processing algorithm is difficult to grasp. Mostly they seem puzzled by the purpose of filter expressions and correlation predicates, by the various event delivery options, and by the way in which updates are driven in a monitoring context.

In this article, I'll give you a behind the scenes look at these concepts. I won't go over many of the finer points of the Monitor programming model like triggers, timers, and nested monitoring contexts, but will focus simply on the basics of event processing.

I've also provided a slide show for download that shows, through a simple storyline, the path an event takes as it's processed by Monitor.

Event processing concepts

At the core of Monitor are observer objects. One observer object is created for every entity you want to monitor. Monitored entities can be tangible, such as a device, server, or vehicle, or abstract, such as a process execution, a package delivery, or a sales cycle. The observer object subscribes to events that report any state changes in the monitored entity, and then updates its own state based on information in those events.

An observer object used by Monitor is called a monitoring context or MC because the information it collects provides the context for monitoring an observed entity. The data fields in an MC are called metrics because they typically represent measurements of business-relevant information about this entity.

For example, let's say a limo company wants to monitor its fleet of cars. The company might want Monitor to create a monitoring contextf for each trip when it begins. This context can be updated with information about the trip, such as passenger pick-up time, traffic jams, and passenger drop-off time, based on events received from limos on the road. It might contain metrics for trip duration, pick-up and drop-off delays, a customer satisfaction index derived from these, average driving speed, and so on.

Extending their monitoring capabilities, the limo company might define MCs for their drivers with metrics for punctuality, trips per month, average customer satisfaction, and so on, or for their cars, with metrics like gas mileage, next scheduled service, and so on. These MCs would be observer objects for the drivers and the vehicles..

The metrics and event subscriptions of an MC are defined by monitoring context definitions. Just as an MC is a special-purpose object, its definition is a special-purpose class which defines the structure and behavior of its instances.

Now that you understand the basic concepts and terminology, let's see how it all works.

Event processing step-by-step

There are three steps to processing an event:

  1. Filtering - What kind of event is this?
  2. Correlation - Which MCs are interested in this event?
  3. Updating the MC - Which metrics are updated by the event, and how?

Each MC subscribes only to the kinds of events that pertain to the entity it monitors.

In the limo company example, the trip MCs might subscribe to events that report trip dispatching, passenger pick-up, passenger drop-off, heavy traffic, and car incidents. The trip MC definition would have five event subscriptions, one for each kind of event.

An event subscription contains a filter, which is a Boolean expression that evaluates to true for events it subscribes to and to false for all other events. The only rule for defining a filter is that it must let events of the desired kind pass and block all others. For performance reasons, filters should be kept as small as possible, in other words, they should be just complex enough to identify a particular kind of event among the variety of expected events.

For example, if an event contains an xsi:type attribute identifying its payload, and different kinds of events have different types, testing this attribute may be all that's needed. But if a single generic type of event is used to report occurrences of different kinds, which can only be determined by examining the event content, the filter must test additional fields.

In the limousine example, if the cars always report trip status using an event whose payload type is limo:TripStatus (where limo represents a namespace) and dispatch, pick-up, and drop-off events are distinguished through an event nature field, the event nature field will have to be tested along with the xsi:type attribute to determine what kind of event has arrived.

After an event has passed a subscription's filter, its correlation predicate is evaluated for existing MC. Correlation predicates typically compare some key value in the event , such as a unique trip identifier, with a metric containing the same key. If a matching MC is found, that MC may receive the event for further processing. If not, a new MC context may be created.

But what if that's not what you want? Say, for example, a passenger pick-up event arrives and no matching MC is found. In this case, you might not want to create a new MC, but instead raise an error condition indicating that the "car dispatched" event (which should have occurred first and created the MC) was not received. Similarly, if a "car dispatched" event arrives and an MC for the same trip is found, this would be unexpected and indicates an error. Again, you would want to raise an error, and not deliver the duplicate dispatch event to the already existing context.

As you can see, it's important to be able control the event correlation algorithm. You can do this by configuring event delivery settings. Each event subscription has three settings, which cover the cases of zero, one, and multiple MCs fulfilling the correlation predicate. The following table shows those settings.

Event delivery settings
Zero matchesOne matchMultiple matches
Ignore Ignore Ignore
Treat as error Treat as error Treat as error
Create new MC Deliver to the (single) matching MC Deliver to any matching MC
Roll back all changes and retry processing this event later Deliver to all matching MCs

After correlation processing has identified MCs for event delivery, their state is updated from the content of the event.

To understand how that works, you can think of an MC as a spreadsheet, whose cells are the metrics. For each metric, the MC definition defines one or more maps that set its value. The maps are like spreadsheet formulas. A map may depend on an event subscription.

When an event is delivered to an MC, all maps that depend on the receiving subscription are run, and their target metrics are updated with the results. Further updates are then processed in a cascading fashion, just like in a spreadsheet: maps that depend on the updated metrics update their targets, and so forth. The cascade will always terminate because the dependency graph defined by the maps is not allowed to have cycles. For example, if metric B depends on metric A, then metric A cannot depend on metric B.

View the slide show

If you found this walk-through somewhat dry, or you'd simply like an entertaining visual review of what you've learned, take a look at the "Event Processing" slide show provided with this article. This slide show steps you through the process I described in this article using simple graphics and an easy-to-understand story line.


I hope this article and the accompanying slides have given you a better understanding of the concepts behind event processing in WebSphere Business Monitor.


Slide show demoepdemo.pdf299KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=BPM voices: Joachim Frank: Behind the scenes of WebSphere Business Monitor event processing