Oracle Business Rules

In our upcoming 11g release, we have added many features and enhancements to Oracle Business Rules (OBR). Everyone that has used the preview version, or has seen a demo, has been very positive. Whether you are familiar with OBR or not, we believe, you will be very pleasantly surprised with the simplicity, richness, and power of OBR 11g.

We recently demonstrated the preview version of OBR 11g to Jim Sinur from Gartner and he blogged about it:

Process and Infrastructure: Now for the good news

While one could argue that Oracles wrapped JESS based rule engine is not the best one in Oracles inventory of BREs, but it is more than sufficient. Oracle is upping its usability and penetration into Oracles BPM offering. I was given an advanced demo of the interaction of Oracle BPM and their advancing rule engine and I came away pleased. This BRE is pervasive in most, if not all, of the process components and it is much easier to use than ever before. With the addition of decision tables and rule modeling/evaluation, the rule engine is something that a trained business analyst could use. In addition there were aspects of a budding business rule management system (BRMS) that included major aspects of change control and rule packaging. I was pleasantly surprised and excited about hearing from Beta users later this year.

Some of the enhancements in OBR 11g include:

1. Decision Tables
Decision Tables is a spreadsheet like metaphor for business rules authoring. In addition to being easier to understand for business analysts, it also provides more validation support including checks for overlapping rules and completeness.

Click here to see full image.

To learn more about the Decision Tables feature in OBR 11g, please see this demo recording.

2. Much simpler to use
OBR 11g makes it real simple to write simple rule. Actually, using the capabilities to nest conditions and change conjunctions (and) to disjunctions (or), very sophisticated rules can be written in the simple mode. Couple this with OBR's inference capability, which enables breaking complex rules into more atomic rules that can then be implicitly chained and re-used, you have a very powerful capability in a very simple to use form.

To learn more about the simplified authoring experience in OBR 11g, please see this demo recording.

3. Seamless integration with BPEL and Composite
First, seamless unification of components is a major theme for our upcoming 11g release; this provides our customers a very well integrated design time, run time, and management experience.

In context of Business Rules and BPEL, among other integrations, we have made the scenario where you want to externalize some logic from BPEL to rules very seamless. You can create a new rules dictionary from within BPEL, select the BPEL variables you want to use as inputs and outputs for your rules, and a dictionary is created for you that is completely ready to start writing rules - i.e. you do not need to manually import your facts (data model) etc. Of course, you can also re-use an existing rules dictionary from your BPEL process.

To learn more about the integration of OBR and BPEL, please see this demo recording.

4. Rules for Human Task Routing
In our 10g product, we leverage OBR from our Human Workflow component in BPEL PM to manage vacation rules, delegation rules, load balancing rules, etc.

In 11g, we have a very powerful integration between OBR and Human Workflow for Task routing. Business Rules can be specified for determining the flow of a Task, such as whether the Task should be sent to the next participant, completed, escalated, or sent to a different participant. These rules are invoked by Human Workflow each time it needs to move Task from one participant to another or other Task state changes.

This feature is being significantly used by Fusion Apps for sophisticated approval routing.

To learn more about rules driven task-routing, please see this demo recording.

5. Aggregate Conditions
Many times, we need to write rules that are based not only on one fact (data) but conditions that are based on having a view spanning multiple facts, i.e. aggregated conditions. In our 10g product, we already support some of these scenarios; we support writing rules that check for existence of a fact type or lack there-of.

In OBR 11g, we are introducing support for aggregate conditions. Out-of-box, we support common aggregation functions such as sum, average, count, min, max. You can provide your own aggregation functions too.

To illustrate the capability of this feature, if I want to write a rule which specifies that if an Order has more than 5 line items whose price is above a threshold, require manual approval, I can write a rule like (pseudo-code for illustration):

numPricey = count of lineItems such that lineItems.price > threshold and
numPricey > 5
then ...

To learn more about support for aggregate conditions, please see this demo recording.

There are a lot more exciting enhancements in OBR 11g including Decision Functions that provide a declarative mechanism for creating rule flows/pipelines, Dictionary Links that enable splitting a virtual dictionary into multiple physical ones for re-use or finer grained versioning and access control, and MDS as a repository. These would be good topics for a future blog post.

