Introduction

This is the second in a series of article exploring on-demand scenarios that integrate business process management (BPM), business rules and business intelligence. This article focuses on integration of external business rules into a business process and looks at how business rules were integrated into the business process at our fictitious company, IFM.

In our last installment, Christina White, the CIO, heard about the benefits of business process management technology and had one of her architects, Greg Thomas, investigate. Greg discovered that not only is there tremendous benefit from moving the business process outside of the application logic into a BPM engine, but off-loading the most volatile logic to business rules engines offers even more flexibility, possibly even allowing the business analysts direct access to rules. Christina decided that the pricing problem would be a good one to tackle in one of their first implementations.

This article focuses on using rules in the business process. We start out with a brief look at hooking external data sources, such as rules engines, into a business process. Then we talk about a few specific rules engines and show how to construct the simple pricing rules using each of these rules engines. Next, we describe the pricing scenario. Finally, we dig into the WICS components used in the scenario, especially the components uses to access the external rules from the business process.

Back to top

Connecting to the business process

Christina and Greg are quickly sold on using WICS for BPM because of the ease of connecting external applications and data sources into the business process with WICS. WebSphere Business Integrator Adapter technology is what makes connecting external sources possible. WICS is commonly described as a "hub-and-spoke" architecture, with the WebSphere InterChange Server as the hub and adapters connecting in external applications and data sources as the spokes.

WBI Adapters are available for many legacy applications (e.g., SAP) and data sources (e.g., text, XML and JDBC). Custom adapters can be written for additional applications and data sources. Adapters all serve the same basic function: They convert data between the format expected by the business processes in WICS and the format required by the external applications and data sources.

As the picture above indicates, WICS business process logic operates on Business Objects; an adapter is the component that converts data between Business Objects and whatever a particular application supports. Greg quickly realizes a custom adapter could be used to link a rules engine into a WICS business process. He notes that WICS-facing interface is basically the same for all adapters, but each adapter is different on its application-facing interface. For rules engines, the application-facing side can be written to whatever API the rules engine exposes.

WBI offers a Web Service adapter that can connect a WICS business process to a web service. This could easily be used with rules engines (such as ILOG JRules) that have web service support, and with other rules engines, after writing the necessary web service interface.

Back to top

Getting to rules

The previous article in this series gave a flavor of the variety of rules engines. Some rule processor types mentioned include simple, data-centric and transaction-oriented. Rules come in many types. In sense-and-respond rules engines (Tivoli TEC) rules are specified as responses to events. Declarative rules that specify what happens, versus procedural "how it happens", characterize decision-logic rules engines (Blaze, JRules and BRBeans). Constraint and relationship rules dominate in data-centered transactional rules engines (Versata). Solution-space constraint rules are used in engines that compute a "best fit" result from alternatives based on constraint criteria (JRules). Greg focuses on just 3 rules engines: Versata, BRBeans and ILOG JRules.

Versata Logic Server is a product of Versata Corporation. The other rules engines considered here are "decision logic" rules engines. In contrast, Versata supports transaction logic and is oriented towards data operations. Versata has a full featured development environment, but no web-based tool for modifying rules. Versata is typically used as a generator for data-centric Java applications comprised of transaction-based and process-based rules logic and web or application GUI presentation layer.

BRBeans is a feature of WebSphere Application Server Enterprise. BRBeans runtime is implemented as EJBs hosted in WAS along with an application framework for invoking rules. BRBeans is a "decision logic" rules engine; however, it does not support rulesets (groups of rules sharing a common execution context). The BRBeans design point makes a distinction between a rule (a reference used by an application) and a rule implementation, which is a Java class. BRBeans provides a rule management application (and API) that can dynamically associate a rule with a particular rule implementation and allows easy update of parameters associated with a rule.

