Business event processing with WebSphere Business Events, Part 1: An introduction

WebSphere® Business Events is a new IBM® product that enables you to detect, understand, and act on patterns in business events. Part 1 of this series introduces you to key WebSphere Business Events concepts and tools.

Share:

Peter Crocker (peter_crocker@uk.ibm.com), Senior IT Specialist, IBM

Photo of Peter CrockerPeter Crocker is an Architect and Development Lead for WebSphere Business Events at the IBM Hursley Software Lab in the UK. He previously worked as a consultant as part of the IBM Software Service worldwide technical practice, leading customers in the architecture, design, and implementation of WebSphere Message Broker solutions. Prior to this, Peter held development positions in WebSphere Message Broker and WebSphere MQ product development. You can reach Peter at peter_crocker@uk.ibm.com.



Doina Klinger (dklinger@uk.ibm.com), Advisory Software Engineer, IBM

Doina Klinger photoDoina Klinger is an Advisory Software Engineer at the IBM Hursley Software Laboratory. She is a developer for WebSphere Business Events. She has worked previously as a developer and development lead on a number of WebSphere products and components, most recently, WebSphere Enterprise Service Bus and WebSphere Integration Developer. She has an interest in Eclipse and messaging and event processing technologies. Doina joined IBM in 2000, having received an MSc in Computer Science from Purdue University. You can reach Doina at dklinger@uk.ibm.com.



Latha Sivakumar (lsivakum@us.ibm.com), Advisory Software Engineer, IBM

Latha Sivakumar photoLatha Sivakumar is an Advisory Software Engineer with the IBM WebSphere Business Monitor development team in Research Triangle Park, NC. She currently works on integration of Business Monitor with other products in the BPM suite, including Websphere Business Events. She previously worked on the Monitor Data Services team and on multiple Tivoli products, including Tivoli Business System Manager. You can reach Latha at lsivakum@us.ibm.com.



03 September 2008

Also available in Chinese Japanese Spanish

Overview

This article is the first in a series that introduces WebSphere Business Events (hereafter called Business Events) and shows how it can be used with other products in the WebSphere family, such as WebSphere Enterprise Bus, WebSphere Process Server, WebSphere Message Broker and WebSphere Business Monitor. In Part 1, you'll learn the about the business value of Business Events in integrating enterprise applications, as well as the core Business Events concepts and tools. Part 2 will describe step-by-step how to develop and test a simple Business Events application. The remaining articles will show you how to integrate the application with the other WebSphere products.

Business event processing

Businesses operate in an ever-changing environment of interconnected events. Customer transactions, interest rates changes, orders from suppliers, logistical difficulties, and unexpected external events from hurricanes to strikes, can all impact a business.

Often, the sheer amount of live data makes it hard to identify the patterns in these events. This difficulty may mean missing out on new opportunities, delays in the redirection of resources when the need arises, and struggling to cope with unexpected conditions.

Business event processing (BEP) software helps businesses detect, evaluate, and react to event patterns in time to meet the business objectives. To the business process management (BPM) space, BEP adds live event pattern detection and the dynamic processes to respond to these patterns.

See Business Event Processing from IBM: A Smart SOA Solution for more information.

WebSphere Business Events can process events from disparate applications when:

  • The logic path is unpredictable and requires activity to be detected and correlated by time and sequence across multiple applications (non-linear processing)
  • Business logic changes frequently (dynamic processing)
  • Real-time monitoring of outcomes and automatically responding to activity trends is key. This provides a closed loop of active monitoring.

Business Events enhances existing BPM and Service-Oriented Architecture (SOA) infrastructures.

WebSphere Business Events

Business Events provides easy-to-use graphical authoring tools that you can use to define business policies and logic that respond to business events and patterns that are of interest to you and that initiate appropriate business actions. The business policies are very readable for non-technical users and closely follow the rules as described in plain language. The policies describe how your system will react to events occurring or not occurring in certain combinations or at certain times. They allow you to detect, analyze, and dynamically react to simple and complex relationships between people, events, and information.

Events can come from a variety of systems and applications, which may or may not be connected. Business Events can correlate and identify patterns from all these sources, and then generate actions that are either consumed by external systems or generate new events that are sent to Business Events.

