Introduction

Business Process Management (BPM) and Business Rules Management System (BRMS) are two hot zones in the current enterprise middleware products. With increasing requirements from customers, BPM and BRMS are more and more integrated to deliver customer solutions with high agility and extensibility for business processes. WebSphere Process Server V7.0 and ILOG JRules V7.0.2 are core products of BPM and BRMS, respectively. This article provides a brief introduction of Process Server and JRules first, then detailed information on how to integrate ILOG JRules and Process Server to implement agile business process, which includes key points on installation and configuration, different integration methodologies such as POJO, EJB, Web services, and JMS/MQ, and monitoring JRules services using the Common Event Infrastructure (CEI) in Process Server.

This article provides an overview of ILOG JRules and WebSphere Process Server integration. If you need a step-by-step guide for each integration points mentioned in this article, see the Integrate WebSphere ILOG JRules with WebSphere Process Server white paper.

Back to top

Overview

Business Process Management is becoming more important as the key part of an enterprise IT infrastructure. Business processes of an enterprise can be modeled, deployed, executed, and monitored on a platform of a BPM products suite, and business rules can be part of a business process. For example, in an account verification process of a bank, the business policies to assess the eligibility of customer or price decision are complex and prone to change in rapidly evolving markets. Therefore, hard coding these policies in process is not a good idea, since it is hard to manage and maintain business rules during runtime. Separating business rules from the business process and executing and managing them separately can improve the agility and extensibility for the entire business process. Figure 1 shows this idea.

In IBM’s current BPM portfolio, WebSphere Process Server is the business process execution platform that provides powerful, highly extensible, and industry standard compatible business process infrastructure for an enterprise. Process Server is based on the WebSphere Application Server platform and provides Enterprise Service Bus (ESB) capability, which enables the service-oriented architecture (SOA) of the enterprise. WebSphere Integration Developer (hereafter called Integration Developer) is the development and assembling tool for a business process. The projects developed in Integration Developer can be deployed to Process Server, which are then executed directly.

Although Integration Developer and Process Server already embed a business rule editor and business rule engine, you can only use it to implement simple rules or decision tables with limited business user interaction. For most use cases, the embedded rule engine cannot meet complex business requirements. Therefore, a dedicated and powerful business rule management system that supports a full life cycle of business rule modeling, executing, and managing and that can easily integrate with BPM products is needed.

ILOG JRules, the market-leading Business Rule Management System, offers such business capabilities to author, deploy, and manage business rules. It supports efficient policy change and rapid policy deployment, which are the required attributes for an agile and globally integrated enterprise.

ILOG JRules provides a systematic way to model, implement, and deploy business rules. It supports collaboration in an orderly and efficient manner. It includes tools tailored to the skills and knowledge of individual users, so policy managers, business analysts, and developers have the right support they need to get the most out of their BRMS.

Figure 2 illustrates the architecture of ILOG JRules.

The following section briefly introduces each part of the ILOG JRules architecture.

ILOG Rule Studio: An Eclipse-based development environment for the development of rule applications. It allows integrated co-editing and debugging of Java™ code and rules. Features include:

• Eclipse integration
• Auto correction in rule editing
• Code generation wizards
• Single interface repository
• Source code control integration
• Conflict and redundancy detection
• Easy deployment

ILOG Rule Team Server: A Web environment that allows distributed business teams to collaborate, create, manage, validate, and deploy business rules.

• The ILOG JRules Rule Execution Server provides a robust, J2SE, and J2EE-compliant execution environment for deploying and executing business rules. The Rule Execution Server includes components for synchronous, asynchronous, and Web service-based invocation of business rules, as well as a Web administration console. It is fully integrated with the ILOG JRules Rule Studio and Rule Team Server to support business rule deployment for both developers and business users.

