Automating business decisions with Corticon rules
Progress Corticon is a Business Rules Management System with a patented rules engine that enables you to automate sophisticated decisions without writing code. To add these capabilities to your app, use a Corticon Decision Service trigger. The trigger sends application data in a request. The Decision Service uses the request values as input to its rules and sends the results back to the trigger. You can configure the results to be mapped into existing and/or new Platform records.
For example, a trigger might send information about an insurance applicant — such as age, gender, and health history — to a Decision Service configured with complex rules defining cost and coverage. The Decision Service could return a quote along with information that explains the decision.
To configure a Corticon Decision Service trigger, you need the following:
- Access to a Decision Service compiled on and deployed using Corticon server version 5.6 or later.
- An understanding of the data expected by the Decision Service and expected results.
When configuring a trigger to invoke a Decision Service, you use a visual mappper to associate fields from Platform objects with attributes and messages of Corticon entities. The Decision Service generates messages to communicate the results of rule execution. You can map object fields to entity attributes and messages of compatible data types or data types for which Platform can provide conversion. The visual mapper indicates the data type next to object and entity fields, as shown below, where age is an integer and gender is text.
You can map fields from the object on which the trigger is defined and from
objects directly related to it. For example, if a trigger belongs to object A and object
A has a relationship with object B, while object B has a relationship with object C, you
can map fields from A and B — but not from C, as illustrated below. The same rule
applies to Corticon entities. 
The trigger supports mappings between related objects and entities with "to-many" cardinalities. When multiple related records and entities exist on both sides, the trigger handles them in the request and response. If the cardinality of the relationship for mapped items does not match, the trigger limits the scope of recursion. For example, if a field in an object with many records is mapped to an attribute in an entity with a cardinality of one, the trigger sends only the values from the first related record in the request. Likewise, on the decision service side. When a mapping exists from an entity or message with a to-many association cardinality to a field in an object with a cardinality of one, only the response or message from the first matching entity will be returned. See Supported relationships for request mapping and Supported relationships for response mapping for details.
Platform relationship and Corticon association cardinality notation displays in the mapping tool as follows:
- (*) — Indicates a multiple relationship with the base object or base entity
- (1) — Indicates a single relationship with the base object or base entity
The following screen shows the cardinality notation of the relationships between Car and Message and Car to Person:
See the following topics for detailed information about how relationships and cardinality affect mapping:
The visual mapper allows you to filter entities in its tree structure so that you can focus on the items of interest. You can select different sets of entities to display in the request mapping and in the response mapping. If no entities are selected, the tree structure displays all entities in the Decision Service. Filtering has no effect on the mappings. Although they disappear when filtered out, just remove the filter to view them again.Platform generates the trigger formula to access the Corticon Decision Service and handle the response. A portion of the formula contains methods that you can override to provide custom functionality. For example, you might want to insert logic in the generated trigger code to capture information about the Decision Service and save it as Platform data. Information such as time when a Decision Service was invoked, the request data, and the response data could be useful when debugging or to review events that occurred during normal operation.