JRules is a "decision logic" inference rules engine. It employs a relatively small footprint runtime that can be deployed with an application, and it offers dynamically updateable rules repositories from which applications pull and trigger rules using JRules APIs. JRules offers a full-featured development environment that supports rule unit testing and code generation of rule-based applications. JRules also provides tools for generating simple-to-use web-based interfaces for modifying rules. JRules code generation options include J2EE (Web Service and EJB) and simple J2SE.

Recall from the previous article, Christina has a requirement to replace IFM's legacy pricing application with a new flexible pricing model that takes into account many parameters; and the business people want to be able to change the model based on conditions in the marketplace. Greg realizes that as new requirements arise for the pricing process they can quickly change the process flow using WBI process design tools. The requirement to apply different pricing equations could be met by exploiting a Business Rules Engine that was integrated into the pricing business process. Greg starts with a simple model for pricing and for markup. His pricing model is a dynamic pricing algorithm where the same pricing action (raise price or lower price) is taken as long as the profit margin is flat or rising.

markupi+1 = markupi + delta*sign{profiti - profiti-1}*sign{markupi - markupti-1}

The next section shows how you could create the dynamic pricing rule in Greg's 3 rules engines: Versata, BRBeans and JRules.

Back to top

Creating business rules with Versata

The screen shot of the Versata Logic Studio IDE below shows the Versata business object used in the pricing scenario. Note that the Versata business objects look like database tables in the user interface and rules look like database SQL.

The screen shot below shows the formula for computing the new value of the markup delta value in the Versata Rule Builder feature of the Versata Logic Studio.

Versata supports parent/child relationships among business objects, with automatic rollups (summation, counts, etc.) from child objects attributes into parent object attributes and replication of parent object attributes into child object attributes. Versata creates database tables that "back up" its business objects and generates Java code that implements the data manipulations that comprise the rules. Versata Logic Studio supports adding custom Java methods to its generated classes using the Versata Logic Server Rule Builder GUI, but most rules can be defined without writing any code.

Back to top

Creating business rules with BRBeans

BRBeans distinguishes between a BRBeans rule, which is the "business rule implemented in the BRBeans framework", and the BRBeans rule "implementor", which is the Java class that implements a business rule. In other words, the BRBeans rule defines or describes a business rule to the BRBeans framework, while the BRBeans rule implementor implements it in code. The BRBeans rule management GUI allows definition of BRBeans rules. BRBeans does not directly support development of rule implementors, but it does define the implementation classes that all implementers inherit in one of the BRBeans Java packages. BRBeans also supplies a set of about 20 pre-defined BRBeans rule implementors. The pre-defined rule implementors are somewhat limited in scope. For example, they could not support a simple rule like "if (price * quantity * profit_percent > X) then do-something". The figure below displays some of these built-in rule implementors in a drop-down box in the BRBeans rule management GUI.

BRBeans divides rule definitions into four types: simple rules, classifier rules, classified rules and situational rules. Simple rules can return any Java object. Classifier rules return a Java String whose value specifies a classification (e.g., "GOLD", "SILVER" or "BRONZE"). A classified rule has a classification such as GOLD, SILVER or BRONZE in addition to its name. A set of classified rules all have the same name, but each has a different classification value. For example, you could have a DISCOUNT rule classified as "GOLD" that returns a Java Long constant value of 20, another DISCOUNT rule classified as "SILVER" that returns a constant value of 10 and a DISCOUNT rule classified as "BRONZE" that returns a constant value of 5. Classified rules are never triggered directly from an application. Situational rules combine a classifier rule with a classified rule. Continuing with the example above, the classifier portion of the DISCOUNT situational rule computes a classification, say "GOLD", which causes the BRBeans framework to invoke the classified rule classified as "GOLD", resulting in a Java Long return value from the situational rule of 20.

The rule management GUI screen shot below shows the information for the pricing rule: the name of the Java class implementing the rule, the initialization parameters (the initial values for markup and delta) and the sources of the "firing" parameters that are passed to the rule when the trigger method is invoked causing the rule to fire. When the rule is triggered, the firing parameters are passed to the rule in a Java Object array.