• ILOG JRules is a product of the IBM WebSphere family, and has extensive technical integration available with other WebSphere products such as Process Server and Integration Developer. ILOG JRules allows business users to create and change rules quickly to cope with dynamic business needs without involving the IT staff. It also helps to establish visibility, trace ability, and quality of business rules across the enterprise so that business managers can make better decisions faster. For these reasons, ILOG JRules is a natural choice to integrate with IBM BPM products to provide policy and decision service for a customer’s business process scenarios. Figure 3 shows an example of invoking JRules service from a business process in Process Server.

This article focuses on the integration perspective of ILOG JRules with Process Server, including installation and configuration, different integration aspects using POJO, EJB, Web services, JMS/MQ, and monitoring JRules services using CEI in Process Server.

Back to top

Integrating ILOG JRules with WebSphere Process Server

Since Process Server is based on a WebSphere Application Server platform and ILOG JRules is J2EE compliant, integration of the ILOG JRules runtime components with Process Server is a standard J2EE application integration process. Figure 4 shows the core components of the JRules execution server after they are deployed to a J2EE environment.

JRules uses a database to store and manage rule set and rule application. Data source and persistence provide a JDBC solution to access the database used by JRules.

The Execution Unit (XU) is a resource adapter for Java EE Connector Architecture (JCA 1.5). The XU handles low-level details of rule set execution and provides access to manage its resources. XU can run independently of the management model. The XU makes configuration and runtime data available to the management model and implements the JCA contracts between the application server and the rule engine. The application server or application client uses the XU to connect to the rule engine.

Execution components are components that authorize the execution of a rule set by the XU. The Rule Execution Server execution components enable you to write code to interact with the Rule Execution Server model, without any dependency on the internal implementation.

A client module needs to embed the Rule Execution Server execution components (jrules-res-session-<appserver>.jar) that will be used to reference the XU.

Figure 5 shows the architecture of the JRules integration with Process Server.

The following steps are required to integrate the JRules runtime into Process Server:

1. Configure the data source for the JRules data source/persistence in Process Server. The JNDI name for the data source must be jdbc/resdatasource, as shown in Figure 6. Otherwise, JRules cannot connect its database correctly.
   
   Figure 6. Create datasource for JRules in WebSphere Process Server
   
   
   
2. Deploy the XU RAR to Process Server. The XU is a resource adapter provided by JRules. You can find it at JRulesInstallDir\executionserver\applicationservers\WebSphere7\jrules-res-xu-WAS7.rar. The JNDI name for the XU J2C connection factories is eis/XUConnectionFactory. Other JRules component may reference this default JNDI name to access the XU (Figure 7).
   
   Figure 7. Deploy XU as resource adapter in WebSphere Process Server
   
   
   
3. Deploy the execution management EAR to Process Server (Figure 8). The execution management EAR is a J2EE compliant JRules management application, which provides a management console to deploy, navigate, configure, and manage all the rule applications deployed to the rule execution server. The execution management EAR is found at JRulesInstallDir\executionserver\applicationservers\WebSphere7\ jrules-res-management-WAS7.ear.
   
   Figure 8. Deploy the execution management EAR to WebSphere Process Server
   
   
   
4. Configure the security for the JRules runtime. The JRules execution server defines several security roles to restrict access to its MBean. WebSphere Application Server provides a security infrastructure and mechanisms to protect sensitive JEE resources and administrative resources. To secure access to JRules, you need to enable global security for Process Server (Figure 9).
   
   Figure 9. Enable global security for WebSphere Process Server
   
   
   Second, you need to define three user groups for JRules Figure 10):
   • resAdministrators
   • resDeployers
   • resMonitors
   Then, you need to define members for each user group (Figure 11):
   • resAdmin
   • resDeployer
   • resMonitor
   
   
   Figure 10. Define user groups for JRules in WebSphere Process Server
   
   
   
   
   Figure 11. Define users for JRules in WebSphere Process Server
   
   
   To access the MBeans of the Rule Execution Server model, an application must have sufficient security credentials. Therefore, you need to map the security roles defined by the execution server to the correct user groups (Figure 12).
   
   Figure 12. Map security roles for JRules execution server
   
   
   