Figure 1 illustrates some of the business situations that Business Events excels in managing. As you can see, there are multiple events across disparate sources over varying timeframes to consider: stock trades, accounts openings, password changes, account profile updates, account manager visits, emails with trade instructions, customers changing their details and large withdrawals. Business Events can make sense all these disparate events coming from heterogeneous sources by finding, in real-time, correlations and patterns that are non-sequenced and non-linear.

Figure 1. The big picture: Detect events, make decisions, and deliver actions
Business events flow

The sample scenario

In this series, we'll use a sample scenario to show how Business Events works. In this scenario, we need to detect speculative action in a trade system. The scenario requires identifying and appropriately responding to patterns of events over time.

Consider a trade system that receives buy and sell requests. The system needs to be monitored for specific patterns in the live trading data. We're interested in patterns within a large number of trade events (or messages) that might indicate speculative action. We'll define two policies to identify such situations: Sell and Buy events have attributes describing the customer, the stock, the date and time when the trade took place, the number of shares and the price. When a Sell occurs within an hour after a Buy event for the same stock and the same customer, a SellAfterBuy action is generated. If one customer does three sells after buys within a day, for the same or different stocks, a SpeculativeCustomer action is generated. These actions are the Business Events output. Other external systems can process these actions, as you'll see in future parts in this series.

Our sample scenario is a simplified version of an application of a regulation compliance use case from the financial industry. The brokers need to identify speculative trading, and regulations require them to report such cases in certain conditions.

Business Events architecture

Figure 2 shows the main components of the WebSphere Business Events run-time architecture.

Figure 2. Business Events run-time architecture
Business Events architecture
  • The run-time server is the core of Business Events. This is where the logic of business event processing takes place.
  • Connectors are internal system components that provide codeless connection to and from touchpoints via a variety of protocols.
  • The repository provides shared, secured storage for definitions of Business Events assets.

Business Events tools

Business Events comes with two core tools that are aimed at different user roles:

  • The Design Data tool is used to define external business systems that will interact with Business Events, as well as the data objects required. The typical user is an IT professional responsible for IT connectivity.
  • The Design tool is used to define the business event rules, which describe what happens when events come into Business Events and certain patterns are identified. The typical user of this tool is a business analyst who can analyze the rules and modify them as appropriate to respond to changing conditions.

In this section, we'll introduce these tools, which we'll refer to and use throughout the series. Other Business Events tools, which are not discussed in this series, include Administration, Dashboards, Design Dashboards, Properties and User Console. In Part 2, you'll learn how to use these tools in more detail. For more information on these tools, refer to the WebSphere Business Events V6.1 Information Center

The Design Data tool

The key components of the Design Data tool are as follows:

  • Touchpoints represent external systems or applications that send and receive events from WebSphere Business Events. The touchpoint defined in the sample application is TradeSystem. In a production Business Events application, several touchpoints would be defined, with events coming in from a variety of sources to be correlated and patterns identified For the sake of simplicity, we'll use a single touchpoint in the sample application.
  • Events identify activities in a touchpoint that will trigger some computation within Business Events. In the sample application, we'll define Buy and Sell events. Events are composed of one or more event objects.
  • Event objects are sets of defined data fields. The Buy and Sell events share an event object called TradeObject with the fields CustomerID, StockID, Quantity, Price, Date.
  • Actions identify activities that will occur in touchpoints when one or more rules in Business Events are true. The actions defined in the sample application include SellAfterBuy Speculative Customer. Actions are composed of one or more action objects.
  • Action objects are sets of defined data fields. The TradeOut action object is shared by all actions in the sample application.
  • Synthetic events are result events that are used instead of an action in an interaction block. A synthetic event allows an interaction block to invoke another event directly, which can be useful for complex event processing, where a complex event can be triggered as a distinct event, rather than being processed immediately.
  • Intermediate objects are conceptual representations of business objects, typically described in different applications or systems (and therefore in different event and action objects) under different names or in different formats. An intermediate object is created when a new event enters Business Events, with some of its fields copied from the event fields, some fields computed, set to constants, or filled in from a database table. In our example, we have one intermediate object, TradeObject.
  • Data sources are additional sources of data, such as relational databases or Excel spreadsheets. They are typically used to compute fields of the intermediate object that are not present in the event. For example, based on the customerID field of the event, the address field is computed using a SELECT statement against a database table. The process of retrieving data from a data source is known as a data fetch. Databases can be hosted (for example, in DB2® or Oracle®), local (for example, Microsoft® Excel spreadsheet), or remote. One or more fields of the intermediate object can be mapped to columns in a table.
  • Connectors pass data payloads (defined as XML messages) between touchpoints and the JMS message topic used by the runtime. Event connectors recognize an event in a touchpoint and pass data either directly or indirectly through protocols like HTTP to an internal Java™ Message Service (JMS) message queue for evaluation by a set of defined interaction policies). Similarly, action connectors take the results of business process rule evaluation, retrieve an action as a payload from the internal JMS message queue, and pass it to a touchpoint. An action connector may also return a result, which is placed on the inbound message queue and can be evaluated as a result event.

