Among other things, this article discusses how Business Rules can leverage BI information as contextual facts to drive optimal decisions.
Happy reading! Again, the article is here.
]]>Among other things, this article discusses how Business Rules can leverage BI information as contextual facts to drive optimal decisions.
Happy reading! Again, the article is here.
]]>Oracle Fusion Middleware 11gR1 can be downloaded here.
Rule Designer, the design-time UI component for Jdeveloper, is part of the Oracle SOA Composite Editor and can be downloaded here.
OBR 11g documentation can be found here.
Information on upgrading OBR 10g dictionaries to OBR 11g can be found in Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF
Appendix C Upgrading Oracle Business Rules Dictionaries and Projects.
Finally, there are a few release notes.
]]>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 newsWhile 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.
Currently, all publicly available documentation from Oracle is for the 10.1.3 version of OBR:
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:
Plenty to get you started in the wonderful world of rules!
]]>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.
]]>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.
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.
To change the logging level to "debug" so you can see the logging information from your rules:
Debugging output is now enabled and will be available in the OPMN log for the domain in which the process is deployed.
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.
By default in 10.1.3, the rules repository stores each ruleset in a separate XML document. In a file-based repository, these documents are stored within a zip file. In a WebDAV repository, these documents are stored in a WebDAV-visible directory. This default mode for storing the rulesets is known as "multiple document format". This format was first used in the 10.1.3.1 release, and continued through to the 10.1.3.3 and 10.1.3.4 releases for backwards compatibility. However, multiple document format has negative performance ramifications, particularly with large numbers of rulesets in a WebDAV repository. The 10.1.3.3 and 10.1.3.4 releases also have the option of storing all rulesets in a single document to provide better performance. Multiple document format repositories must be manually converted to single document format to take advantage of these performance benefits.
The following utility will convert a rule repository to single document format. All dictionaries that are not in single document format are converted. Once the repository is converted, all new dictionaries that are created will be in single document format. This utility is contained in the rulesdk.jar file.
These classes are required on the classpath when running these commands: xmlparserv2.jar, xmlmesg.jar, xml.jar, orai18n.jar, oraclepki.jar, ojpse.jar, http_client.jar, rl.jar, rulesdk.jar, jr_dav.jar, webdavrc.jar.
java oracle.rules.sdk.repository.SingleDocumentFormat
-type repository_type
-path file_path | -url webdav_url [-wallet wallet_path]
where
repository_type is either file or webdav
file_path is the path to a file repository
webdav_url is the URL for a WebDAV repository
wallet_path is the path to an Oracle wallet containing WebDAV credentials
A file_path or a webdav_url must be provided.
Additionally, there is a similar utility that converts a rule repository from single document format to the multiple document format. All dictionaries that are not in multiple document format are converted. Once the repository is converted, all new dictionaries that are created will be in multiple document format.
java oracle.rules.sdk.repository.MultipleDocumentFormat
-type repository_type
-path file_path | -url webdav_url [-wallet wallet_path]
where
repository_type is either file or webdav
file_path is the path to a file repository
webdav_url is the URL for a WebDAV repository
wallet_path is the path to an Oracle wallet containing WebDAV credentials
A file_path or a webdav_url must be provided.
]]>The integrated way to use Oracle Business Rules (OBR) from a BPEL process is via the Decision Service component through a Decide activity. Chapter 18 BPEL Process Integration with Business Rules of the Oracle BPEL Process Manager Developer's Guide explains the basic steps for doing this, but there's always more information than can go in the official documentation. This post explains in greater detail how to use the various decision service configurations.
Stateful vs. stateless
By default, the decision service is invoked as a stateful service. This allows the same decision service instance to be called more than once within the same BPEL process instance and maintain state between calls. For example, we may retrieve some data from a database, make a call to a stateful decision service, branch in our process based on the result, access the database again, and call the stateful decision service again with our additional data.
If you are only making one call to a decision service within a BPEL process using the "Assert facts, execute rule set, and retrieve results" operation type, consider changing the decision service to be stateless. This will improve performance because a stateful service invocation creates a new rule engine instance for each call, whereas a stateless service maintains a pool of services that can be reused. Thereby, the stateless service call has lower CPU overhead for creating the service instance and does not require additional memory because the rule engine instances already exist as part of the pool.
Ruleset invocation type
The Ruleset invocation type allows you to select from several Operation types, as described in section 18.4.3.1 "Mapping Input and Output Facts to BPEL Variables" of the BPEL Developer's Guide. The most common usage is the "Assert facts, execute rule set, and retrieve results" type as a stateless session. The other operation options are usually used for stateful sessions, whereby we want to maintain the state of the decision service between multiple calls, for example, if we wanted to use facts generated in the rules engine during one call as available to another call.
The primary advantage of using the Ruleset invocation type is it's simplicity, as the assert, execute, and retrieve operations are easily defined with in the Decide component. The primary disadvantage of using the Ruleset invocation type is that only rules from one ruleset will be evaluated. You cannot evaluate multiple rulesets against the same facts or use a pattern by which rules in one ruleset causes additional ruleset to be evaluated via the pushRuleset mechanism, because only the named ruleset is created in the rule engine instance.
Note that if you have multiple calls to the same decision service within a BPEL process, even these calls do not maintain state between them, it is preferred to use a stateful session. This way, if the rules are modified during the lifetime of the process, the process will still use the rules which existed when the process started. Otherwise, there is a possibility that different rules can be used for different invocations of the decision service. Multiple calls to a stateful decision service that do not (or should not) maintain state between them should be invoked with the operation "Assert facts, execute rule set, retrieve results, and reset the session", so any facts in the rule engine are removed between calls.
Function invocation type
The most useful invocation type in the decision service is to call a function defined in the rules dictionary. This allows the user greatest flexibility in how the rules are used. However, this pattern also requires the user to perform some actions which can be automatically performed with the Ruleset invocation type.
There are two operation types for the Function invocation type, "Execute function" and "Execute function and reset the session". These have equivalent functionality when called as part of a stateless decision service. When called from a stateful decision service, resetting the session will cause all facts to be retracted, as with the similar Ruleset operation type.
A function called from the decision service by this invocation type must meet the following requirements:
It is necessary that the return and parameter types be XML Schema element types rather than XML Schema complex types. If complex types are used, the functions will not appear in the dictionary browser and therefore cannot be selected.
The body of this function must do three things:
An example of a function which can be called from the decision service is shown below:
Function body:
assertXPath("com.oracle.fmw.obr.test1", email, "//*");
pushRuleset("RULESET_1");
run();
return email;
This is a very simple function body. The function body can assert any number of parameters and push any number of rulesets onto the stack.
However, sometimes users will encounter an error like the one below when trying to import it into a dictionary:
[ERROR] src-resolve: Cannot resolve the name 'ns0:Header' to a(n) 'type definition' component. line 13 of baz.xsd
This error indicates that the imported schema has multiple imports with the same namespace. The XML Schema specification says that it's at the discretion of the parser whether or not it wants to acknowledge all of them, and most don't. Xerces is the parser used in WebLogic, and does not. An import has the meaning of "components from namespace X might be found in schema Y," so the parser looks in one of them and then returns that the component cannot be found. The name which the error indicates is in one of the ignored schemas, so the name can't be found.
The most common way around this is to create a schema that includes all of the schemas you want to have in the same namespace, and then import that schema into your primary schema.
Example:
intermediate.xsd:
<schema targetNamespace="foobar" ...>
<include schemaLocation="foo.xsd"/>
<include schemaLocation="bar.xsd"/>
...
</schema><schema targetNamespace="baz" ...>
<import namespace="foobar" schemaLocation="intermediate.xsd"/>
...
</schema>
Also, it is common to use <import /> when the target schema has a targetNamespace, and use <include /> when the target schema does not have a targetNamespace.
One issue is when running Firefox and the application server on the same machine, when opening a dictionary within Rule Author using the "Browse" feature, only the name of the file and not the full path is filled into the text box. This will result in an error message like:
Cannot perform operation. 'RUL-01213: Error initializing the repository. Please refer to the base exception. Root Cause: 'ruleRepository' does not exist. '
Also, there are several issues with the partial page rendering and the popup windows do not work, preventing the user from editing rules.
Firefox 2 and Internet Explorer 6 and 7 all work properly.
Google Chrome, though not officially supported, works properly and has the nice feature of being able to resize text entry windows for expressions. However, as of November 2008, Chrome does not have an autofill/autocomplete feature for text entry, so the user must manually enter the location of the dictionary, Java classes and jars, and XML schemas each time.
Apple Safari also works, but pop-up blocking must be disabled (unlike Firefox and IE, the pop-ups are silently blocked rather than prompting the user to allow them).
]]>Oracle Business Rules was first released as part of the Oracle Fusion Middleware 10.1.3.x stack. Since it was released, we’ve gained valuable knowledge about its use, and in particular about the use of the Rule Author rule development tool, in various customer environments. Understanding how other customers have successfully used Rule Author in OBR version 10.1.3.x can help make your own rules development experience more efficient and can make harnessing the power of rules that much easier.
Note that in many cases the tips provided below are obviated by changes made in OBR version 11 and in Rules Designer, the authoring tool that that replaces Rule Author in version 11.
Updating the datamodel to reflect changes to XML schema
Issue: XML fact types are based on XML schemas, and Java fact types are based on Java classes. When XML schemas are changed, you should re-import them to the datamodel in order to update the XML fact types. This updating happens automatically when Java classes change, but when XML schemas change, you need to take extra steps to update XML fact types.
Action in 10: When an XML schema changes, remove the schema from the schemas list and then re-add it to force the JAXB classes to regenerate and the import tree to be updated. Then select and import the changed elements.
Action in 11: Rules Designer contains a button that re-imports all XML schemas on command, updating all XML fact types automatically.
Removing a fact type property, method, or field
Issue: Removing fact type properties, methods, or fields can be tricky in Rule Author. Removing one of these items invalidates any rules that use it, which blocks dictionary updates. Unfortunately, Rule Author allows you to edit only one rule between dictionary updates. This means that whenever multiple rules are affected by the removal of a fact type element, you will find yourself in a catch-22: you must modify all rules before the dictionary can be updated successfully, but only one rule can be edited between updates.
Action in 10: To remove a property, method, or field from a fact type, first remove all references to it in all rules, then remove the fact type element. If there are references in any rules to a missing fact type element, a validation warning appears when that rule is next saved. Unfortunately this warning doesn’t describe where the reference to the missing item is, so you must manually search the rules for it. If the item occurs in more than one rule, another validation error appears when you update the dictionary. In that case, you must re-add the item to the data model, remove references to the item from all rules, and then try again to remove the item from the data model.
Action in 11: When you remove an element from a version 11 fact type, rules that use it return validation warnings, but you can still save the dictionary.
Renaming a fact type property, method, or field
Issue: Changing the name of a fact type property, method, or field takes several steps.
Action in 10: To rename a fact type property, method, or field, you need to both remove the original fact type element and create a new one with a different name. Here’s how to do this. First, add the new item. Next, change all references in rules from the old item to the new item. Finally, remove the old item according to the directions in “Removing a fact type property, method, or field” above.
Action in 11: Follow the same general procedure of adding a new item and deleting the old item. However, if you give the new item the same alias as the old item, Rules Designer will automatically replace any references in rules to the old item with references to the new item. You can then change the alias of the new item, and rules will maintain their references to the new item.
Changing the signature of an RL function
Issue: Changing the signature of an RL function does not update the expression table for each usage of the function. This can cause invalid RL to be generated.
Action in 10: When the signature of an RL function is changed (i.e., parameters are added or removed), perform the following steps for each use of the RL function:
Adding an Action other than to the end of the action list
Issue: Adding an action anywhere other than the end of the action list.
Action in 10: This is not possible.
Action in 11: You can create actions in, or move actions to, any position within the action list.
Complex rule actions
Issue: The limited number of rule action types and limited action management capability make it difficult to write complex rule actions.
Action in 10: Write complex rule actions as RL functions, and call them via a Call rule action.
Action in 11: A greatly expanded number of predefined actions and better action management mean that most rule actions should not need to call RL functions.
Writing RL functions
Issue: Writing RL functions in Rule Author is difficult
Action in 10:
JAXB derived types
Issue: The Oracle XDK JAXB implementation has a bug that prevents the proper functioning of “unbounded” elements in derived types. For example, the following XML schema snippet demonstrates the creation of a derived complexType:
<xs:complexType name="base-type">
<xs:sequence>
<xs:element name="foo" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="derived-type">
<xs:complexContent>
<xs:extension base="tns:base-type">
<xs:sequence>
<xs:element name="bar" type="xs:string" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
If this schema is used to generate JAXB classes and unmarshall XML documents, the resulting JAXB object graph will not contain any “foo” elements. This is a bug in the Oracle XDK.
Action in 10: Do not use complexType inheritance in schemas which will be used as the basis for XML Fact Types.
Action in 11: The Sun JAXB 2.0 reference implementation, which is used by default, does not have this issue.
Writing RL functions that can be called from a BPEL Decision Service
Issue: RL functions that can be called from a BPEL Decision Service must conform to a specific signature. If they don’t, the functions won’t appear when creating the decision service.
Action in 10: The RL function must return an XML fact type that represents an element (not a complexType) and must only have parameters of element type. XML fact types representing complexTypes typically have the suffix “Type” while element XML fact types typically do not this prefix.
Action in 11: Version 11 introduces the more robust concept of a “decision function,” which is the only thing a decision service can call.
Defining a Pattern
Issue: When creating a pattern, Rule Author presents three options: blank, “there is a case where.” and “there is no case where.” It is not always clear which option to use. If you choose “there is a case where,” the pattern variable does not appear as a valid option in the action part of the rule.
Action in 10: The blank option is the default and is a valid choice. It means “for each case” and will execute the rule’s actions for each instance of a fact matching the pattern. The other two options involve existential quantifiers. A rule defined with “there is a case where” will fire if there is at least one match, but the rule’s action does not get a reference to any specific fact instance that matched. Since the rule has no reference to a specific instance, the pattern variable doesn’t appear in the action option lists.
A rule defined with “there is no case where” will only fire if no fact matches the rule’s pattern. In this case, the rule’s action would not be able to reference a fact instance.