Common patterns for synthetic events in WebSphere Business Events

This article describes how to use synthetic events in a WebSphere® Business Events project, using sample patterns to depict potential solutions where a synthetic event may be required or recommended. This content is part of the IBM Business Process Management Journal.

Share:

Paul Faulkner, Senior IT Specialist, IBM

Paul Faulkner photoPaul Faulkner is a Senior Certified IT Specialist with IBM Software Services for WebSphere, who specializes in system integration. Paul has designed and implemented complex integration patterns including policy driven Enterprise Service Bus (ESB) and solutions involving business event processing. Paul has over 20 years in IT with the majority of time spent developing middleware solutions and also has presented at multiple conferences.



15 January 2011

Introduction

This article describes some of the common interaction patterns that are seen when using synthetic events in a WebSphere Business Events project.


What are synthetic events?

A synthetic event is an event that is generated by WebSphere Business Events itself and is fired from an interaction set in the same way as an action. Other interaction sets can then be created to process the synthetic event.

In versions prior to WebSphere Business Events V7.0.1.1, when a synthetic event is fired, it is put on the JMS queue, or topic, and processed in the same manner as any other external event. This implementation has performance impacts because each synthetic event must be retrieved from the JMS and processed.

For WebSphere Business Events V7.0.1.1, the synthetic event process has been redesigned so that the event is processed immediately and is no longer re-queued. This new design does not have the same performance implications as the original design.


Why use synthetic events?

A synthetic event can be used in an interaction in many ways, but following are a few of the more common implementation patterns.

Simplify interaction logic

Reduce complexity of interactions by executing pre-filtering/screening logic on the inbound event. If the event passes the screening and is a candidate for further processing, a synthetic event can be fired. Interactions can then be written to operate on the synthetic event with the knowledge that the event has already met the conditions of the pre-screening logic.

Populate a context-sensitive intermediate object (CSIO) array

The CSIO may be required to contain data only for events that meet certain criteria. To facilitate this, an interaction is typically written to do a preliminary filter of the event and invoke a synthetic event, which can then update the contents of the CSIO array as appropriate.

Administer a context-sensitive summary object

When using a summary object, it may be necessary to reset the content of the summary object based on certain rules which can be defined within an interaction. By creating an interaction that dentifies when the summary object needs initialization, a synthetic event can be invoked and the summary object initialized using a simple JavaScript.

Create a common interaction for multiple event sources

In this case, events are received from different sources but a common set of interaction rules can be applied.

Reroute an event

In the case where events from an event source require processing independently, you can reroute the events to different synthetic events.


Sample interaction patterns

The following sections describe the sample interaction patterns in more detail.

Simplify interaction definitions

Sample scenario:

An event message contains an array of customer data from which you need to filter the event with different logic depending on the type of customer. The customer type is identified in the array by a field called CustomerType. There are several types of customer that need to be identified and then different complex logic needs to be applied to each type.

Possible Solutions

Depending on the complexity of the event data and the requirements for the action content, the recommended option is typically to use multiple interaction definitions, which contain the collection of filters required. The filters should be granular in design and reused within other filters to enable for reuse of the filter definitions.

Figure 1. Interaction with multiple filters in series
Interaction with multiple filters in series

Where complex event or action data is required, a better solution might be using synthetic events to filter the initial data and route to a new interaction set. Using this solution, you can often pass just the relevant portion of the array to the synthetic event, which makes the logic to process the event much simpler.

Figure 2. Solution using multiple synthetic events
Solution using multiple synthetic events

A third option could be to reuse the same synthetic event. This pattern can be implemented where the filter rules for each customer are the same or are defined by the content of the event.

Figure 3. Solution using a common synthetic event
Solution using a common synthetic event

Populate a context-sensitive intermediate object (CSIO) array

A CSIO array is used to collect and store the content of multiple events within the same context ID. This data is stored in memory, which can lead to a high overhead of memory utilization for your implementation.

The CSIO array can only store event data, and you typically want to limit the amount of data you store in the CSIO array to limit the memory overhead. To do this, it is recommended that you use a synthetic event that filters the relevant data to an intermediate object, which is defined to capture the array of event data within the context.

Figure 4. Solution using synthetic events with a CSIO array
olution using synthetic events with a CSIO array

Administer a context-sensitive summary object

The summary or state data from multiple events can be shared across events in a context by placing it in an intermediate object that is configured to be a summary instance intermediate object. There is only one instance of each summary instance intermediate object, and its contents can be updated at event arrival time, but prior to the execution of filter logic within the interaction

In order to reset the summary content based on filter logic, a synthetic event can be fired when the appropriate conditions are detected. This synthetic event can then be used to reset the content of the summary event using JavaScript.

Figure 5. Solution using synthetic events with a context-sensitive summary object
Solution using synthetic events with a context-sensitive summary object

Create a common interaction for multiple event sources

In this scenario, events are received from multiple event sources (App1, App2, and App3), but need to be processed by a common set of rules within the same context. An interaction is created to consume each event source and map the appropriate data to a common format, then a common synthetic event is fired from each application. Another interaction is defined, which consumes the synthetic events and process against the common filters.

Figure 6. Common interaction for multiple event sources
Common interaction for multiple event sources

Reroute events

There are many scenarios in which you need to reroute an event source and process the events independently of each other. One example of this is when an event source contains events that may require processing by multiple interactions. In most cases, creating multiple interactions with unique filters is sufficient. In the case where a context ID is required for an interaction, but not for all interactions from the same source, it maybe beneficial to precede the interaction processing with a “router” interaction, which can route the events to distinct synthetic events. This allows you to process the events for context-related interactions and plain interactions independently and avoid any costly overhead required for the contexts for all events.

Figure 7. Rerouting events
Rerouting events

Conclusion

In this article you learned about several patterns that utilize synthetic events to address various requirements within a WebSphere Business Events project.

Resources

Comments

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=617629
ArticleTitle=Common patterns for synthetic events in WebSphere Business Events
publish-date=01152011