Figure 3 shows a sample of the Design Data tool. On the left, you see an asset tree with the definitions grouped in three sections:

  • Data Sources
  • Intermediate Objects
  • Touchpoints

On the right, you can see the editor for the selected object.

Figure 3. Design Data tool
Design data tool

The Design tool

The key components for the Design tool are:

  • Interaction blocks and interaction sets . An interaction block describes the action that will be triggered by the arrival of an event in Business Events when some conditions, or Filters, are satisfied. A group of one or more related blocks that are all triggered by the same event is called an interaction set. The rules that are part of one policy may have different filters attached to them, or may apply to actions in different touchpoints. In our example, we have SellAfterBuy and SpeculativeCustomer interaction policies.
  • Contexts are sets of Interaction sets related by an Intermediate Object field called a context ID. A context ID (for example, customer ID) uniquely identifies a common set of events flowing through a stream. The functions and filters are evaluated for events with the same context ID. In our example, the SellAfterBuy policy uses a context ID that is a combination of the customer ID and the stock ID. When a context relationship is defined for a policy, functions such as Occurrences of a certain event refer to the occurrences of the event with the same context ID as the event being evaluated.
  • Filters are conditions that appear in one or more rules. The conditions expressed in a Filter may be very simple, such as testing the value of a single data field, or quite complex, involving patterns of multiple events occurring (or not occurring) over time. The filters in our application are After Buy and Speculative Customer.
  • Event Flows are executable, graphical representations of business processes. They consist of a set of interaction sets and related business steps indicating events that are expected to follow triggered actions.

Figure 4 shows an example screen shot from the Design tool. The asset tree shows the interaction sets and filters. The definitions from the Design tool, the touchpoints with their events and actions, and the intermediate objects can be viewed but not modified.

Figure 4. Design tool showing interaction sets and filters
Design tool

What's next in the series

Future articles in this series will teach you how to detect business event patterns, and show you how to integrate Business Events with other WebSphere products and technologies.

  • In Part 2, you'll learn how to build and test the sample application to detect patterns in trading data. You'll learn how to use the Design Data tool to define data such as events and actions. You'll also learn how to use the Design tool to define filters and interaction sets. Finally, you'll learn how to deploy and test the Business Events application.
  • In Part 3, you'll learn how to integrate WebSphere Message Broker and Business Events to filter and transform messages to events and from actions. Business Events detects patterns in the events generating the actions.
  • In Part 4, you'll learn how to integrate Business Events with WebSphere Process Server and WebSphere Enterprise Service Bus (WebSphere ESB), so that messages from WebSphere ESB are sent as events to Business Events, which detects the patterns and sends resulting actions back to WebSphere ESB for processing.
  • In Part 5, you'll learn how to integrate Business Events with WebSphere Business Monitor (Monitor) so that Business Events can forwards business events in a format that the Monitor server can receive and process. Monitor can then analyze and provide reports on the business data received. The Monitor dashboard also provides a comprehensive set of graphs, reports and notifications that can be used to monitor and act on the data received from Business Events.
  • In Part 6, you'll learn how to configure Business Events to accept and generate Common Base Events, which are transported via the Common Event Infrastructure (CEI).

Summary

This article introduced you to business event processing and WebSphere Business Events, including its core concepts and tools. The next article in this series will describe step-by-step how to build the sample scenario.

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 Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, SOA and web services
ArticleID=334042
ArticleTitle=Business event processing with WebSphere Business Events, Part 1: An introduction
publish-date=09032008