Business applications often require logic that changes frequently to meet the dynamic needs of the enterprise. While this logic can be coded in Java, the resulting application cannot be quickly adapted when change is required. BEA WebLogic Portal includes a rules engine that, together with a WebLogic Integration business process, provides an alternative solution that allows rapid changes to business logic without changing Java code. In this article, we review how the rules engine works and the steps required to incorporate it into a WebLogic Integration (WLI) process. We also describe how JavaBeans can be used in the rules engine to describe an arbitrary set of objects for the rules to act on and provide actions for back-end processing. Finally, we describe how the Datasync facility of WebLogic Portal can dynamically update a set of rules on a running system without redeploying the application.
The needs of a business application are constantly changing in response to shifting currents in the business environment. Decisions are rarely static, and competitive pressures demand flexibility in the design and implementation of business logic to accommodate rapid response to changing needs. Traditionally, changes to business logic must be made by the development staff and then thoroughly retested, which can be a time-consuming process. When the revised application is finished, it would need to be redeployed on the server, requiring scheduled downtime when the application is unavailable to users.
A better solution to this problem is to implement some of the business decisions via a set of rules external to the application. Rules are not compiled into the application, but rather, are read and applied at runtime. In this way, the rules can be changed without changing code or stopping the running application.
WebLogic Portal includes a basic rules engine that can be used to bring benefits of rules to WebLogic Platform applications. While the engine is not a full-featured product, we will show how it can be used with WebLogic Integration Business Processes (JPDs) to provide a flexible and dynamic mechanism for implementing business logic without requiring that the application be redeployed just to modify the rules.
We first look at the example application used throughout the article, then at how to inject a rules engine into a WLI process to implement the business logic. We'll then look more closely at just what rules are and how we can define them for business logic, and finally describe the mechanism used for modifying the business rules in a running system.
As an example of using rules within a business process, we will develop a sample trading application. The trading application is a simplified version of a financial trading process built using a (JPD) business process that invokes the rule engine. The sample application takes a collection of individual securities trades and groups them together according to a set of business-defined rules into blocks of trades for execution, perhaps to reduce commissions. Of course, the application presented here is by no means complete, but it is sufficient to demonstrate how the rules engine can be used in real-world applications. The complete source code for the sample is available for download, and instructions for building and running the application are included in the readme file in the download.
Before we explain how to develop such an application, we'll first see how the portal rule engine works with a brief overview of some its features. The explanation assumes you are familiar with rule technology in general.
The basics of the rules engine are illustrated in Figure 1. The engine processes an initial set of facts according to a set of rules, which it gets from an external repository. The initial facts are used to populate working memory for the engine. Rules are evaluated given the facts in working memory, and if conditions for a rule are met, its corresponding action is executed. Normally, a rule action adds a new fact to the working memory, and the process repeats until no more rules can be applied. An optional filter then selects objects of specified classes to return to the caller. The rules engine is made accessible via the Controls interface, which is also used to set properties such as the location of the rule set file.
Figure 1: The rules engine is an EJB wrapped by a control. Rules from the repository are iteratively applied to the facts in working memory to derive new facts. After no more inferences can be drawn, the working memory is filtered to return only items of interest.
Let's start by taking the trading business process implemented as a JPD and look at how to add a call to the rules engine. To add rules to a WLI process, we use the rules executor control provided as part of WebLogic Portal. For this example, we use only a subset of the methods and features available in the control. Additional documentation on the rule controls can be found in the references.
For this discussion, we assume that the developer is using the WebLogic Workshop IDE to create a new process application. A process project is then created within the application. Since the portal controls are not available by default from within a process project, it is necessary to import these controls and the EJBs for the rules engine into the application. Then, the inputs and outputs for the control must be plumbed into the JPD. The basic steps for using the portal rules engine from within a WLI process are:
Import the rules engine into the application:
Process inputs and outputs:
We discuss each of these steps in further detail in the sections that follow.
The Rules Engine is contained in the file:
To include the engine in the application, right-click on the
Modules folder in the Workshop IDE and choose
Add Module. Navigate to the jar file and select
To make the portal rules controls available to the application, right-click on the Libraries folder in the Workshop IDE and choose Add Library. The controls are located in:
After navigating to the file, click the Open button.
The Rules Executor control method used here requires an array of objects as input and returns an iterator of results. Create variables in the Workshop IDE for these values so that we can create the control via the GUI in the next step. To do this, click the
Add button for variables in the
Data Palette, enter a name for the input variable, and enter the Java type
java.lang.Object. Create the output variable in similar fashion with Java type
To create the rules control, click the Add button for controls in the Data Palette. From the menu, choose Portal Controls -> Rules Executor. Enter a name for the control and press the Create button.
Drag-and-drop the newly created control into the process to create a control node to actually invoke the rules engine. In our example, we use the
evaluateRuleSet() method of the control. From the
Send Data panel, choose the input variable created above for the input argument to the method. Use the
Receive Data panel to select the return variable to retrieve the results from the execution of the rules. Enter values for control properties in the Property Editor window.
When we created the input variable, we did not assign it any value, so we need to write code to do that. This variable is an array of Java objects that provides the initial facts that are input to the conditions in the rules. You may either create a new Perform node to initialize this array, or use Source View to add code in the Control Send node to set the value of this variable.
Each evaluate method from the Rules Executor control returns an iterator of results. Write code to use this value to iterate over the results of the rules execution. If a filter class was not specified, the iterator will return all values in working memory for the rules engine. These include both the original input plus any values that were added to working memory while executing the action of rules whose conditions were met. For the added objects, the iterator returns an object of class
getObject() method of this class returns the actual object that was added in the rule action.
Using your favorite XML editor, create a file under the directory
/META-INF/data with a
.rls extension. Rules are usually added in the subdirectory
Pages: 1, 2