Decision Driven Business Processes Using Red Hat BPM Suite 6.4

Business Processes as defined by the BPMN 2.0 specifications are usually structured and rigid.  This is great for well-defined end-state business logic.  In another words things don't change much.  In the real world business requirements change often and many times drastically.  Making such changes in rigid business processes can be both risky and time consuming.

The Red Hat BPM Suite 6.x allows for top-level ad-hoc processes that can be driven by signals.  This gives us a flexibility rigid process do not.  In this article I will outline a pattern using ad-hoc processes that can be driven by business decisions encoded in business rules.  This flexibility allows for quick changes without modifying the business processes.

Example Business Case

To show the decision driven business process pattern we will use a simple business case of ordering supplies through the company procurement department.  We have four different actors: the employee (requester) who makes the supplies request, the manager who reviews the request, a procurement specialist who creates an order for the supplies and submits it after approval, and a procurement manager who reviews the order.  The following is a state diagram showing the business flow.

With this we can make a simple BPMN diagram to implement the business logic.  Here we're encoding the business state directly into the human tasks.  That means there are two separate tasks for the procurement specialist: one for when he/she creates the order and the other for when he/she submits the order. 

Transforming the above process into a decision driven pattern, we will make the following changes:

1. Move the business state from the human task into the rules.  Well the business state is still used by the human task to give context but we will inject it as an input to the business state rather than explicitly stated.  This will make the BPMN diagram a bit less intuitive but this allow us to reuse the human task for other business states.
2. Move the flow logic from the gateways to the business rules.
3. Use signals to advance the flow to the next human task.

The resulting business process looks like the following.

And the business rules for the "Determine Next Actor" business rule task look like the following.

Notice the business state is encoded in the instructions to the next human task.

Business Requirements Change

Imagine after the above process has gone to production, we get a request to change it to add some business requirements.  The requirements are to add return flows into the process.  The manager and procurement manager can both return the request/order to be modified.  The following state diagram shows the changes.

Translating these changes into the business process we get the following.

As for the decision driven case, we don't need to change the process at all since all the existing human tasks will serve our purpose.  All we need to do is to change the business rules to add the new business states and flows.

We added two new rules for the return flows and we didn't change the existing rules.

Conclusion

Using an ad-hoc process, signals, and business rules, we defined a pattern for decision driven business processes that are easy to change and maintain.  Business rules in a decision table are easier for business users to modify since the structure is already defined and all they have to do is fill in the data.  So next time you are challenged with implementing a human task heavy business process, try using this pattern!