This illustrates a conceptual view of the event processing flow. There are 3 basic elements – events, the event processing system and actions. Again, events are any electronic message or signal emitted or published by any process executing in the extended information infrastructure, including sensors, databases, 3rd party application suites, legacy applications, business process workflows, activity monitors, content from external sources, transactions, for example, from CICS. Although events can be sent directly to the event processing system, most often events are published to an enterprise message transport service such as JMS, IBM’s MQ, Message Broker or Enterprise Service Bus. Our use of the cloud illustrates events published to the enterprise message service. Any process can subscribe or consume events from the cloud. In this illustration, we show the WBE system (running on any network server) subscribing to certain events of interest, as defined by the user. When events are consumed, the WBE system immediately attempts to execute the user defined logic . This logic is used by WBE to understand which events are of interest, how to evaluate and correlate events for detecting event patterns and what actions or responses to create and emit when actionable events or patterns are detected. Actions, like events are electronic messages emitted by the WBE system. Action messages are used to inform people or other systems when an actionable situation has been detected. Presumably, when informed, people will react and systems will execute.. An action might be an email alert, an update to a dashboard or a database, a message to a transaction processing system or a message that might initiate the processing of an application or invoke a business process or service. Actions can be communicated directly to a system, published to the message transport service for consumption by any process or transmitted directly back into the WBE system for recursive event processing. In summary, events are emitted, communicated, and then processed by WBE, where, when actionable situations are discovered, action messages are published by WBE informing people or systems of the situation resulting in a response. This intelligent sense and respond processing is often a continuous recursive flow of events and actions among systems driven by the processing of events. This flow mimics how businesses operated before automation – when certain actives occurred in one department, it would trigger a response from another department, which when completed would initiate activities in yet another group and so on and so on until the process came to a logical conclusion. For example; if there are 3 product inquires from the same perspective client within a 5 day period, respond by initiating sales activities, resulting in a purchase, which drives a product order, requiring shipment, billing and accounts receivable activities. The right-time processing of these disparate systems was coordinated based on a preceding event or an event pattern.
Filters, or conditions, come in two flavors – “data” filters and “stream” filters. Data filters operate against the Intermediate Object (in-memory data) layer which can be populated by the event or other methods (DB, Web Service, etc. – as defined by the IT person when the objects were created). Stream filters allow correlation of the event triggering the rule with any other event or action (or combination) in the application. The context in which to relate the events and actions is called a “Stream ID” or “Context ID” which can be any Intermediate Object field. In this example, the Stream ID is the Customer ID which tells the rule to look for any PIN changes for that customer. If a different Stream ID were used in this example (such as “ATM ID”), then the rule would look for a PIN change from the same ATM in the past 24 hours (in that case the customer id would be irrelevant).
In addition, any number of actions may result in a rule evaluating to true. In this case, if the conditions are true (the withdrawal amount was above $1,000 and the customer changed his/her PIN in the last 24 hours), then the transaction would be denied and would be sent to Investigations.
WBE is comprise of 3 seamlessly integrated elements – Design Environment, Run-time Environment and a Asset Repository.
Key Take Away: Show combination of Business Activity Monitoring (BAM), Business Event Processing (BEP), and Business Intelligence (BI) in the same closed loop system with the ability to act or intervene based on that information.
The result is a comprehensive systems of capturing, aggregating and analyzing information. Combining best of both value propositions for BAM, BI and BEP.
Aggregating across events, processes, applications and historical data for a complete business picture
Unparalleled ability to act or intervene based on that information: automated response, human decision support, or ongoing process optimization