Create and execute business rules in IBM Integration Bus

The new business rules feature in IBM® Integration Bus V9 (formerly known as WebSphere® Message Broker) enables you to create business rules that are executed in the integration server. This article describes the business rule integration, demonstrates how to use it, and answers some frequently asked questions. This content is part of the IBM Business Process Management Journal.

Share:

Callum Jackson (callumj@uk.ibm.com), IT Specialist, IBM

Photo of Callum Jackson Callum Jackson is an IT Specialist in IBM Software Services for WebSphere, based in Hursley, UK. He specialises in consulting on IBM Integration Bus, IBM Operational Decision Manager, and other Connectivity and Integration products. Prior to joining Software Services for WebSphere, he was a Software Engineer on the IBM Integration Bus team, and before that he worked in Software Services on SOA applications for the telecommunications industry.



28 August 2013

Overview

This article gives an overview of the new business rules capability in IBM Integration Bus V9 (Integration Bus). The business rule capabilities use IBM Operational Decision Manager (ODM) technology to execute the rules in the runtime. The rule engine can load and execute rules either from a local Integration Bus repository or an external configurable repository managed by a full ODM solution. This article is separated into five sections:

  • Overview of business rules
  • Overview of Operational Decision Manager
  • Overview of IBM Decision Server Rules Edition for Integration Bus
  • Out-of-the-box experience
  • Collaborating with an existing ODM topology
  • Frequently asked questions

Overview of business rules

Business rules provide a natural means for line of business users to manage policies that determine how frequently occurring decisions can be automated. The automation of complex business decisions has many applications, such as targeted promotions for certain customers based on their geographical location or determining insurance cost based on driving record.

These rules can be created using a number of different tooling options, allowing the author to select their preferred method. For instance a developer may create business rules within an Eclipse environment, while a business user may prefer a web UI or Microsoft® Office® products. Regardless of the program used to create the business rules, two main constructs are supported:

  • Traditional IF <condition> THEN <action>, enabling a user to define a condition and corresponding action. These rules can be used to express a policy that identifies particular actions to take whenever a specific condition arises, as shown in Figure 1.
    Figure 1. IF, THEN, ELSE business rule
    IF, THEN, ELSE example business rule
  • A decision table, where a single row defines the entire business rule. In a decision table, the conditions and actions are represented as columns in the table, while each row represents a range of conditions and the resulting actions to take for that range. This approach enables business users to quickly understand the behavior of a decision in a familiar tabular form, as shown in Figure 2
    Figure 2. Decision Table Business Rule
    Decision Table Business Rule

The business rule author can select whichever authoring tooling or representation he or she prefers and the rule engine will execute regardless.

Although business rules in IBM Integration Bus could be used for almost any logical decision, this is not recommended. Existing technologies such as Compute, Java™ Compute, PHP, .NET, and Route nodes are powerful techniques for IT-based logic. The business rules capabilities are aimed at business-level decisions within flows, where these may need to be discussed, written, or updated by business users who may be unfamiliar with IBM Integration Bus. For instance, a flow may process an inbound stock trade message and based on its overall trade value, the message may be sent to one of two backend systems. One system may provide additional verification and auditing, while the other focuses on high throughput. The business may want to control this routing decision based on legal requirements or changes to the business risk criteria. In this case, using business rules would be a sensible approach so that the logic can be exchanged and in some situations controlled by business users. There are several additional use cases for business rules around business-level validation or transformation of messages.


Overview of IBM Operational Decision Manager

IBM Operational Decision Manager (ODM) combines the functionality of WebSphere ILOG JRules BRMS and WebSphere Business Events. The integration between IBM Integration Bus and ODM focuses entirely on the rules side and does not attempt to enhance the existing integration available for events.

This article describes the high-level components in ODM, but it is beyond the scope of this article to discuss the full capabilities of ODM. For more information, refer to Resources.

Following are some of the relevant features of ODM, as shown in Figure 3:

  • Design time: ODM provides an Eclipse-based tooling environment called Rule Designer for the creation of business rules. This environment also supports many of the Java or integration development environments, which makes it a good environment for development or IT users. This environment is only one of many possible alternatives for rule creation and modifications.
  • Runtime environment: Decision Server provides the core runtime engine for execution of the business rules. External systems can delegate a decision to the Decision Server via a variety of different integration mechanisms, including web services. This allows the flexibility to support the architecture of the solution.
  • Monitoring the runtime environment: The Decision Server console provides the capability to manage and monitor the deployment of business rules on the associated Decision Servers.
  • Management and governance: Decision Center provides a working environment for people to collaborate, share and manage their business rules. This can involve business rules creation or modification of rules, either via the web UI or Microsoft Office. Decision Center also controls the process involved in approving updates before they are deployed to the relevant runtime environment (Decision Servers).
Figure 3. ODM components
Operation Decision Manager components

Overview of IBM Decision Server Rule Edition for Integration Bus

IBM Integration Bus Decision Server Rule Edition provides the capability to either author rules within the IBM Integration Toolkit or on existing ODM tooling environment. The embedded tooling in IBM Integration Toolkit is aimed at first-time users of business rules, and provides a quick and easy mechanism to construct and deploy rules within the Integration Bus development environment without any additional installation or configuration.

If the user wants the full capabilities of the ODM programming model, such as decision tables and rule flows, then the existing ODM authoring capabilities (such as Rule Designer and Decision Center) should be used.

Regardless of the authoring technique, the business rule can be included in an IBM Integration Bus flow and executed inline. There are a couple of restrictions, such as only schema-based rulesets are supported, which either have a schema XOM or parameters that are all based on schema types. For further information, refer to Frequently asked questions.

When authored in the IBM Integration Bus Toolkit, the user can deploy business rules using the normal BAR file deployment model. If business rules have been authored outside of the IBM Integration Toolkit, the user can decide to reference these from an external Decision Server repository or deploy them locally to an integration node. By using an existing decision service database, the IBM Integration Bus Integration Server is included as another runtime environment within the wider ODM estate.


Out-of-the-box experience

This section describes the embedded business rule development environment in IBM Integration Bus and demonstrates how to create a simple example. The scenario we'll use is the routing of a stock trade system in which, based on the overall size of the trade, it is routed to one of two possible services. The completed application and starting artefacts are provided for download with this article.

The following instructions assume the default integration node has been configured. If your set-up is different, the instructions and screenshots will differ slightly. The instructions are divided into four sections:

  • Importing the starting resources
  • Building the decision service
  • Adding the decision service to the message flow
  • Deploying and testing the sample

Importing the starting resources

  1. The sample used in this article utilises MQ queues for receiving and sending requests. To assist with the set-up, a configuration script is included for download to create the required resources. Open the IBM integration console and issue the following command: runmqsc IB9QMGR < CreateMQQueues.txt, as shown in Figure 4.
    Figure 4. Create MQ queues for the sample
    Create MQ queues for the sample
  2. Start the IBM Integration Toolkit.
  3. To allow us to focus on the core business rule integration, a starter application is included in the download package that defines the schema and flow that is used. Import this into the toolkit using the standard approach: File => Import => Other => Project Interchange.
  4. Specify the zip file included for download and import the StockTradeRoutingApplication, as shown in Figure 5.
    Figure 5. Import starting application into the workspace
    Import starting application into workspace
  5. The imported application, shown in Figure 6 includes two resources:
    • StockTrade.xsd: The schema for the message structure
    • RouteRequest.msgflow: An incomplete message flow
    Figure 6. Application imported into workspace
    Application imported into workspace
    The schema is a simplified stock trade request that includes the stock trade information and also an optional target service field. The inbound message will include the four fields associated with the stock trade and the business rule will enrich the message to determine the routing.
    Figure 7. Stock trade schema
    Stock trade schema
    The message flow, shown in Figure 8 includes a single MQ input node that receives the inbound message and two MQ output nodes, one for each trading system. The nodes have been preconfigured with the required queues and parsers.
    Figure 8. Starting message flow
    Starting message flow

Building the decision service

