Corticon doesn’t just make managing your business rules without code easy. With unparalleled scalability, Corticon is designed to deliver amazing performance no matter the number of rules or complexity of your data.
The Corticon Server is a high-performance, scalable and reliable system resource that manages pools of Decision Services and executes their business rules, as defined in the Corticon Studio, against incoming requests. Progress Corticon is stateless, meaning no external data is stored in the memory of the server. This introduces a number of key performance benefits, but how can complex rules be used in an enterprise architecture without intermingling data into the rules? To answer that question, it’s important to first understand the Corticon Rule Vocabulary.
The Rule Vocabulary (figure 1) provides the basic elements of the rule language—the building blocks with which business rules are implemented in Corticon. A vocabulary is user-defined set of business “entities” and their various properties called “attributes.” Finally, “associations” define how the entities relate to one another.
1. Example of a Corticon Rule Vocabulary
Vocabulary elements are often representations of external data elements. A key value derived from using Corticon is that the rule modeler need not be concerned with where data is, only how it is used in the context of building and evaluating business rules. The decision management system should ensure that proper links are maintained between the Vocabulary and the underlying data. We often refer to this concept as abstraction—the complexities of an enterprise's data storage and retrieval systems have been hidden so that only the aspects relevant to rule writing are presented to the rule modeler. The Corticon approach is to pull all frequently changing or business user maintained logic out of a multitude of different application languages, and make it available in a common format.
So how does the Vocabulary correlate back to the underlying data?
When an instance of a Decision Service processes rules, it accesses the data in “working memory.” The working memory can be populated through any of the following methods:
- Passing it in as part of the request payload, as an XML or JSON document.
- Creating the data from the processing of rules. During rule processing, some rules may create new data, modify existing data, or even delete data. These updates are maintained in working memory until rule execution is complete.
- If, during the course of rule execution, some data from a database is required which is not already present in working memory, then the decision service asks Corticon Server to query and retrieve it from an external database.
- New in Corticon 6.0: If, during the course of rule execution, some data from a REST service is needed, the decision service asks Corticon Server to connect to a REST endpoint and treat it as if it were a database to query data from. The wealth of REST Datasources exposed through APIs means that you could be touching multiple sources to build the best complete data set possible.
What is Unique about Corticon’s Data Integration Methodology?
A key value proposition of rules engines as a software category is this concept of abstraction. But the Corticon Server does quite a bit more than just take business language and translate it into lines of if-then-else code. Not only is it allowing the rule modeler to very granularly define when and where to access external data without coding, it enables unparalleled scalability for data that is subject to frequent change.
Most rule engines use an algorithm to analyze rules during execution. This means significant processing is taking place when systems are looking for an answer from the rules system. In systems using an algorithm like this, a person typically queries a large rule base with a question, and the system converges on zero or more (sometimes conflicting) answers. Because a human interprets the results, logical inconsistencies (such as no answers or conflicting answers) are tolerated and, in fact, architecturally required in order to allow for human judgement.
Additionally, because these systems are assessing each rule when invoked, there is an inherent bottleneck. While this algorithmic analysis scales well with an increasing number of rules, it degrades exponentially with an increasing complexity of data, resulting in a performance scalability problem.
The Corticon engine was designed from the ground-up for decision automation, not decision support. Corticon took a radically different approach for decision automation. Decision Services, which are made up of sets of rules, are deployed/undeployed as a unit, so the rule engine does not need to support dynamic tweaking of individual rules.
Since Corticon Studio helps the rule author identify and resolve logical conflicts during the rule modeling phase (Figure 2), the Corticon engine’s smart compilers automatically generate optimal processing sequences for any decision service. This results in a best-of-both-worlds solution, as Corticon delivers blazing performance that scales linearly with both the number of rules and the complexity of the data.
2. Example of one of Corticon Studio's Rule Integrity Checks, the "Completeness Checker"
Corticon enables full abstraction of underlying data from the rules, without sacrificing usability for non-programmers, and all while scaling at a predictable pace. This unlocks massive new efficiency gains for organizations that are focused on reusability within their architectures. Because rules are not tied to the data that they act upon, each can be maintained individually as an architectural layer. Overlapping business functions can utilize like-for-like business terminologies for optimizing systems to respond to complex events. Decision making can be easily documented and audited from a human-readable version history. And at a time where any given organization’s success is so deeply tied to the data it can collect and analyze, Corticon provides an assurance of unparalleled scalability.
With the new release of Corticon 6, Corticon is better equipped than ever to help you make the most of your business rules. To learn more, feel free to request a demo today.
Seth Meldon
Seth Meldon is a Pre-Sales Engineer with a primary product focus area of Progress Corticon Business Rules Engine. His work is focused on educating and demoing Corticon’s expansive functionalities, use cases, and architectural strategies to internal and external audiences. You can follow Seth on LinkedIn.