As it frequently happens with all good & bad things in life, the SOAMythBusters Blog has ran its course as well, so today we publish our final chapter. It’s been a great run, which brought us many satisfactions and allowed us to deliver some interesting content to a very broad audience. Our goal has always been to contribute to the Oracle Community, but also to give our opinion and point of view regarding the most exciting trends and developments in integration technology.
We take a lot of pride in the quality and originality of our publications, as well as in the research, time and effort we invariably put into them. We’re also very grateful for all the amazing contributions and feedback we received from accomplished professionals all over the world, and have always strived to give credit where credit is due.
It is important that you know that the SOAMythBusters Blog is and has always been a non-profitable and independent space, with no affiliation whatsoever to our current or former employers or any other organization. All the content here represents our own personal views and was developed without exception on our personal free time; therefore, no one but us can ever claim ownership over it.
Our published content will still be available for everyone until further notice, so feel free to keep enjoying the Blog and commenting on the posts.
And now, we bring you our last effort, long overdue to tell the truth. This body of work was done a while ago with outstanding contributions from our colleagues Marisol and Miguel. In that time, we all used to work together in Mexico City, so it allowed us to create a really comprehensive article containing a deep dive into Oracle Business Rules, its evolution and a practical approach both for 11g and 12c.
So here it is, our final episode in vintage SOAMythBusters style. Enjoy!!
In this article, we will dive into the discussion of how and where Oracle Business Rules fits into a Service Oriented Architecture. Furthermore, OBR’s evolution along Oracle’s FMW stack will be revisited, as well as its importance, benefits and the best practices to implement this product based on our own experience.
In many customers / projects we have faced a lot of resistance spearheaded by inaccurate conclusions around OBR’s scope, capabilities, performance and overall reliability as a component of Oracle SOA Suite.
This kind of concerns, can frequently lead organizations to underestimate the tool’s potential or even to abandon its use altogether, selecting instead suboptimal alternatives for business rules implementation and management.
“Oracle Business Rules is not a relevant tool within the FMW Stack; it is also risky to use, unfriendly to the final user and difficult to position adequately in a SOA Architecture”
Let’s get started
First and foremost, let’s take a look at how any business rule engines may fit into a technological architecture based on service-orientation principles.
It is very important to take in account that from a theoretical / methodological standpoint, “Rules Centralization” is in fact an established SOA design pattern, related to both the “Orchestration” and “Enterprise Service Bus” compound patterns.
Rules Centralization is also one of the “Inventory Centralization Patterns”, along with Policy, Schema and Process Centralization.
By definition, Rules Centralization should allow us to abstract and centrally govern business rules, promoting reuse, standardization and simplifying code by removing this type of business logic from the component’s core implementation.
This kind of centralized approach can be especially useful when deployed together with SOA-enabled orchestration scenarios:
*If you want to read more about the Rules Centralization Pattern as well as other fundamental SOA Design Patterns, we strongly recommend the following site:
Business Rules in Oracle Fusion Middleware
Maybe this will call our reader’s attention, but it so happens that Oracle Business Rules is one of the oldest products in the SOA Suite stack. It is there since the 10g old days.
We remember that during those days there was this wave of technology intellectuals defining the usage of many of the SOA stack components. Within Oracle there was this fight of trying to show to the market that the SOA stack included a Business Rules engine to compete against products like iLOG and JRules for example.
So OBR has been there for a long time. Take a look at this:
This is a sample presentation slide that back in 2005 we used to present the concept of OBR. That is exactly 10 years ago. Even the black background in the Oracle slides is present. That is a long time ago.
This used to be the web based application where developers and rules designers could define their dictionaries and rulesets:
Very often, clients have asked us how long OBR has been part of SOA Suite. Maybe they think that this a relatively new and unproved component, whilst actually it has been there for a long time, as you can see.
It’s been growing together with the rest of the components. Maybe not in the same pace as with BPEL PM or OSB, but it’s been there.
Furthermore, OBR is definitely not an improvised component, or something Oracle just pulled up from under their sleeves. In fact, like most of the best-known rule engines, OBR is based on an implementation of the RETE algorithm, which was developed to improve evaluation performance with large knowledge or fact sets.
*The Rete algorithm was designed by Dr. Charles L. Forgy of Carnegie Mellon University, first published in a working paper in 1974, and later elaborated in his 1979 Ph.D. thesis and a 1982 paper:
In this regard, Oracle’s customization of RETE has evolved progressively to become more subtle and has been tuned for performance. RETE is memory intensive so different caching strategies have been put in place in order to create an ideal execution map. Yet, essentially, RETE efficiently performs inferences against large fact sets (goals) and decides actions.
As for its integration capabilities, one constant thing for OBR is that it has always been able to communicate in many ways. Since its first release, it promoted integration:
As time has gone by, the integration has increased. In 11g, it was very clear how it was integrated with Oracle SOA Suite and with Oracle BPM. Within the SCA composite of Oracle SOA Suite, OBR is a first class citizen:
Source: Oracle Documentation http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/med_createrr.htm
OBR is a component, not only a reference within a composite, but a component.
Since Oracle BPM’s 11g version was released, OBR has also offered native integration with it. Not only as a component but within the Human Workflow. The rules to assign a role/user to a specific task is via Oracle Business Rules. The gateway elements can be mixed with OBR to make decisions on which path the process should take based on the information that is processing.
One of the questions that we get a lot from our customers is: ¿where does OBR fit in a FMW reference architecture?
The answer to that question is pretty simple. With the use of OBR, we would be generating a layer of “decision services” within our service inventory. In the same way as the rest of the services in there, our decision services can be reutilized by applications, business processes, service compositions, etc.
Now, we’ll focus our attention on the implementation of this product, so let’s start with a simple definition: what is a business rule? Well, it is a statement that describes business policies or key business decisions. So how do we implement those?
First of all we need Facts, which are the objects that rules reason on. This facts include the data we’re going to work with. From a purely technical standpoint, a fact is an asserted instance of a class that can be based on a variety of fact types such as: XML Schema, Java classes, Oracle RL definitions, and ADF Business Components view objects.
Additionally, we also have Bucketsets, which are lists of values or lists of value ranges to limit the acceptable set of options for a fact or a property of a fact.
Once we have the data, then we can define some rules. This can be accomplished by using simple conditions (if-else), but also with more complex decision tables. Depending on the result of the conditions we will execute a specific rule action.
A Ruleset contains a group of simple conditions and/or decision tables. A decision function provides a contract for invoking rules from Java or SOA.
Finally, we will end up with a dictionary, which is an Oracle Business Rules container for facts, functions, global variables, bucketsets, links, decision functions, and rulesets. A dictionary consists of an XML file that stores the application’s rulesets and the data model.
When using business rules, either as a decision component or as a library in a java application, several elements are involved. Beginning with the design of a dictionary with Rules Designer, which supports high-level Java-like language (Oracle Business Rules RL Language) and implements the Rules SDK.
Once we have deployed a dictionary in a SOA composite application, with every invocation to Business Rules a session is created, either stateless or stateful, into working memory. There, the facts will be loaded and asserted before the firing and execution of the rules with their consequent actions.
In OBR the rule-based system is a data-driven forward chaining system. The facts will determine which rules should be fired. When a rule fires that matches a set of facts, the rule may add more facts. These facts are again ran against the rules. This process repeats until a conclusion is reached or the cycle is stopped or reset. This process is typically called an inference cycle.
Process of Rule session
If you want a more extensive definition of these concepts, as well as of OBR’s basic architecture, please take a look at this guide:
Ok, so now that we have gone over the technical concepts, what about real-life experiences with the product? Some recommendations regarding the development cycle of business rules and specially the interaction with end users would be:
- Keep in mind that this a business-user oriented tool, and whilst its implementation requires high technical skills, the final result should always be user-friendly.
- Always look to design rules arm in arm with the final users; In order to achieve this, try using techniques such as mind-maps, flowcharts and process diagrams as opposed to technical-oriented diagrams, pseudo code, and/or unreadable narratives.
- When creating facts, it is paramount to emphasize the use of terms and concepts which are familiar to business users in day-to-day activities. For example, let’s take a fact representing a quantity of money; we could very easily be tempted to name this fact after a corresponding database column (e.g. “amount”), only to find out that our business user doesn’t even recognize such term. Instead, the definition we are looking for is “debtCapital”, which is a business term as opposed to a technical one. Behind the curtains, we can easily perform mapping if necessary, so let’s provide the users with an implementation that facilitates their work instead of introducing a bunch of technical stuff which will only make them uncomfortable.
- It is also very important that the execution chain we design for the rules, can relate to the actual business decision processes commonly followed by an organization. Again, the idea here is to simplify user tasks with the introduction of OBR, not to add more complexity.
- When we want to show some of the rules we’ve already designed to the business rules, it is very recommendable to do it in the Oracle SOA Composer web application. Keep in mind that JDeveloper is a developer-oriented tool, so if we try to give a demonstration to the users with it, they could be easily overwhelmed and discouraged. When a final user sees how easy it is to update a decision table in the Composer, we are in the right track.
- It’s recommended to use more decision tables than declarative conditions. As programmers, the IF / ELSE rules can look very simple because we are accustomed to this language, but for a business user the spreadsheet format provided by a decision table is way more friendly.
- When defining XML Schemas for the Rules Dictionary, try to reduce the fields to only those that will be useful for the definition of facts and rules. If we leave additional useless fields in our schema “just-in-case”, this will only confound our users once they are presented with the tool.
- Incorporating DVMs can be very useful for parametrization and data caching.
For successful implementations of OBR, it is very important that users understand the advantages of including business rules in their daily workday:
- They can change any value of the rules at runtime avoiding complicated and long procedures to deploy and release new versions of the components.
- The SOA Composer is friendly and learning to use it is easy.
- The prioritization of rules can be changed at runtime.
It is also very important to point out OBR’s weaknesses, so organizations don’t become overconfident with the product:
- There is no support for either rule-versioning, auditing rule changes or authorization workflows.
- The runtime changes cannot be synchronized seamlessly with design-time, this complicates governance procedures and introduces risks for lost changes and versioning issues.
- Execution tracing for rules is not friendly at all, the tool does not provide out-of-the-box statistics or insight. Integration with Oracle BAM can be a very good stopgap solution in this regard.
Use Case for OBR 11g
In order to reinforce and illustrate the last section, let´s take a quick look to a use-case assembled in OBR 11g:
First of all, we must create an XSD to represent our facts:
In this case we will be working with a bank, which among other things, has the ability to perform as a broker for international payments.
As you can see in the XSD, the decision service will receive some fields directly related to a “payment”. With this information, the rules engine must decide and return the intermediary bank through which the money will be sent to a foreign account. Additionally, our ruleset must have the ability to identify if we are dealing with an exceptional condition.
Once our facts have been defined, we will create a new dictionary by referencing the types we just established:
Before adding some rules, we may start by creating a “Bucketset”, which will contain the valid currencies we will be working with:
Our first Ruleset will contain declarative rules (IF…THEN):
Here we have a very simple test concerning the payment amount, which upon evaluation may determine the final result of our decision service’s execution.
If the first ruleset doesn’t conclude on a final result, we have defined a pretty simple decision table in order to evaluate a couple of distinct conditions (currency, accountNumber).
As you can see, the decision table serves as a container for five different rules (¿how would this same rules look on Java code for example?), which may be very easily maintained and modified in runtime by a final user.
And how about some conflict resolution? OBR provides out-of-the-box capabilities so that we can detect conflicts and define some overriding criteria in case some of the modeled rules overlap:
So far, we’ve been working on JDeveloper; however, once we deploy our composite to a running SOA instance, end-users will be able to login into SOA Composer and begin working with the rules with a full set of product functionality:
OBR 12c Overview
Two of the new and most relevant features in the 12c version of the Oracle Business Rules are the Verbal Rules and the MS Excel Integration. These can be considered as key for those integrations where Business Analysts and Users don’t want to get into details when it comes to technical terms or tools for modifying a “simple” if/then Rule -as we know it- or values in a complex Decision Table within a developer tool. And let’s face it, this is what happens most of the time. End users are most likely to expect a simple way to achieve this on their own business understanding.
Verbal Rules is a way to use natural language statements that are easier to comprehend and memorize than a sequence of actions in rule logic. So, for example, it would be much more simple to use a statement like “Customer is under-age” rather than “custAge < 21”, or “Customer has a valid bank account balance” rather than “custAccBalance > 0″. These are called Business Phrases, which are defined and set by the users to work all together and create the Verbal Rules.
¿Remember our 11g use case? Let’s take a look at how some of the same rules would look if we implemented them using business phrases / verbal rules:
Using this new feature, as rules designers we could very well sit together with our final users, with the purpose of defining a set of “business phrases”, which later can be combined using “verbal rules” in order to reach the desired outcome:
MS Excel Integration
When working with Decision Tables, this new functionality comes in very handy to our users: Business Analysts who are most likely to be more familiar with Excel than JDeveloper, no matter how friendly you try to make it look.
With a simple click, you can export your Decision Table to a .xlsm (Macro-enabled Spreadsheet) file to be modified (or a simple .xls), as well as importing it from Excel to the Decision Table into the Ruleset
Exporting a Decision Table to Excel, will enable operations like:
- Add/Delete Rule
- Merge/Split and Edit a Decision Table cell
- Add descriptions to Rules/Conditions/Actions
Importing said Table back to JDeveloper, will display the changes made, allowing the user to approve or reject them individually.
Besides these relevant features, there has also been some usability enhancements to the Rules editor like:
- Master detail layout of rules
- Description for condition, rule and action in decision table
- Better searching of choice list
- Enhanced auto-complete
OBR 12c Use Case
So now we will be going through the process of how to export a Decision Table to Excel, (get an overview of its features) modify it, and then import it back to JDeveloper, either to validate each modification individually, create a new version, or completely overwrite it. All this on a simple Loan use case.
This is our first version of the Loan Decision Table:
Once we have our table ready to export, we’ll click on the little Excel icon on the top menu:
On the next window, we have to select the Decision Table we want to export by clicking on the green plus sign.
It is important to note that, if our goal is to modify the information within the decision table and take it back to JDev, we must export the file in an xlsm (Macro-enabled Spreadsheet).
When opening the file, the ReadMe, ValueSets and Loan Decision Table (the name of our table) tabs are going to appear:
On top, there’s the Oracle Business Rule options menu for the Decision Table and ValueSet:
For our scenario, the only possible outcomes are a loan being approved, rejected, o the creation of a customer in case he/she doesn’t exist in the current database, but meets the other requirements. This means that, for example, a customer with a freelance job can’t apply for a loan.
So now, let’s say the business requirements changed and now a freelancer can apply for a loan if the rest of requirements are met. I’m a Business Analyst who knows the conditions that need to be validated for each action in the result and was asked to modify the table.
First I will need to add the new value “freelance” into the ValueSet for the corresponding condition, which in this case is customerEmploymentInfo.employmentStatus
Now I would have to go back to the Decision Table and add the new rule:
The new option will appear on the corresponding condition for me to select it now:
Once the file is saved and closed, it can be imported back to JDeveloper.
As we mentioned before, we can either create a new decision table out of our modifications, or completely replace the existing one. For this case we will check the “Perform Diff-Merge on Import” box.
This will highlight for us the changes between the previous and current versions for them to be individually reviewed and accepted or rejected. These can be identified as the ones with the delta (Δ) sign.
First we will review the changes on the Value Sets and Accept:
Then we go to the Decision Table in the Rule Set. The rule we added from Excel is now there.
For every change, we can individually accept them by right clicking on the delta sign, choose “Accept/Reject Diff…” and confirm.
Another option would be to simply click on the “Accept All” option on the upper right corner if we don’t want or need to go through the changes one by one.
And now we’re done:
- Oracle Business Rules is a bona fide product, which has been part of SOA Suite for years and as such has also evolved, providing capabilities according to contemporary business and technical requirements.
- As a concrete implementation of the “Rules Centralization” pattern, OBR can be positioned as a key component within a SOA Architecture, especially for an organization that is looking to move forward regarding the SOA maturity model. Its integration capabilities also make it a good fit for abstracting business logic and exposing it as decision services.
- Even though the product can bring with it a lot of benefits, it is important to beware of certain pitfalls; take in account that a misguided OBR implementation can potentially compromise or in the worst case cripple a service inventory or even a set of BPM processes.
- For a successful OBR implementation, it is fundamental to approach rules definition and design as a discipline based mostly on a business perspective. In Oracle SOA Suite 12c, this is further supported by features such as verbal rules and excel integration.
So, the myth we described at the beginning of the article has been thoroughly demythified. In fact, with the right approach, OBR can even become a key enabler for organizations looking to introduce business-driven SOA & BPM initiatives.