BRBeans framework directly supports rules invoking other rules. In BRBeans terminology, the rule invoked by another rule is a dependent rule. BRBeans framework passes the names of all dependent rules to a "parent" rule in the parent rule's initialization method and the parent rule invokes the dependent rule as needed. However, the rule to compute price markup was simple and did not require dependent rules.

Back to top

Writing Java implementations for BRBeans rules

A custom BRBeans rule implementor must be written if the application calls for functions not supported by one of the pre-defined rule implementors. A BRBeans implementor is a Java class that implements the Java interface com.ibm.websphere.brb.RuleImplementor, which includes an initialization and a fire method. The init method is passed the initialization parameters defined in the BRBeans rule management GUI and the names of any dependent rules. The "fire" method is passed the "firing" parameters from the trigger method invocation in the client application. The fire method implements whatever logic is necessary to produce the rule behavior. The example code below is excerpted from the init and fire methods in the MARKUP rule of the pricing scenario. The first excerpt shows code that processes the initial parameters. The second excerpt shows code computing the new value "delta" and the new markup percentage.

Back to top

Developing rules in ILOG JRules

The JRules rule development environment supports three rule formats: BAL (Business Analyst Language) - an intuitive IF-THEN-ELSE rule format, TRL (Technical Rule Language) - a powerful language intended for use by technical staff, and Decision Table rules, where rules input and outcomes are specified in "decision table" format.

Since the IFM pricing rules are quite simple, they can be modeled in a BAL rule that uses an input Pricing information resource and an object that persists previous profit and markup information. The figures below show the object model and markup rule in the JRules rule builder testing facility.

Back to top

Dynamic Pricing Scenario

The dynamic pricing scenario topology includes WebSphere Portal Server, WICS, Analytics (to be discussed in the next article in this series), a rules engine and some WBI Adapter to hook things together. A purchase order message initiated at the portal front-end kicks off the pricing process. The pricing process uses information in the input message, along with historical information hosted in a Business Analytics system, passing this information to the rules engine where the markup for the purchase order is computed based on policy rules. The scenario also includes maps that transfer information needed by the rules from the input message to a "Rules Business Object".

Back to top

The business process in WICS

In the scenario, WICS business process flows trigger external rules by mapping relevant portions of the business process BO into a rules BO, then passing this rules BO to the rules adapter. The WICS Process Designer screen shot below shows the flow used to map information from the purchase order to the rules BO, pass it to the rules adapter and process the result.

Since the rules engine adapters all share a common interface and use the same Rules business object, they are interchangeable from the point of view of the WICS hub. Switching from one to the other is a simple selection, as illustrated in the screen shot below.

Back to top

The WebSphere Business Integration rules business object

The rules business object in the rules engine adapters is the VLS_versata_cw BO. The business object is XML-based (i.e., created from a DTD definition). The business object is described in the table below.

Figure 13: Format of VLS_versata_cw WebSphere Business Integration Rule Business Object

WBI mapping technology allows automatic conversion between different business object formats. Typically, a WBI adapter is the component invoking a map to convert BO formats, but in the dynamic pricing scenario, the maps are invoked directly from the business process flow. The maps used in the dynamic pricing scenario convert between an input purchase order BO and the rules BO. The business process flow invokes maps that extract order data and analytics data into the rules BO, and then passes the BO out the rules engine adapter port. When the resulting BO is returned on the rules engine adapter port, the business process flow invokes maps that extract the result into the purchase order BO.

Next we look at implementing custom WBI adapters that process the rule BO into rules for Versata, BRBeans and JRules.

Back to top

Using Versata rules in WICS business process

Everything in Versata looks like a relational database. Rules look like database SQL commands and triggers organized around Business Objects that look like a database schema. Versata directly supports data sources in a relational database. In a typical Versata implementation, Versata is used as an application generator for a transaction-rules application and GUI; and, Versata Logic Server operates directly with the application database, with rules triggering as data is changed. While this is beneficial for straight relational access, it is not necessarily a good fit for complex application environments that require integration of multiple systems. Environments that consist of pre-packaged applications and legacy systems on various platforms require sophisticated Enterprise Application Integration tools like those in the WebSphere Business Integration family of products.