This section describes the process to define a new decision service. A decision service encapsulates the interface, defining the input and output data as well as the implementation using business rules.

  1. To create a new decision service, select File => New => Decision Service.
  2. The Decision Service wizard will appear with two mandatory fields:
    • Container: Specify the containing application or library within which the decision service should be created.
    • Decision service name: The name of the newly created decision service.
    Figure 9. Creating a decision service
    Creating a decision service
    Complete the fields as shown above and click Next.
  3. The data to be used within the decision service is now selected. Select the StockTrade element.
    Figure 10. Select decision service parameters
    Select Decision Service Parameters
    Select StockTradeRoutingApplication => DFDL and XML Schemas => StockTrade {http://www.ibm.com/demo} and check the box. Click Finish.
  4. The decision service editor will automatically be loaded showing the parameters that have been configured in the previous wizard, as shown in Figure 11
    Figure 11. Decision service parameters summary page
    Decision service parameters summary page
    In addition to the information provided in the wizard, it also states the verbalization that will be used within the rule. The verbalization is how the parameter will be represented in the rules, providing the natural language. In addition the field names within the schema will be pulled in. In our example, we want to change StockTrade to the stock trade. In our scenario, this is the only modification required. In other situations the parameters required by the rule may change, and this is where these can be changed without returning to the wizard.
  5. To author the rule, change to the Rule Sequence tab. Here rules are authored using a natural language editor with auto-complete capability provided by using Ctrl+Space. In this scenario, only one rule is required. In more complex situations, additional rules can be added, deleted and reordered as required. Create a rule by entering the following text, as shown in Figure 12.
    if the maximum price of 'the stock quote' is more than 10000
    then set the target service of 'the stock quote' to PREMIER ;
    else set the target service of 'the stock quote' to STANDARD ;
    Figure 12. Rule editor
    Rule editor
  6. Save the changes.

Adding the decision service to the message flow

In the last step, you authored the business rule and defined the required data. In this section, you'll include the rule into a message flow.

  1. Open the RouteRequest flow, and drag and drop the DetermineStockTradeSystem decision service onto the canvas between the input and output nodes, as shown in Figure 13
    Figure 13. Adding a decision service into a flow
    Adding a decision service into a flow
    This creates a new decision service node, with most of the configuration completed.
  2. The final piece of configuration required is a mapping between the message that arrives at the decision service node and the data required by the decision service. In this scenario, the stock trade message required by the decision service needs to be resolved to a location in the inbound message tree structure. Select the decision service node and then select the properties view. You'll see an error message indicating that the data mapping is still outstanding.
  3. Select the StockTrade entry within the Parameter table and click Edit, as shown in Figure 14.
    Figure 14. Decision service node parameters
    Decision Service node parameters
  4. In the Data location window, click Edit.
  5. This opens the standard XPath editor, which enables graphical selection of the data location. Expand the $Root folder, click on the (Add Data Type...), and select StockTrade element, and click OK, as shown in Figure 15.
    Figure 15. Select data type
    Select Data Type
  6. A new Sto:StockTrade [XMLNSC] entry is included in the tree structure. Double-click to populate the XPath expression box, as shown in Figure 16, then click Finish and OK.
    Figure 16. Selecting the XPath
    Selecting the XPath
  7. Return to the message flow. The final node is a routing node, to process the enhanced message from the decision service and pass to either the standard or premier service queue. Expand the Routing folder, and drag and drop the Route node onto the canvas, as shown in Figure 17.
    Figure 17. Add Routing Node
    Add Routing Node
  8. Select the Route node and on the properties dialog, click the Add button associated with the filter table. A pop-up dialog will appear where you can associate the routing logic, as shown in Figure 18. In the Filter pattern field, enter: $Root/XMLNSC/Sto:StockTrade/targetService="PREMIER", then click OK.
    Figure 18. Configuring the routing node
    Configuring the routing node
    This configuration will route all messages with PREMIER as the targetService to the Match terminal.
    Figure 19. Properties of the Routing node
    Properties of the Routing node
  9. Finally, wire the nodes together as follows, and as shown in Figure 20:
    • StockTrade.IN Out Terminal => Decision Service In Terminal
    • Decision Service Out Terminal => Route In Terminal
    • Route Default Terminal => StockTrade.OUT.STD In Terminal
    • Route Match Terminal => StockTrade.OUT.PREMIER In Terminal
    Figure 20. Message flow wiring
    Message flow wiring
    Save the completed message flow.

Deploying and testing the sample

In this section, we'll deploy and test the completed application on Integration Bus.

  1. Deploy the application to the integration server by dragging and dropping the application onto the server, as shown in Figure 21.
    Figure 21. Deploying the application to the runtime
    Deploying the application to the runtime
    When you attempt to deploy the application the following error may be displayed:
    Figure 22. Error during deployment
    Error during deployment
    This means the runtime has not been enabled for business rules. During development and testing, no additional license is required, but in production an ODM Integration Bus license is required. By default the business rule capability is disabled until the administrator explicitly enables it, to highlight this additional license requirement. To enable business rules, run the following command: mqsimode -x DecisionServices.
  2. To test the deployed application, open IBM Integration Explorer, expand the Queue Manager folder, IB9QMGR queue manager, and select the Queues folder. In the MQ Explorer content view, right-click the STOCK.TRADE.IN queue and select Put Test Message, as shown in Figure 23.
    Figure 23. Putting the test message onto the queue
    Putting the test message onto the queue
  3. Copy the following text into the message data field:
    <?xml version="1.0" encoding="UTF-8"?>
    <p:StockTrade xmlns:p="http://www.ibm.com/demo" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.ibm.com/demo 
    ../StockTradeRoutingApplication/StockTrade.xsd">
         <customerID>1234567890</customerID>
    	lt;tickerSymbol>IBM</tickerSymbol>
         <numberOfStock>100</numberOfStock>
         <maximumPrice>20000.0</maximumPrice>
    </p:StockTrade>
  4. The inbound message is processed. Because the maximum value is over 10000, the message is routed to the premier queue for processing. Click the refresh button at the top right to refresh the queue information. The current queue depth associated with the STOCK.TRADE.OUT.PREMIER should be incremented by one. Right-click the queue and select Browse messages, as shown in Figure 24.
    Figure 24. Browsing messages on the output queue
    Browsing messages on the output queue
  5. Double-click the message contained in the list to display the details of the output message. Navigate to the data section and verify that the message contains the correct targetService information, as shown in Figure 25.
    Figure 25. Viewing the output message
    Viewing the output message
  6. Repeat the test with a maximum value smaller that 10,000 to verify that the message is routed to the standard service.

Collaborating with an existing ODM topology

The authoring, functional features, and deployment flexibility provided in the out-of-the-box experience may not be adequate for some users. In these situations the ability to execute rules authored and deployed independently of IBM Integration Bus is provided. This allows the standard ODM development and deployment lifecycle to be used, and separates this from the IBM Integration Toolkit.

When interacting with an externally authored and deployed business rule, the Integration Bus developer needs to import the decision service to establish the data to pass into the decision service node. To enable this, the RuleApp developed within Rule Designer or Decision Center can be imported using the decision service Import wizard within IBM Integration Toolkit and any schema files can be extracted out of the archive.

The standard IBM Integration Toolkit import capability has been enhanced to include the ability to import a rule application archive file and define a decision from that archive, as shown in Figure 26.

Figure 26. Import wizard for externally created decision service
Import wizard for externally created decision service

The wizard allows a rule application archive file to be imported into a container from the existing workspace or external file system, as shown in Figure 27.

Figure 27. Specify ruleApp location
Specify ruleApp location

In order to describe the structure of the ruleset parameters within the message flow and allow the parameters to be mapped to information within the flow, the schema files can be extracted once the rule application has been imported. Right-click on the imported rule application and select Extract XML schema files, as shown in Figure 28.

Figure 28. Extract XML Schema files
Extract XML Schema files

As previously demonstrated, the decision service can be dragged and dropped onto the canvas. When completed for an externally authored decision service, there is a Use decisionServiceRepository configurable service checkbox available for the decision service node. Check this when the decision service should be retrieved from an external decision server database, as shown in Figure 29.

Figure 29. Configure decision service repository on node
Configure decision service repository on node

A configurable service is provided to configure the external decision server, as shown in Figure 30. Optionally, this can also be configured with a notification system, allowing updates that are deployed to the ODM decision server to be immediately available to the rules engine within Integration Bus.

Figure 30. Decision service configurable service
Decision service configurable service

Frequently asked questions

If I'm using the IBM Integration BAR file deployment option for my rules, can I redeploy without my other artefacts?

Yes, this is possible, but you need to structure the projects correctly. The business rule feature maintains the existing application, library and project methodology. Therefore, if you include a business rule within an application (or associated library), and update a business rule, the entire application needs to be redeployed. If you deploy libraries (instead of applications) to an integration server, and include your flows in one library and business rules in another, the business rule library can be updated and deployed independently of the flows and other resources.

What are the restrictions on the types of rules I can include in my flow?

IBM Integration Bus only supports XSD-based XOM business rules. For further information regarding restrictions, refer to Resources.

How do I configure IBM Integration Bus to use an decision server database?

IBM Integration Bus provides a configurable service that allows users to define the ODM connection details. These include an external JDBC connection to a remote decision server database and also a notification endpoint. In addition, the decision service node is configured to enable the Use decisionServiceRepository configurable service option, as shown in Figure 31.

Figure 31. Decision service configurable service
Configure decision service repository on node

Acknowledgements

The author would like to thank Craig Briscoe and Duncan Clark for their review of this article.


Downloads

DescriptionNameSize
Script to create required MQ queuesCreateMQQueues.txt1KB
Starting Project Interchange FileStartingAppPI.zip2KB
Completed Project Interchange FileCompletedAppPI.zip3KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=942213
ArticleTitle=Create and execute business rules in IBM Integration Bus
publish-date=08282013