Using loosely coupled rules in your process

Acknowledges

This article is inspired by the blog article of Maciej Swiderski that applies to version 7 of jBPM.
The code provided is a partial backport of the standard Work Item Handler coming with version 7 and is tested on Red Hat JBoss BPMS v6.4.

Introduction

One of nice capabilities of the Red Had BPMS platform is managing rules and processes at the same level. The API are uniform and the developer can build an interconnected solution made of processes and rules, getting the best of two worlds.
Nevertheless, there are some situations where the developer want to separate rules from processes for many different reasons, among others:

• Rules follow a different life cycle, usually shorter than processes
• Rules should be exposed for reuse across different applications
• Rules and processes stakeholders are different
• Better separation of concerns

In this article, we will see how to invoke from a process rules that are defined in a separated project (kjar). This will be accomplished running the rules in the same process runtime with the benefit of avoiding any latency due to a remote invocation.

The fact model project

First of all, we have to split the facts from rules in two different projects. This is in general a good practice, but in our case it is essential, because the fact model has to included in the process project as a dependency.
In fact, it can be considered the external contract between the rules and their client. The usual interaction with the rule engine is to add facts to the working memory, to fire the rules and finally to retrieve the modified facts. In other words, the facts are the data exchanged between the two worlds.
Since the rules and processes has to share the same classes, the jar file should be configured at high level in the loading hierarchy. For example, it can be placed in the WEB-INF/lib of the process runtime (Business Central, Kie Server or custom).

In order to run the sample provided, follow these steps:

1. Launch mvn install for each the maven projects.
2. Copy the fact model jar file in the WEB-INF/lib of the runtime (rule-fact-model/target/rule-fact-model-1.0-SNAPSHOT.jar)

You can find the sample code on dynamic rule invocation example on github.

Reusing the work item handler in your process

In order to use the “loose-rule-wih” in your BPM project, you can import it through the service registry and set it up to point to your rule project:

1. In the github repository you can find a special folder called services-repo
2. Open your process diagram and click on the service discovery icon
   
3. In the service discovery dialog, fill the URL field with the absolute path to the services repository in my case: file:///home/donato/git/demo-rule-wih/services-repo
4. Select Connect button
   
5. Click on the wrench icon to load the Work Item Handler definition in your project

This simple procedure configure all for you:

• create the work item definition file
• add the image file for the work item handler task
• add the dependency to the work item handler project
• configure the work item handler in the deployment descriptor

To complete the configuration open the deployment descriptor and change the placeholders with your actual reference to you rule project:

1. Open the project editor and select the deployment descriptor
   
2. Edit the loose-rule in Work item handler section, the constructor parameters have to match the rule project GAV (group, artifact, version). The last parameter is the number of milliseconds for the rule scanner; by default it is 10000, so every 10 seconds the work item handler look up for new rules project release in the maven repository.
   In our sample, the identifier should be new loose.rules.wih.LooseRulesWorkItemHandler( "example", "rules", "1.0-SNAPSHOT", 10000 )