We are very excited about OBR 11g and hope you will share the excitement. To learn more about the 11g release, please visit the SOA 11g - Technology Preview site.

We've just put a new whitepaper on Smart Business Processes with Oracle Business Rules on our official site.

This post gathers together some of the resources for learning how to do rules programming, and specifically how to use Oracle Business Rules.

Currently, all publicly available documentation from Oracle is for the 10.1.3 version of OBR:

• The official webpage for Oracle Business Rules
• OBR User's Guide (10.1.3)
• Oracle Business Rules Language Reference (10.1.3)
• OBR SDK Javadoc (10.1.3)
• OBR 10.1.3.4 release notes (there were only minor changes between point releases, so the documentation above listed as "10.1.3.1" applies to all of the 10.1.3 versions)
• Chapter 18 BPEL Process Integration with Business Rules of the Oracle BPEL Process Manager Developer's Guide, which describes using the Decision Service

For questions or issues with OBR, the
SOA Suite category on the Oracle Forums is the the best place to go.

Unfortunately, there aren't many books on rules programming out there. Here are a few of the relevant ones:

• Jess in Action by Ernest Friedman-Hill - while the Lisp-style syntax may be daunting to many OO programmers, there's a lot of good information on how rules engines work in practice and on how to write rules.
• Smart (Enough) Systems by James Taylor and Neil Raden - this book mostly focuses on the business case for improved decision support, but has an excellent chapter on the current state of business rules engines (BRE) and business rules management systems (BRMS).
• Expert Systems: Principles and Programming by Giarratano and Riley - a thorough and deeply technical description of rules principles.
• Introduction to Expert Systems by Peter Jackson - another very technical book

Plenty to get you started in the wonderful world of rules!

When one calls the normal "assert" function on an object, only that fact is asserted. OBR also allows you to assert an object graph consisting of JAXB objects representing an XML document with the "assertXPath" function. This will assert the tree of objects starting with object passed to the function. The most common path to assert is "//*", meaning the entire subtree, but any arbitrary XPath can be used. assertXPath will assert only objects for which there is a 1-to-many relationship with the parent object. In the JAXB generated code, by default this is represented by a property of List type.

Objects in the hierarchy with a 1-to-1 relationship with their parent can be accessed directly via their parent's property, so it is not necessary to assert them in most cases. This also means that when a schema definition has an object hierarchy with a 1-to-1-to-many relationship, the child and grandchild objects will not be asserted. Some schemas define this type of relationship explicitly, but it can also occur in some situations when anonymous complex types are used.

If the user wishes to have the entire tree below the 1-to-1 relationship asserted, then this tree must be explicitly asserted. One way to do this is to write a rule that will match the parent fact type and call assertXPath with the the child fact type instance as an argument. This rule can then be made to run before all other rules. In the case of invoking a single ruleset from a decision service, this rule should be in the invoked ruleset with a priority higher than all other rules in the ruleset. In the case of invoking a function, the rule should be in a ruleset which is pushed onto the ruleset stack last, so it will be executed first. Because the rule will only match on the fact type, and not any of the properties of the fact type instance, the rule must be written like:

if (fact Parent p && not exists (fact Child c && p.child != c) )

Meaning, the parent exists but the child does not. If only the parent fact is matched, then the rule will re-fire anytime the parent fact is changed, reasserting the child and re-firing any rules which depend on the child. In Rule Author, "not exists" is implemented using the "there is no case where" form of a pattern.

When creating a decision service which invokes a single ruelset, there is a checkbox labeled "Check here to assert all decendants from the top level element". This will cause the decision service to use assertXPath with the path as "//*" instead of the default of only asserting the root object. If you wish to assert something other than "//*" in the decision service, the decisionservice.xml file can be edited to replace "//*" with the desired XPath expression.

Assert Fact and Watch Fact
If the same fact type instance is used for input and output to the decision service, both Assert Fact and Watch Fact must be checked for that fact type in the decision service wizard.

Editing a decision service
The only way to edit a decision service is to begin to create a new Decide activity. Click on the edit "pencil" icon. However, the only thing you can only change the function or ruleset which is called. Also note that when you edit the decision service, the Decision Service drop down menu is reset, to the decision service you selected to edit is no longer selected and must be reselected. If you need to change anything other than the function or ruleset called, you must create a new decision service.