Now the basic components of JRules runtime are integrated in Process Server. They are ready to develop and deploy the rule application to JRules running on Process Server. The business process can invoke the rule set as its decision service node via various bindings.

Back to top

Invoking business rules from within a business process

Figure 13 shows the invocation model defined by JRules.

Based on XOM, the execution object model defined in the rule application, the client can invoke the rule set deployed in the Rule Execution Server via various methods, such as POJO, EJB (remote or local), JMS, and so on. At the same time, JRules also provides a transparent decision service so that the client can access the rule set via a Web service using SOAP/HTTP. In this article, the client to JRules is the business process deployed in Process Server. Therefore, different invocation methods correspond to various SCA components in Process Server. Table 1 summarizes various JRules invocations.

The following sections illustrate each invocation method in detail.

Invoking rule service using the POJO session

SCA POJO invocation has high efficiency because it does not need to serialize or deserialize for input and response parameters. However, the limitation is that only local invocation is supported. That means the JRules execution server is required to be located at the same JVM as Process Server, where the calling business process resides. Figure 14 shows the model of the rule set invocation using SCA POJO component.

In this model, a SCA POJO component invokes the APIs provided by jrules-bres-session-WAS7.jar, which invokes the XU to access the rules set and to return the result to the SCA POJO component. Listing 1 shows a Java snippet that invokes JRules using a POJO session.

Map inputParameters = new HashMap();
String strAMERICASPricing = serialize(AMERICASPricingSdo,
	  	"http://AMERICAS_Pricing", "AMERICAS_Pricing");
inputParameters.put("AMERICASPricing", strAMERICASPricing);

//Get the session factory for a Java rulesession invocation
IlrSessionFactory sessionFactory = new IlrPOJOSessionFactory();
IlrSessionRequest request = sessionFactory.createRequest();
request.setRulesetPath(IlrPath.parsePath(rulesetPath));
request.getInputParameters().putAll(inputParameters);

//create a stateless rule session
IlrStatelessSession ruleSession = sessionFactory.createStatelessSession();
IlrSessionResponse result = ruleSession.execute(request);

Map outputParameters = result.getOutputParameters();
String strOutAMERICASPricing = (String) outputParameters.get
 ("AMERICASPricing");
DataObject response = createResponse("http://com",
 "AMERICAS_Pricing_RuleProjectExecutionResult");
response.set("AMERICASPricing", deserialize
(strOutAMERICASPricing,"AMERICAS_Pricing"));

JRules provides a Decision Service Wizard in Integration Developer to generate the SCA POJO component automatically (Figure 15).

Invoking rules using an EJB session

Rule services deployed in ILOG JRules can be accessed via EJB invocation, locally or remotely. Figure 16 shows the model of rule set invocation using EJB bindings.

Figure 16 shows that the client application invokes the rule service using a rule session (IlrStatelessRuleSession or IlrStatefulRuleSession). In the rule session, IlrStatelessRuleSessionEJB or IlrStatefulRuleSessionEJB will be invoked. IlrStatelessRuleSessionEJB and IlrStatefulRuleSessionEJB can reside at different JVM from client. In turn, IlrStatelessRuleSessionEJB or IlrStatefulRuleSessionEJB will invoke the rule set running on the XU locally. In ILOG JRules, IlrStatelessRuleSession, IlrStatefulRuleSession, IlrStatelessRuleSessionEJB, and IlrStatefulRuleSessionEJB are all packaged in jrules-res-session-WAS7.jar. In Process Server, the client will be the scenario running in Process Server that invokes the rule service. The server will be the application server where the ILOG JRules execution server is located.

Listing 2 shows a Java snippet that invokes the rule service using an EJB session.

//Sets IN and INOUT parameters.
Map inputParameters = new HashMap();
String strCreditpricing = serialize(creditpricingSdo,"http://creditpricing", 
   "CreditPricing");
inputParameters.put("creditpricing", strCreditpricing);

