The iWay Business Rules Engine: A Primer

By Reshma Radia

Serving as a single repository for business rules, the iWay Business Rules Engine adds an additional layer on top of the iWay Service Manager. It includes a simple user interface to manage and configure all business rules within a particular database instance configured to interact with the iWay Service Manager. iWay Business Rules Extension is compatible with mySQL, Oracle and IBM DB2, and can be enhanced to interact with any other database.

The main function of the Business Rules Extension is to allow for a set of rules, conditions and outcomes based on business requirements to be processed efficiently using iWay IFL (iWay Functional Language provided by the core product) but still loosely coupled with the final integration solution. The Business Rules Extension can be coupled with several other iSM products, such as iWay Activity Monitor, iWay Trading Partner Manager and iWay Enable.

There are four main ways business rules are encoded and processed within the iWay Service Manager environment:

Self-contained decision: iSM ProcessFlow/Decision Switch object acting on Message and Context
External info lookup: local rules but with external processing information (iWay Trading Partner Manager, LDAP)
External decision and information (business rules-based): rules and information externalized (iWay Rules Engine)
Event-triggered rules: Complex Event Processing /CEP)-iSM with iRules plus iWay Activity Monitor or iWay Enable.

iWay Business Rules Extension: Components
In order to configure a complete Business Rules Extension solution, one must think about the following components and how to relate the business requirements in order to create the overall solution:
Domain: the set of rules needed to fulfill a particular business requirement.
Rule: the actual rule that needs to be implemented.
Rule conditions: one or more tests of the rule
Outcomes: What should occur when a rule (the related set of conditions of the rule) is true
Domain rules: the mapping of what rules are in a named Domain, and in what order they should be applied
Rule outcome: the mapping of outcomes to rule (and in sequence)

With iSM and iWay Business Rules Extension, one has a Business Processing Engine and a Rules Processing Engine. One must understand the different functions of each. There is overlap in functionality, so design decisions and the associated trade-offs need to be understood.

iWayBusiness Rules Extension: User Interface
The iWay Business Rules user interface provides an easy and simplified way to maintain and create rules without having to understand the inner workings of the database layer.  Screen 1 provides a visual look into creating rules and outcomes via the business rules user interface.

Screen 1

Tying it all together
One must understand how to integrate a complete Business Rules solution in order to leverage both the iWay Service Manager and iWay Business Rules Extension to their full potential. Take for example, a business case of an organization handling package shipments and wanta a Rules Engine to define the rules for how these packages should be handled.  

Such a business case would require both the iWay Service Manager to create a channel with a listener and process flow. The process flow would tap into the business rules engine to execute the correct rules, conditions and subsequent outcomes to complete the business requirement.

Systems infrastructure, Business Processing and Rules Processing Summary
Business events exist in a relational database:
Call Rule Engine to set up processing info defaults (e.g., Rule Processing Start Time, and New Priority Ship time)
Set processed events to 1 or “in process”
Get all “Pickup” events with status = 1 and pickups are in future
Call Rules Engine with these Pickup events

Pickup Events are processed via Rules Engine – Rules Domain: “Pickups”
PickupBegin: always happens and clears values
DriverNotComplete: if the driver has not completed pickup of this pickup event
PickupRecord: if this record is a pickup event
PickupShipmentRecord: if this record is a pickup shipment event
PickupEnd: Always happens and sets the processing end time

The above high-level set of rules is shown in the iWay Rules Engine Admin User Interface here:

Results of event processing include the following:
Updates to the database
Existing pickups – update
Not existing – create new pickup
Existing PickupShipment – update shipment
Not existing – create new shipment from PickupDetails

The business flow above must be deployed into a physical iSM integration server and triggered in some fashion, either by an event listener or by a call from a Web service or scheduler.