Business Process Management using jBPM – Part II

Posted: April 7th, 2013 | Author: sabre1041 | Filed under: Technology | Tags: JBoss, jBPM | No Comments »

If we recall the basic requirements for our sample application from the previous blog post, we are simulating an order processing system. Orders enter the workflow and depending on if the amount of an order, an approval or denial email is sent. Let’s take a closer look at the sample application itself and how jBPM5 components are integrated.

Process Properties

Within JBoss Developer Studio, the properties view allows for the manipulation of components of the business process. If the properties view is not present, it can be opened by navigating to Window -> Show View -> Properties. With the business process of the sample application open in the BPMN process designer, select any empty area of the process which will bring up the general properties of the process in the properties view.

Most of the properties are fairly self explanatory. The Id identifies the business process itself using the typical Java naming convention. The variables property defines the names of global process instance variables which can be referenced throughout the workflow. We will use these variables momentarily.

Script Tasks

A script task is one of the available activities which can be performed during the execution of the process. All activities have one incoming and outgoing connection, an ID which identifies the node, and a display name which displays the name of the node. A script task represents a script that should be executed at a given point of a process which can be written in either Java or MVEL dialect. In jBPM3, a script task is comparable to a Node which implements the ActionHandler interface. In our sample application, we used a Script Task at the beginning of the workflow to ensure certain required process variables are present within the process, otherwise they will be created. The script task can be inspected by selecting the script task next to the start of the process. In the properties view, the action the Script Task performs can be inspected by clicking the … button in the value section of the Action property. This will bring up the Action editor.

Let’s review some of the components of the Action editor. At the top, there is a dropdown to select whether to use Java or MVEL for the dialect of the script. The imports button allows for external libraries to be imported into the script. For the script task above, we use the Random class to choose a random value between 50 and 150 to simulate the amount of an incoming order. Because of this, the java.util.Random class must appear in the imports section. Please note that all script tasks share a common set of imports so adding imports in other Script tasks will add the imports to all Script tasks. Global’s are any variables that have been defined globally in the Knowledge Session. In this script, we are using the “user” global variable. We do not need to specify the variable in the globals section in the Script task because we had already defined this variable in the variables of the business process earlier. You may also notice the kcontext variable which is referenced near the bottom of this script. This variable represents the org.drools.runtime.process.ProcessContext and is available in any Script task. the ProcessContext can be used for a variety of reasons such as getting the current node instance, signaling events, or for what is being used in this example, setting process variables. Process variables are set by referencing the name of the variable and the value which should be applied.

Gateways and Constraints

Gateways allow for multiple paths of execution through a process. There are two types of gateways in jBPM5: diverging and converging gateways. A diverging gateway has one incoming connection and two or more outgoing connections. This is comparable to a Fork node in jBPM3. Diverging gateways can have the following types: AND or XOR. An AND, or parallel, type allows the flow of control to continue along all outgoing branches simultaneously. An OR, or exclusive, type allows the flow of control to continue along only one outgoing connection. At least one connection must evaluate to true otherwise an exception will be thrown. A converging gateway has two or more incoming connections and one outgoing connection. In jBPM3, this is known as a Join node. Depending on the type of diverging gateway, the diverging gateway will performed differently. An AND type will wait for all incoming branches to complete before allowing the process to complete continuing. An OR type will allow for the process to continue as soon as the one active incoming branch to complete. To configure the diverging gateway in the sample application, select the diverging gateway. Notice the type is selected as an XOR because only one path of execution should be selected. The paths of execution are based on constraints defined on the gateway. There are two types of constraints: code constraints and rule constraints. Code constraints are Boolean expressions which are evaluated when they are reached and can either be in Java or MVEL dialect. A rule constraint is equal to a normal Drools rule condition and written in the Drools Rules Language. To view the constraints being applied to this gateway, select the … button on the value component of the constraints property. The edit constraint dialog lists all of the outgoing paths of this diverging gateway. Click the edit button next to each constraint which will bring up the Constraint editor.

This editor is similar to the Script editor as shown earlier as it has a dropdown for dialect and sections for configuring imports and globals. In our sample application, the constraint editor is used to set a result variable which indicates the outcome of the decision process. In addition, a Boolean value indicating whether the amount of the order is over or under the threshold amount of 100 is returned which will be used by the gateway to determine the path of execution for the overall process.

Sending Emails

Emails are sent using an Email Task. An Email Task is a type of Service Task which represents an abstract unit of work which should be executed within the process. Once again reviewing the requirements of the sample application, an email should be sent containing the user id, amount of the order and the approval decision. To send emails in jBPM5, we need to configure the following:

• An email service node for each type of email being sent
• A work item handler

An email service node has been added after each diverging gateway constraint. Selecting one of these nodes, we can review the available properties for review.

The properties we are most concerned about for the Email task are the To, From and Subject properties which designates the recipient, the sender and the subject of the email. Set these values accordingly. Finally, the most important property from the end users point of view is the body which contains the contents of the email message. We can inject process variables into the body of the message by using #{expression} . In our email message, we are injecting the user and amount variables. We could have used the result variable set earlier in the decision constraint, but since we already had two separate email service tasks, it was not chosen to be included.

Every service task must have a work item handler associated with it. A work item handler is responsible for completing the work and notifying the workflow the tasks associated with the work item has completed or failed. Work items can be programmatically configured and attached to the KnowedgeSession or set via configuration files. Two configuration files are present in the sample project and located in the /src/main/resources/META-INF folder. The first file we will look at is the CustomWorkItemHandler.conf file. This is where we will define our work item handler. Using the MVEL dialect, we can configure all of the work item handlers we will need for our workflow. We will only need to configure one work item handler and it is the out of the box EmailWorkItemHandler. To configure the work item handler, we must specify the name of the Service Task (Email) and the work item handler itself. The EmailWorkItemHandler requires the configuration of an outgoing email server as part of its’ constructor signature. An outgoing server address, port number, user name and password are required.

Configure this file with the appropriate values for your environment. Finally, we need to tell the drools session to utilize these work item handler configurations. We set the property drools.workItemHandlers property in the drools.session.conf listing all of the files containing custom work item handlers. As you can see, we are referencing the CustomWorkItemHandler.conf file from above.

drools.workItemHandlers = CustomWorkItemHandlers.conf

With these configurations successfully set, our workflow will be able to successfully send email notifications. The final step in our workflow is to log a message to the server console indicating the result of our workflow. To do this we use two additional script tasks, one on each branch of the workflow. Using the concepts demonstrated earlier, we use the java dialect to build a message, reference process variables and then finally print out the message to the console.

After the script task completes, the workflow reaches the end event and completes.

---