Properties properties = new Properties();
properties.put(JAVA_NAMING_FACTORY_INITIAL, INITIAL_CONTEXT_FACTORY);
properties.put(JAVA_NAMING_PROVIDER_URL, ENGINE_URL);

IlrSessionRequest request = new IlrSessionRequest(rulesetPath);
request.getExecutionSettings().getInputParameters().setParameters
 (inputParameters);

//Get the provider for a Remote EJB
IlrRuleSessionProvider rsProvider = new IlrRuleSessionProviderFactory.Builder(
    properties).setJNDINameOfRuleSessionStateless(JNDI_NAME).build();

//create a stateless rule session
IlrStatelessRuleSession ruleSession = rsProvider.createStatelessRuleSession();
IlrSessionResponse result = ruleSession.executeRules(request);

ilog.rules.bres.session.IlrSessionParameters outputParameters = result
					.getExecutionResult().getOutputParameters();

String strOutCreditpricing = (String) outputParameters.getObjectValue
 ("creditpricing");
DataObject response = createResponse("http://com", "PricingrulesExecutionResult");
response.set("creditpricing", deserialize(strOutCreditpricing,"CreditPricing"));

JRules provides a Decision Service Wizard in Integration Developer to generate the SCA POJO component with the EJB invoking the code automatically (Figure 17).

Invoking rules using a Web service

The rule service can be accessed from within Process Server via a Web service. ILOG JRules uses the transparent decision service to provide Web service access for the rule set. Two types of transparent decision services are provided by JRules:

• Hosted transparent decision service: This is essentially a rule set deployed as a Web server. It is installed on the same application server as the Rule Execution Server, and then integrated with the Rule Execution Server.
• Monitored transparent decision service: This is generated by the Rule Studio and resides on the same application server as the Rule Execution Server, but not integrated with it. The decision service remains independent of the Rule Execution Server, but accesses it to execute the rules.

For the monitored transparent decision service, the only supported application servers are JBoss and Tomcat. Therefore, only the hosted transparent decision service is used when integrating with Process Server. Figure 18 illustrates using the hosted transparent service to access the JRules service.

To use a Web service to access the rule set, the hosted transparent decision service (jrules-res-htds-WAS7.ear) is deployed to the same Process Server, where the Rule Execution Server is located. It can be the same or a different host from the calling business process.

First, to invoke the rule set using a Web service, you need to export WSDL for the target rule application from the Rule Execution Server console (Figure 20).

Then, in Integration Developer, import the WSDL file to the SCA module that will invoke the rule service and specify the interface defined in the WSDL file for the Web service binding import.

Invoking rules using JMS

A business process can invoke the rule set running on JRules asynchronously using the message standards of Java Message Service (JMS). Figure 21 shows the model for invoking the rule set using JMS.

Figure 21 shows that the client application invokes JRules services using the message standards of JMS. It sends JMS messages to a message destination, which the message-driven rule bean (MDB) is listening to for the arrived messages. The MDB, or JRules MDB, is an enterprise bean working as the message listener. Inside the bean, IlrRuleExecutionBean is the queue MDB and IlrRuleExecutionTopicEJB is the topic MDB (Listing 3). You can assign the destination of the message-driven rule bean using application server resources.

<message-driven>
 <ejb-name>IlrRuleExecutionEJB</ejb-name>
 <ejb-class>ILOG.rules.bres.mdb.ejb.IlrRuleExecutionBean</ejb-class>
 ...
</message-driven>

<message-driven>
 <ejb-name>IlrRuleExecutionTopicEJB</ejb-name>
 <ejb-class>ILOG.rules.bres.mdb.ejb.IlrRuleExecutionBean</ejb-class>
 ...
</message-driven>

When a JMS message arrives, the EJB container calls the onMessage method of the MDB IlrRuleExecutionBean or IlrRuleExecutionTopicEJB. IlrRuleExecutionBean or IlrRuleExecutionTopicEJB can reside locally or remotely from the client application. In turn, the MDB calls the rule sets running in the XU. The real invocation of the rule engine is delegated to a simple rule session.