Creating a Decision Service which uses a WebDAV repository
You cannot access the WebDAV connection wizard after starting the decision service wizard, so you must create the WebDAV connection from the Connections tab before starting the decision service wizard.

In production, it is recommended to use the WebDAV repository option. However, during development, this can be laborious, since the WebDAV repository is slower than the file-based repository, as it usually on a remote machine. Additionally, if the WebDAV repository connection is over a slow link, the UI can pause for several seconds at a time while the repository is accessed. The latency usually isn't an issue at runtime because the repository is accessed infrequently by the running decision service. However, during design-time, it can be advantageous to use a file-based repository for development and then change the decision service configuration to use WebDAV when the application is ready for production deployment.

There are two primary things that need to be done: (1) moving the dictionary or dictionaries from the file-based repository to the WebDAV repository, and (2) changing the decision service to use the WebDAV connection.

I've seen people try to just copy their file-based repository to their WebDAV repository, but this will not work. The repository itself is nothing more than a collection of appropriately named XML files representing the rules. A file-based repository is a zip file of these files, and a WebDAV repository is a directory of these files. So, copying the file-based repository into the WebDAV directory is putting a repository inside another repository!

To move a dictionary between a file and WebDAV repository or vice-versa:
1) In Rule Author, connect to the source repository.
2) Choose the "export" tab.
3) Export the dictionary and download the resulting export file.
4) Disconnect from the source repository.
5) Connect to the destination repository.
6) Choose the "import" tab.
7) Select the previously exported file and import that file.
8) Save the dictionary.
9) Done!

The next step is to modify the decision service to use the WebDAV repository. To do this, open the file:

JDev_Oracle_Home\jdev\mywork\application_name\
process_name\decisionservices\DecisionService\war\WEB-INF\
classes\decisionservices.xml

In the ruleEngineProvider element, "repository" element must be changed from something like:

<repository type="File">
<file>repositoryresource:CreditRatingRepository</file>
</repository>

to something like:

<repository type="WebDAV">
<webdav>
<url>http://myhost.mydomain.com:8080/rules/repository/</url>
<username>bob</username>
<password encrypted="true">r9CqG45+Cg=</password>
</webdav>
</repository>

Instead of manually creating the "webdav" element in decisionservices.xml, I usually create a new decision servce which uses the WebDAV repository and then copy the "repository" element created for that decision service into the one I want to change. This way, there's much less chance of a typo and I don't have to manually encrypt the password.

Section 18.7.2 of the Oracle BPEL Process Manager Developer's Guide 10g (10.1.3.1.0) contains instructions for enabling debug logging for a decision service. However, unless you are familiar with BPEL debugging already, there is one step missing. The logging is at the "debug" level, but the BPEL server sets the logging level to "info" by default.

To change the logging level to "debug" so you can see the logging information from your rules:

• From the BPEL Control panel, click on the "Configuration" tab.
  
• From that tab, click on the "Logging" sub-tab.
  
• For the "Logger Name" "default.collaxa.cube.engine.bpel", select "Debug" for the "Logging Level.
  
• Click the Apply button at the bottom of the page.
  

Debugging output is now enabled and will be available in the OPMN log for the domain in which the process is deployed.

In 10.1.3, the two types of rule repositories are file-based and WebDAV. WebDAV is recommended for production deployment, but some people may still want to use a file-based repository. Support for product lifecycle is not as strong when using a file-based repository, so this post describes the manual steps that must be performed.

When you deploy the BPEL process with a decision service that uses file repository, a copy of repository is packaged with the decision service. The decision service refers to this copy when executing. To modify the rules without redeploying the BPEL process, you must modify this copy on the server. To do this, go to the BPEL Console, click on your BPEL process, and go to the descriptor tab. This page contains a link to open the deployed rule repository using Rule Author.

Changes to the deployed dictionary will be reflected in decision service instances created after the dictionary is saved. A stateless decision service keeps a pool of rule engine instances which it re-uses, and will refresh these instances with new ones when it detects the dictionary has changed. A stateful decision service creates a new rule engine instance every time it is invoked and will always be created with the latest version of the dictionary.

If you make changes to the deployed file-based dictionary, you must manually copy this file back into your JDeveloper project if you wish to have the changes persist in the next deployment of the decision service.