Eric Moore provides some tips for Java and JavaScript developers working with the Corticon BRMS. Ease frustration with this quick start guide.
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.
Progress Corticon Business Rules Management System (BRMS) has helped break down the Business-IT impasse by removing rules from application code. However, Corticon may initially frustrate programmers who work primarily in Java and JavaScript environments.
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.
Declarative Processing Means Loosening the Reins
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:
- Will I be approved for a mortgage?
- How much will my auto insurance cost?
These are decisions that even senior managers can’t compute without processing help. As a result, though, Java and JavaScript programmers lose the ability to strictly order processes.
How Corticon Handles Rule Dependencies
Rule dependencies are usually the first big bump in the road for Java and JavaScript developers. So it’s very important to understand this first quick tip:
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.
How Corticon Handles Rule Iterations
A rule in Corticon can be thought of as being similar to a SQL SELECT statement. All entities referenced by the rule will be selected and acted upon automatically—or, to put that in Java and JavaScript terms, a rule is an iterative loop over the entities and associations used in the rule. This leads us to our next quick tip:
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.
What is an Alias in Corticon?
Aliases are similar to Java variable definitions, but are closer to SQL alias bindings. An alias is thus not just a shorthand version of an entity name. This brings me to my third Corticon tip for Java and JavaScript programmers:
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.
About Exists Operators
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.
Need More Java Programmer Tips for Using Corticon
Help is always available should you need it. Check out these online resources, or contact us anytime.
Eric Moore
Eric Moore is a Software Architect at Progress.