In this chapter you will see how developers use advance routing rules in Human Workflow. You will learn to use facts, functions, IF/THEN, Decision Tables, Bucketsets, rulesets, decision components, and other features of Oracle Business rules. You will learn to implement business rules using BPM Studio and will customize rules at runtime using BPM Composer.
This chapter will focus on implementation tasks such as the following:
- Extending Human Tasks
- Adding a Business object
- Creating a Dictionary
- Defining Global and Bucketsets
- Defining the rule: Decision Table
- Adding gateways and Human Tasks
- Defining the rule: IF/THEN
- Testing the rules
Business rules focus on decision making and policies. Business rules can be included in cases where you need dynamic processing, Human Task routing, data validations, and so on. A Decision component, also called a Business rule service component, supports the use of Oracle Business rules in an SOA composite application.
Business rules are statements that describe business policies or key business decisions. For example, computations such as discounts or premiums, or say a business rule for a car rental company might specify that if the driver's age is less than twenty-one, the application must be denied. Business rules can perform calculations, such as calculating a credit score, and they can result in changes to the flow by setting values that determine how the process branches.
Rules follow either an IF/THEN structure or can be expressed in a spreadsheet-like format called Decision Tables. You write rules and Decision Tables in terms of fact types and properties. Fact types are often imported from the Java classes, XML schema, Oracle ADF Business Component view objects, or may be created in the Rule designer. Fact properties have a name, value, data type, and an optional Bucketset. A Bucketset splits the value space of the data type into buckets that can be used in Decision Tables, choice lists, and for design time validation.
A decision function provides a contract for invoking rules from Java or SOA (from an SOA composite application or from a BPEL process). The contract includes input fact types, rulesets to run, and output fact types. A ruleset is a group of rules and Decision Tables. A dictionary is a group of rulesets, facts, and Bucketsets. It is an XML file that stores the application's rulesets and the data model.
Business rules can be used as a Decision component or as a library in a Java application. A Decision component is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes. A Decision component can be used within a SOA composite and wired to a BPEL component. It can be used within a SOA composite and used directly to run business rules, or be used with the dynamic routing capability of Mediator, or be used with the advanced routing rules in Human Workflow.
Some facts about Business rules are as follows:
- They use the Rete algorithm as the foundation of Oracle Business rules.
- This rule-based system consists of:
- A rule base which contains the appropriate business policies or other knowledge encoded into IF/THEN rules and Decision Tables
- Working memory, which contains the information that has been added to the system.
- The Inference Engine Rules engine, which processes the rules and performs pattern-matching to determine which rules match the facts for a given run through the set of facts. Oracle Business Rule Engine is an inference-based engine. You just have to load the facts into Rule Memory and it will evaluate the outcome based on implicit inference.
- This rule-based system is a data-driven, forward-chaining system.
- Rules fire sequentially, not in parallel. Note that rule actions often change the set of rule activations, and thus, change the next rule to fire.
- They follow an inference cycle, that is, facts cause rules to fire and firing rules can create more facts, which in turn can fire more rules.
BPM Studio and Business Process Composer, both have Rule designers which you can use during development.
As you are moving ahead and implementing the process as a Process Developer, you will use BPM Studio. However, the Business Analyst and Process Analyst use Business Process Composer. Whatever the tool you use, business rules are deployed to the business rules MDS, which is a data store that interacts with the business Rules engine at runtime.
You modeled the process, as a Process Analyst, in Chapter 1, Process Modeling, and as Process Developer, you implemented the process in Chapter 2, Process Implementation and deployed the process in Chapter 3, Process Deployment and Testing. There are cases when you need to implement rules in the process. Let's say you want to check if a customer is a new customer or an old customer, and if he/she is a new customer you want management approval. Or consider a new customer who has bought a quantity greater than 100, and you can approve a 10% discount to the customer. Such rules can be implemented in processes. However, as you use rules, they become dynamic and one can change those rules at any time without bringing changes in the process (application code) itself. Separating the business rules from application code allows business analysts to change business policies quickly, with graphical tools. The Rules engine evaluates the business rules and returns decisions or facts that are then used in the business process.
You can use Business rules in BPM in the following areas:
- As a component in the BPMN process
- In the BPM Workspace for user-defined task management and vacation rules
- In Human Workflow to identify the proper recipient for a task assignment
- For dynamic service binding in the composite
Once the process is deployed and running, through Business Process Composer, users can read and make changes to Business rules. When they commit those changes, they take effect immediately, without taking the process offline.