Putting It Together

We have seen Process Choreography and Business Rules in this chapter. Process Choreography enables us to create new business processes, leveraging the various assets already in our business model. We also have some business rules in our business model, which help our systems react to changes more easily and factor out dynamic algorithms and data-driven code.

Is it possible to leverage the business rules and business processes together? Yes it is. Again, that is how business works so that is how we need the systems that run the business to work. Our sample business process of approving and effecting a price change for a given item in our catalog could be modified to leverage business rules.

Assuming now we have decided that the approval process for simple price changes of some nominal percentage no longer requires approval by a human or employee, as it costs more to approve them than it is worth. The new algorithm now becomes:

1. Input and accept item identifier and and percent price change (could be lowered or raised)

2. Get price of inventory item

3. If the price change is less than x%, then approve it automatically

4. Otherwise drive it thorugh a human interaction for approval

5. Set price to current price multiplied by the requested increase

The challenge is that the x% can change and for some items it might not apply. This is at least what the business policies of the day seem to be. So to put in a solution that will adapt, we will leverage business rules in our business process.

A refactored business process will look like this:

After the request is received and the information on the existing price is retrieved, we will now call a sub-process that will take care of the approval activity.

Instead of a staff activity that always gets put on a worklist, we will add an automated approval process as shown here:

The screenshot shows that the first step is going to the PriceIncreaseRule. This rule will determine if the price is to be increased automatically (the true condition, Step 3 from above), or if human staff activity is required for approval (in case not true, Step 4 from above).

The PriceIncreaseRule is a session EJB that fires a business rule into the Rules Infrastructure. The EJB has a trigger point in it that takes in the current price, the itemID, and the requested increase. The business rule implementor consults the rules database for the currently allowed percentage of increase or decrease.

This models the business requirement and leaves flexibility in the design. A simple servlet application, to be run by someone who has the authority to change the business policy, could change the percentage increase or decrease allowed for automated updates. This can all be done without re-deploying any EJBs or business processes.

If in the future, or even at certain points during the year, if we wish to have more rules fire for that trigger point, such as a rule that would only allow automated price changes on items less than a certain price, it can be done transparently from the EJB and the business process that drives it.

This short example mixes together rules and business process and demonstrates the power of these two features working together.