Comparing data from two consecutive events in WebSphere Business Events

A commonly occurring event processing scenario concerns the situation where we have two consecutive events, and we wish to compare a given value between the two of them. Consider a scenario where we have a smart metering solution and we want to make sure that the meter is functioning properly. We might reasonably want check that the reading we just received is not less than the previous reading as an indicator that the meter is operating properly. This posting describes the WebSphere Business Events (WBE) logic I created to implement this scenario.

For this scenario we are primarily concerned with one event, Data arrived received from a Meter touchpoint defined in WBE.

The summary instance

In WBE, we have two possible options for comparing values in the current event with those of a previous instance of the same event. We can use an accumulating array to build a list of data received as each event arrives. This is useful for situations where we are interested to examine data gathered across a number of received events. In this scenario, we can use an alternative approach and use a summary instance intermediate object.

The summary instance is a mechanism for sharing state data across two events received by WBE. Rather than store state in the form of a growing list of data items, the summary instance is one single instance that can be updated with each received event. This approach is useful when we want to maintain simpler state information, such as a running total or in this scenario the previous value we received for the given meter reading.

In this scenario, we simply wish to maintain the previous meter reading alongside the current meter reading such that we can subsequently create an interaction set that compares the two values in WBE Design. The summary instance intermediate object will be visible within the WBE Design tool, and so the business user is free to define exactly how they wish to compare the two values using a filter.

We begin by creating an intermediate object ReadingTracker just as we would normally with two fields, currentReading and previousReading, both of data type Real.

 image

We now then modify the scope of this object to be summary instance by right-clicking and selecting Intermediate Object Properties… then navigating to the Object tab on the dialog box.

image

Using the drop down box provided, we simply set the Context scope: field to be Summary Instance and click OK.

Now we have created the summary instance object, we now need to manipulate its contents. We do this using a field constructor on the source event object.

Populating the summary instance from the event

Having created an intermediate object that will persist across multiple events, the next step is to create the logic to populate the fields when the events are received. In the simplest case, we map a field in the event object with a corresponding field in an intermediate object, for example the unique identifier for the meter. In WBE, we can add more sophisticated logic to control exactly how the contents of an intermediate object are populated. This is accomplished using a field constructor and fragments of JavaScript. The field constructor defines how the fields of the intermediate objects that are used to evaluate the business logic in interaction sets are constructed. By embedding fragments of JavaScript we are able to inject programmatic logic at this point before any of the business logic is computed by WBE.

In this scenario, we will use this mechanism to update and maintain the summary instance variable when we receive a Data arrived event such that when our interaction set is computed by WBE, the previousReading and currentReading fields accurately reflect the previous and current values returned from the meter. The source event in this case defines a single event object field reading.

image

We associate the currentReading field in our ReadingTracker intermediate object with the reading field in our event object as normal simply using drag/drop to join the two fields together. For the previousReading field, we will add some JavaScript logic that will return the previous reading we had stored in our intermediate object, or zero if this is the first reading we have received. To do this, we add a field constructor for the previousReading field.

image

We now see that the field has been added and we can use the twistie to expand on the detail of how the field is to be constructed. Since  we wish to add JavaScript logic to compute this field, we will select JavaScript from the drop down list for the Type: field.

image

The JavaScript logic we need evaluates the correct value to return for the previousReading field. The logic we enter into the Expression field is as follows:

var dblReturn = 0;
if (ReadingTracker.currentReading != null) {
   dblReturn = ReadingTracker.currentReading;
}

dblReturn;

This logic checks the existing summary instance to see if it has a currentReading value set. If so, this will be the reading gathered from the previous event, and hence we now return this as the value of previousReading since in the context of the currrent event, this is the previous reading. This is the key to the logic: because we are examining the value of currentReading during construction of the fields, we know that any state in our summary instance must be what remained from last time.

Note that we also have a safety guard in there that says if the summary instance has currentReading set to null, then we return zero since we have not had a reading before.

To complete the picture, we can other computed fields in our intermediate objects that make use of these values. In this case we are going to offer a readingDifference field alongside the readingValue field on our Reading intermediate object that will offer the business user the difference between the recent and previous values.

image

Sample interaction set and filter

Using the fields created previously we can now construct an interaction set and filters to make use of them. In this sample we are checking for meter tampering in the form of a decreasing meter reading.

image

The Meter reading decreasing filter simply checks where the readingDifference field is relative to zero – if less than zero, the more recent reading was less than the previous reading.

image

Advertisements

One response to “Comparing data from two consecutive events in WebSphere Business Events

  1. Hi webmaster – This is by far the best looking site I’ve seen. It was completely easy to navigate and it was easy to look for the information I needed. Fantastic layout and great content! Every site should have that. Awesome job

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s