WBI adapter technology allows accessing Versata-hosted business rules results from a business process flow. The business process flow passes the rule BO to the custom WBI rules engine adapter. The adapter uses the data in the rule BO and meta-data for the Versata business object to construct queries and command necessary to trigger the business object logic to compute the markup and retrieve the result.

The Versata VLS APIs support manipulation of the structure (rules meta-data) and content (rules data values) of Versata business objects. The Versata adapter uses the Versata VLS Java API to interrogate the meta-data associated with the Versata business object specified in the input BO table Name to determine how to formulate data requests (create / update / query) to the Versata Logic Server. The example code below illustrates use of business object meta-data as it checks the meta-data for each attribute in the business object to determine whether it is part of the unique access key needed to retrieve data from a specific data object.

The adapter also uses the Versata VLS APIs to push attribute values out to Versata business objects and retrieve business rules results from these objects. Notice that the API has a definite database access flavor.

Back to top

Using BRBeans rules in WICS business process

The BRBeans adapter has the same interface and uses the same rules business object as the Versata adapter. The BRBeans adapter differs only in the code that initializes and accesses the rules engine framework.

The initialization code in the BRBeans adapter establishes the BRBeans environment (host, port, rules JNDI information and access to the BRBeans "rules management" framework) as defined in the BRBeans properties file, which is specified in a Java command-line parameter. The initialization code is excerpted below.

BRBeans has specific methods for invoking each type of BRBeans rule: simple, classifier or situational(1). The BRBeans rule management API does provide a way to distinguish between simple and classifier rules; but BRBeans framework does not support identification of situational rules versus classifier rules(2). If only simple and situational rules categories are used, BRBeans APIs can be used to determine the correct trigger method to invoke a particular rule. BRBeans requires that the name of both the classifier and classified rules be supplied for situational rules, so situational rules are easier to manage if both classifier and classified rules for a given situational rule have the same name (i.e., if you know one name you know the other). The example code below invokes a private method that uses the BRBeans rule management API to determine whether the rule is simple or situational, and then invoke the appropriate triggering method.

Back to top

Using JRules rules in WICS business process

JRules supports XML document input to its rules engine. To achieve this, the user defines the format of the Java class resources used in the rules in a schema XSD file, then uses JRules APIs and the schema XSD to process XML documents into resources at rule execution time. JRules development environment can generate J2SE and J2EE (Web Service and EJB) rule processing code, so the adapter developer has implementation choices. Since the JRules runtime is relatively small, it could even be included directly in the adapter.

The following represents XSD contents for the simple Pricing resource used in the dynamic pricing rules:

 
  <schema...> 
  <element name="productId" type="string"/>
  <element name="profitPercent" type="double"/> 
  <element name="markupPercent" type = "double"/> 
  </schema> 

The following represents XML contents for an example Pricing object:

 
  <Pricing> 
  <productId>A123</productId>
  <profitPercent>25.0</profitPercent> 
  </Pricing> 

Back to top

Coming next

In the next article in this series we continue our dive into the details of how BPM, business rules, and business intelligence systems can be integrated together within the context of these business scenarios at International Foods Market, with a focus on integrating Business Intelligence systems.

Back to top

Footnotes

¹ For example, the method triggerSituational is used to trigger situational rules; and, the method trigger is used to trigger simple rules.

² The initial rule invoked in triggerSituational is a classifier rule.

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Connecting to the business process
• Getting to rules
• Creating business rules with Versata
• Creating business rules with BRBeans
• Writing Java implementations for BRBeans rules
• Developing rules in ILOG JRules
• Dynamic Pricing Scenario
• The business process in WICS
• The WebSphere Business Integration rules business object
• Using Versata rules in WICS business process
• Using BRBeans rules in WICS business process
• Using JRules rules in WICS business process
• Coming next
• Footnotes
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers