≡ Menu

How Business Events and Business Rules Work Together


Another session on the integration of ILOG’s products with WebSphere, this time focused on the integration of WebSphere Business Events and rules.  Business Events are defined here as any electronic signal indicating a change of state. Business Event Processing is the sensing of patterns in these events that show an actionable situation has arisen and then the coordination of action in response. Business rules drive business decisions – they define how those decisions should be made. Business rules management is about extracting those rules from the various sources (people, legacy systems, regulations) and making it possible to execute them effectively to make automated decisions. BEP technology detects that events or patterns of events have occurred. A BRMS codifies the the logic in a decision or recommendation. The combination of technology is interesting, obviously, for turning insight into action and allowing a coherent response to be made to some pattern detected in the event cloud.

WebSphere Business Events (WBE):
In WBE business users can define the conditions and event-condition-action blocks they need using a simple, point and click interface. The environment allows technical integration, design, event flows to be defined and provides dashboards for monitoring the events. Intermediate objects can be defined, context is captured and both missing and temporal events can be handled. Specifically the product supports a process:

  • Business and IT users define the events to be monitored
  • These event definitions are stored in the WBE repository
  • The runtime then
    • Detects the events
    • Automates enrichment of the event data
    • Evaluates patterns and detects
    • Pattern is enriched if necessary
    • Some action is triggered

I won’t repeat the description of JRules – check out my previous post on rules and BPM for some details – but they did mention the powerful MS Office tools that ILOG has to manage rules.

The products can be integrated by having WBE call a Decision Service built with JRules or by having JRules deploy a Decision Agent that is listening for events, JMS messages for instance, and then having it put an event back into the event stream based on the decision. In either case the Decision Service/Agent can call other services to, for instance, gather additional data such as credit bureau data. Finally, when WBE kicks off a process, the rules and decision services can be reused in the context of the process thanks to the integration of WPS and JRules.

The two products were demonstrated in combination using an Anti-Money Laundering scenario. For AML, banks must ensure that they follow certain rules whenever handling transactions so they don’t miss money laundering. Regulatory rules applied to specific patterns. For instance, multiple cash deposits at different branches in a small time window that exceed the AML threshold for cash deposits or rapid sequences of deposit/withdrawl.

The demonstration includes two rulesets – “know your customer” rules to classify customers and rate for risk and rules to establish money laundering is happening. WBE is used in the scenario to watch the various deposits and the type/location/value. When a suspicious pattern is found it generates an “analysis required” event. JRules detects this and calculates risk. JRules adds a new event to the event cloud based on this. WBE detects the combination of the original pattern and the risk event and determines the action to take.


Comments on this entry are closed.