The drools-examples project contains a sample process (org.drools.examples.process.order) that illustrates some of the advantages of being able to combine processes and rules. This process describes an order application where incoming orders are validated, possible discount are calculated and shipping of the goods is requested.
Drools Flow can easily include a set of rules as part of the process. The rules that need to be evaluated should be grouped in a ruleflow group (using the ruleflow-group rule attribute) and a RuleSet node can be used to trigger the evaluation of these rules in your process. This example uses two RuleSet nodes in the process: one for the validation of the order and one for calculating the discount. For example, one of the rules for validiting an order looks like this (note the ruleflow-group attribute, which makes sure that this rule is evaluated as part of the RuleSet node with the same ruleflow-group):
Rules can be used for expressing and evaluating complex constraints in your process. For example, when a decision should be made which execution paths should be selected at a split, rules could be used to define these conditions. Similarly, a wait state could use a rule to define how long to wait. This example uses rules for deciding the next action after validating the order. If the order contains errors, a sales representative should try to correct the order. Orders with a value > 1000$ are more important and a senior sales representative should follow up the order. All other orders should just proceed normally. An decision node is used to select one of these alternatives, and rules are used to describe the constraints for each of them:
Human tasks can be used in a process to describe work that needs to be executed by a human actor. Which actor could be based on the current state of the process, and the history. Assignment rules can be used to describe how to the actor based on this information. These assignment rules will then be applied automatically whenever a new human task needs to be executed.
Rules can be used for describing exceptional situations and how to respond to these situations. Adding all this information in the control flow of the main process would make the basic process much more complex. Rules can be used to handle each of these situations separately, without making the core process more complex. It also makes it much easier to adapt existing processes to take new unanticipated events into account.
The process defines the overall control flow. Rules could be used to add additional concerns to this process without making the overall control flow more complex. For example, rules could be defined to log certain information during the execution of the process. The original process is not altered and all logging functionality is cleanly modularized as a set of rules. This greatly improves reusability (allows users to easily apply the same strategy on different processes), readability (control flow of the original process is still the same) and modifiability (you can easily add, remove or change the logging strategy by adding, removing or changing the rules, the process should not be modified).
Rules can be used to dynamically fine-tune the behaviour of your processes. For example, if a problem is encountered at runtime with one of the processes, new rules could be added at runtime to log additional information or handle specific cases of the process. Once the problem is solved or the circumstances have changed, these rules can easily be removed again. Based on the current status, different strategies could be selected dynamically. For example, based on the current load of all the services, rules could be used to optimize the process to the current load. This process contains a simple example that allows you to dynamically add or remove logging for the 'Check Order' task. When the 'Debugging output' checkbox in the main application window is checked, a rule is dynamically loaded to add a logging statement to the console whenever the 'Check Order' task is requested. Unchecking the box will dynamically remove the rule again.
Processes and rules are integrated in the Drools Eclipse IDE. Both processes and rules are simply considered as different types of business logic, but are managed almost identical. For example, loading a process or a set of rules into the engine is very similar:
Our audit log also contains an integrated view, showing how rules and processes are influencing each other. For example, a part of the log shows how the '5% discount' rule is executed as part of the 'Calculate Discount' node.
Rules do not need to be defined using the core rule language syntax, but they also can be defined using our more advanced rule editors like domain-specific languages, decision tables, guided editors, etc. Our examples defines a domain-specific language for describing assignment rules, based on the type of task, its properties, the process it is defined in, etc. This makes the assignment rules much more understandable for non-experts.