When I created the Corticon business rules engine, my goal was to ease the pressure on business application developers who are tasked with almost continuous code changes related to business rules. Not to mention the business analysts and operational departments who are anxious to put updated policies, regulations and guidelines in place to automate critical decision-making processes.
The following tips come from my programming point of view. However, advanced business users should find them helpful as well, as modeling and managing complex business rules basically make you an honorary programmer—hoodie optional.
As I discussed last week in my Introduction to Corticon for Java Programmers post, Corticon is 100% declarative. It was built this way to allow for business processes that cannot be predicted in advance to be automated for decision-making. Imagine the complex set of variables used to answer questions such as:
Quick Start Tip #1: When rules are created in the same rule sheet, Corticon will automatically detect logical dependencies and order rule execution so the rules that modify data will execute before those rules using the modified data.
For example, say that you have a rule that requires the age of a customer and another rule that computes the age. Both of these rules can go into one rule sheet, and Corticon will detect that the age must be computed automatically. It is not necessary to tell Corticon to compute the age with additional code.
Quick Start Tip #2: Corticon is designed to generate efficient optimized looping code, so adding additional redundant checks will slow things down.
This means that adding in additional conditions to check for not empty or not null association references is inefficient and can create drastic drains on performance. Not to mention the redundant code that results when those extra association checks are used in filters. Keep in mind that Corticon has created an iterative loop for you.
Quick Start Tip#3: When an alias is created, a new binding to the corresponding entity is logically created.
An alias is then limited with a filter, and all further references to that alias are also limited. However, the entity itself is not limited. When you use the entity name itself in a rule sheet, the entity name is the default alias, and is treated as such.
The collection operator ->exists is a way to determine if a collection contains an entity with certain characteristics. This results in a very important tip to keep in mind:
Quick Start Tip#4: The collection operator ->exists should only be used when the collection as a whole (or filtered) needs to be acted upon.
So if rules only need to act upon the entity or entities that would qualify the
->exists operator, only use filters or conditions to qualify that entity so as not to affect application performance.
Help is always available should you need it. Check out these online resources, or contact us anytime.
Eric Moore is a Software Architect at Progress.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.