Business Process Management with Red Hat Process Automation Manager [Part 1 of 2]

Today's business world is all about efficiency. Business processes grow and become more and more complex, and our client's need technology that can keep up, keep automated, and keep those processes working. How do we go about this? Using a business process management platform such as Red Hat Process Automation Manager is a step in the right direction. Instead of keeping all business rules in a monolithic architecture, we can break them down into their own individual services. By breaking these processes and rules down into a microservice architecture, we can save time by reusing rules, we can manage each service's life cycle independently, and when we need to work on one process, we don't have to shut the rest of them down. Today, I would like to demonstrate how we can use Red Hat Process Automation Manager to create one of these microservices.

This demonstration will touch on:

• Red Hat Process Automation Manager Workflow

• Data Objects (Fact Model)

• Validation using Drools

• Human Intervention (Task Server)

• Process Execution Server (Part 2)

For the purposes of this demonstration I have built a simple workflow based on a use case for a company that requires resellers to fill out an application before they are approved to purchase at wholesale rates. First, I created the basic workflow for my process. It includes a simple form validation task to confirm field inputs, and a user task as the final form approval.

Second, I created a data object asset titled “ResellerInformation” that contained the form information an applicant would need to provide: name, email, tax ID, and other even less interesting fields. The data object can then be assigned to a process variable, (I named mine "ResellerForm" to further demonstrate my creativity), allowing the data object to be accessed within the workflow. Below are examples of the Data Object 'ResellerInformation' and the Process Variable mapping.

The boolean 'status' identifier will update to true or false based on the form validation drools.

Step three is to set the data inputs and outputs for the Validate Form task, and to create the validation rules using Drools. I will use the data object and process variable I previously defined to do this. Below I am telling the task that it should expect an object of type 'Reseller Information' from the 'ResellerForm' source and I am naming it targetResellerApp.

The 'targetResellerApp' is the variable used within the drools file to access the input data object, and run the rules on it. For the purposes of this example I have created a simple rule titled "Check Name." As the enigmatic title might suggest, my rule checks to see if the "name" field of the form has been filled out or left blank. If blank, the form 'status' is marked false- meaning the application is denied. The example below shows the syntax of the rule; and remember to give your task the correct workflow group as defined in your rules file!

Next I set up the user intervention Form Approval task. In the diagram properties for the task, provide a name and description, as well as the users that will have permission to claim the task. For the data assignments, I used the same assignment as the targetResellerApp in the Validation task.

At this point we are ready to build the project and deploy it to an embedded process execution server within business central. In the next post we will demonstrate how to view the process definitions and instances, and how to see your workflow in action. I will also provide examples of interacting with your process execution server via the REST API.