After the rule engine processing, the MDB takes charge of sending response messages, if there are any. It posts the result to the JMS response destination specified by the JMSReplyTo header.

In JRules, the implementation classes of the MDB IlrRuleExecutionBean and IlrRuleExecutionTopicEJB for WebSphere Application Server are packaged in jrules-res-mdb-WAS7.jar.

You need to package jrules-res-mdb-WAS7.jar in a dummy EAR file and deploy it to the same Process Server as the XU when using JMS to invoke rule set. On the JRules MDB side, you need to define the following resources:

• Configure the following MQ connection factories:
  • Queue connection factory with the JNDI name jms/BRESQueueConnectionFactory.
  • Topic connection factory with the JNDI name jms/BRESTopicConnectionFactory.
• Configure the following queue or topic definitions:
  • Create a queue definition for the JRules MDB to receive a message. We use the JNDI name jms/BRESQueueIn as an example.
  • Create a queue definition for the JRules MDB to respond to a message. We use the JNDI name jms/BRESQueueOut as an example.
  The corresponding topic definitions need to be defined if the topic needs to be used.
• Configure a message listener port or activation specification to activate the JRules MDB if any message is in the jms/BRESQueueIn queue.

On the client side, you can use an import with JMS binding to send and receive a JMS message to and from the JRules MDB. Since the JRules MDB is expecting a java.util.Map as the payload of a JMS object message, the client SCA application in Process Server is expecting a business object. You need to create a custom JMS data binding that maps java.util.Map to the business object representation in Process Server. Listing 4 illustrates how to use a custom data binding to build a map between the business object and java.util.HashMap.

public class CustomerApplicationDataBinding implements JMSDataBinding {

public int getMessageType() {
	return JMSDataBinding.OBJECT_MESSAGE;
}

public void write(Message message) throws JMSException {
 try {
       ObjectMessage requestMessage = (ObjectMessage) message;
			
       //Get the data object
	DataObject customerApplicationSdo = getDataObject();
	
       // Create the java.util.HashMap
       HashMap inputParameters = new HashMap();

       // CustApplicationObj is the custom object defined in the 
          parameters of rule application  
      // convertSDOToCustApplicationObj converts the incoming SDO to 
         CustApplicationObj 
	CustApplicationObj customerApplicationObj 
              =convertSDOToCustApplicationObj(customerApplicationSdo);
	inputParameters.put("CustomerApplicationObj", customerApplicationObj);
			
      // Set the payload of the JMS Object Message
	requestMessage.setObject(inputParameters);
			
	String rulesetPath = "/" + RULEAPP_NAME + "/" + RULESET_NAME_EMEARULE;
			
	//Set the JMS message header properties.
	requestMessage.setStringProperty("ilog_rules_bres_mdb_rulesetPath", 
     rulesetPath);
	requestMessage.setStringProperty("ilog_rules_bres_mdb_status", "request");
   } catch (DataBindingException e) {
      throw new JMSException(e.getLocalizedMessage());
	}
}

public void read(Message message) throws JMSException {

	//Get the payload of the JMS Object message
	ObjectMessage responseMessage = (ObjectMessage) message;
		
	HashMap parameters = (HashMap) responseMessage.getObject();
		
       CustApplicationObj outCustomerApplicationObj = 
         (CustApplicationObj) parameters.get("CustomerApplicationObj"));
		
	// convertCustApplicationObjToSDO converts the rule application parameter to SDO
	DataObject dobject = convertCustApplicationObjToSDO(outCustomerApplicationObj);
	try {
		// Set the data object
		setDataObject(dobject);
	} catch (DataBindingException e) {
		throw new JMSException(e.getLocalizedMessage());
	}
}
}

Back to top

Monitoring JRules services in WebSphere Process Server

