7 Best Practices for Oracle Fusion Business Rules
Oracle Business Rules are an effective tool for dealing with human nature, order irregularities and help eliminate some of the chaos related to managing orders and fulfillment. In order to get the most of them you need to give them attention and care to keep them effective. Here are 7 Best Practices for Oracle Fusion Rules to design and develop better business rules.
One – Use only one tool for creating business rules
There are two rules engines available for the creation of Oracle Business Rules. They are the Oracle Business Rules (OBR) Engine and the Visual Builder. Some rule functions allow you to choose to create rules using either Oracle Business Rules or Visual Builder. Oracle cautions against mixing the use of both in those cases because there could be unwanted interactions based on the way the two methods work.
Visual Builder creates a duplicate rule automatically in the Oracle Business Rule format in some of the functions. Thus using Visual Builder makes some amount of sense in most situations. Visual Builder is easy to manage and the ability to create rules is within the abilities of most functional types.
Oracle Business Rules are more complex in the way they are created and as such are better created by a technical role. OBR does provide a more robust dictionary and in some cases allows the definition of attributes you choose.
Two – Use a Design Document
It’s a good idea to create some type of design documentation when creating an Approval Rule. It helps contend with potential issues that could arise in design and development. If possible, use a template that outlines conditions to look for. Include items like Where Used lists for attributes and a standard test plan (more on that later). Methodology is a matter of choice, so go with what you know.
When you are designing a rule, consider what other rules act on the same attributes you considering for your new rule. The Where Used list mentioned above can be a useful tool in figuring this point out.
Consider consolidating like rules into one rule using Else Clauses. This helps simplify maintenance of rules and raises awareness of rules or clauses that may conflict with each other.
During development, be vigilant for conflicting statements and consider what actions to take if an attribute in the rule is null. If you find that an attribute is not working in the way you expected, sometimes there is a similar attribute that will achieve your desired outcome.
Three – Use a dedicated Environment
It is recommended that you use only one environment to develop Business Rules. This is because of the way that migration between instances works. More on that later in this blog.
Another good reason for using a dedicated environment is that you have ALL of your rules in place. For that reason, it’s a good idea to refresh the environment from Production before starting a major rule creation event. Having all of your rules together minimizes the chance of ending up with conflicting rules after an addition.
Four – Testing, Testing, Testing…
After you have designed and developed your rule, test it, test it, and test it again.
Be sure to include regression tests in your standard battery of approval testing requirements in addition to the conditions you designed for.
It is imperative to test with as recent a copy of your production pod as possible. This is for two reasons; First, to ensure your regression tests cover all the rules that exist in your Production Pod. Secondly, to guard against losing existing rules in Production if you are using the Migrate functionality.
Five – Rule Administration
It is helpful to periodically review your approval rules for relevance. This is ensure accuracy of the rules in the face of changing product lines and customer flux. It also helps cull rules that are no longer necessary and clear the landscape to make rule maintenance easier.
As mentioned earlier, if two or more rules are of a similar nature, it might be helpful to combine into one rule using Else statements. However, there sometimes comes a point with similar rules where there are too many to put in one rule and still be able to find the clause you’re looking for.
Six – Limit access to Development
It is also helpful to limit the number of people with access to the Setup and Maintenance of rules. It prevents overlap of rules, conflicts and stops the publishing of unwanted rules to Order Management.
If more than one person is involved in rule creation it is important that they talk to each other about their respective rule projects. They should coordinate on publishing and migrating rules as well.
Seven – Use the Migration Process
Oracle has created a process to migrate rules from one environment to another for many kinds of rules. This helps to ensure the rules set stays intact. This process goes hand in hand with best Practice Number Three. One of the characteristics of the process is that it deletes any rule not in the source environment. Moving your your rule sets from Production to the Development environment ensures that you don’t accidentally lose a rule after development.
Conclusion
We have looked at 7 Best Practices for Oracle Fusion Business Rules . We identified some critical points to consider when designing and creating rules. Feel free to reach out to us here at Perficient with your questions and needs.
For more detailed information about Oracle Cloud OM Business Rules, try this link: https://docs.oracle.com/en/cloud/saas/supply-chain-management/21a/faiom/orchestrate-fulfillment.html#FAIOM1702198
For more information about Oracle Fusion Business Rules in Order Management, check out this blog:
