By attaching rule statements to the rule columns Corticon provides an automatic mechanism for providing an explanation of which rules fired and why. This makes generating an audit trail very easy

However the messages that are generated by this means are inaccessible to Corticon rules which means you cannot write rules to eliminate duplicate messages or determine the more important messages or count the number of violation messages and the messages cannot be written to a database using EDC – something that was possible in version 4.3 of Corticon - in 5.5 you would need to add some code to your application that calls Corticon to allow it to save the rule messages to a database.

If you need to exercise more control over the content and disposition of such messages here is one way to do it



By supplying (or omitting) an empty “seed” instance ofMessage in the input payload you can control the generation of the messages:

Any number of additional attributes can be added to the Message object and set in the rule columns (something that is not possible if you use the build in rule statements)

And because the messages are instances, it becomes possible to write rules that can analyse the messages. Eg counting different types, totalinq the score, merging similar messages etc

These messages can also be stored in a database using EDC


Download PDF version.