In Process Server, you can monitor the business process based on CEI. All the enabled Common Base Event (CBE) events are emitted to the CEI server and get stored for monitoring purposes. You can use the CBE browser shipped with Process Server to check the generated events when the business process is running. You can also use WebSphere Business Monitor to monitor the specified measurements, such as metrics and KPIs for the business process.

The rule services in ILOG JRules can also send CBE events to the CEI framework, which provides consistent monitoring mechanism with Process Server. These CBE events can provide detailed and integrated audit trails of the JRules services.

JRules provides APIs to emit CEI events. To make it easier, JRules provides a component, ILOG JRules CEI Event Source, for integration with Process Server. This includes the CEIEventBOM module that defines the CEI event BOM and encapsulates APIs to emit CEI events. The rule project can reference the CEIEventBOM module and define a variable with type ilog.connector.ibm.runtime.EventContainer to emit CEI events to Process Server. See the examples in Figure 22 and Figure 23.

Then you can add a code to where the CEI events need to be emitted, as shown in Figure 24.

After the rule set is invoked, you can use the CBE browser to check the events (Figure 25). You can view the audit trails of the rules invocation here, which provide useful information such as the rules fired as well as the flow of rules executed.

Back to top

Conclusion

This article provided an overview on how to integrate ILOG JRules with WebSphere Process Server. It illustrated how to invoke a rule service using different methodologies from a business process, which includes POJO, EJB, Web services, and JMS/MQ. Lastly, it covered how to monitor JRules services through CEI in WebSphere Process Server.

Resources

Learn

• WebSphere ILOG JRules product page
  
  
• Exploring ILOG JRules integration with IBM WebSphere Process Server
  
  
• Integrate ILOG JRules with WebSphere Process Server white paper
  
  
• WebSphere Process Server Information Center
  
  
• WebSphere Integration Developer Information Center
  
  

Get products and technologies

• WebSphere ILOG JRules V7.0.2 trial download
  
  

Discuss

• WebSphere ILOG Business Rule Management Systems forums
  
  
• WebSphere Process Server forum
  
  
• WebSphere Integration Developer forum
  
  

About the authors

Zi Hui Duan (Steven) is a Staff Software Engineer and the Business Process Management Integration Quality Assurance Team Designer at the IBM China Development Lab in Beijing, China. He has in-depth knowledge of SOA, BPM, and J2EE, as well as rich product experiences with the IBM BPM family. Before joining the BPM IQA team, he was a developer of WebSphere Process Server and WebSphere Interchange Server. He also has L3 experience with WebSphere Process Server.

Zhi Qiu Xie (Samuel) is a Software Engineer from the Business Process Management (BPM) Suite Integration Quality Assurance team at the IBM China Development Lab in Beijing, China. He has in-depth knowledge of SOA, BPM, and J2EE, as well as rich product experiences of the IBM BPM family. He has written extensively on BPM stack products. Zhi Qiu is an IBM Certified SOA Solution Designer and an IBM Certified Administrator for SOA Solutions. Before joining the BPM IQA team, he worked for the WebSphere Process Server system validation team.

Hua Cheng (Ted) joined IBM in 2003 and is currently the Business Process Management Integration Quality Assurance Team Lead at the IBM China Development Lab in Beijing, China. He has broad experience in BPM products, including WebSphere Integration Developer, Process Server, Modeler, Monitor, and Adapters. He also has in-depth knowledge of Java and J2EE development and product testing. Before his current role, he worked on several WebSphere Process Server development and test projects, including as the WebSphere Process Server component owner, development lead, and test lead.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Overview
• Integrating ILOG JRules with WebSphere Process Server
• Invoking business rules from within a business process
• Monitoring JRules services in WebSphere Process Server
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere ILOG JRules
• Demo: WebSphere ILOG JRules features
• Article: Five ways to fast ROI: WebSphere ILOG BRMS can help
• Community: Developer blog: WebSphere ILOG BRMS
• Buy: WebSphere ILOG JRules

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers