Anatomy of a Rule Request

Integration to Execute Rules at Runtime

Before rules can be consumed at runtime by production applications, some integration points must be defined between calling applications and the rule engine. In general, at least a small amount of .NET code must be written to create these integration points.

Due to the fact that the InRule SDK is written in .NET code, there are many possible application architectures where similar and simple integration code and approaches can be reused. Essentially most places that a .NET application can run are also possible places where InRule can run. The InRule integration can normally be accomplished with just a few lines of .NET code, and then exposed to any number of consuming applications using reusable DLL or service interfaces.

Runtime rule execution is accomplished by creating a "rule request" to the rule engine, and then consuming output as necessary after the rule engine has completed executing rules. A rule request is minimally comprised of the following components that must be instantiated by application integration code:

• Rule Session - the RuleSession is a public class in the InRule SDK. It serves as the main programming interface for developers that are invoking the rule engine. The Rule Session automatically manages communication between user-provided data, rules, and rule engine operations.
• Entity (Application Data) - At least one InRule Entity must be created by the integration code. The Entity is a wrapper that the rule engine uses to read and write to data provided by calling applications. The underlying objects that are wrapped by the Entity instances are generally custom .NET types, XML, or JSON. However, InRule also supports the ability to construct custom data providers if other backing stores are required. Root Entities must be created explicitly in integration code, but children of these root Entities will be automatically generated by the rule engine during rule processing.
• Rule Application Reference - The Rule Session must be directed to run a specific set of rules against the Entity data that is provided. The Rule Session accepts a "rule application reference" that it can use to either automatically locate an existing rule application cache entry, or load rules and populate the rule application cache on-demand.
• Rule Execution Settings (Optional) - Prior to execution, the developer can adjust rule execution behavior using an extensive list of settings exposed by the InRule SDK. In many cases the default settings are adequate for a given production application; in these cases no settings need to be provided by the developer.

After a Rule Session has been populated with the required input, rules can be invoked by issuing either an Apply Rules or Execute Rule Set call to the Rule Session.

The Anatomy of a Rule Request

Free Threaded Caching per .NET App Domain

The Rule Session automatically manages four thread-safe caches that are maintained by the InRule SDK. Most developers do not need to write any code against these caches, but they should be aware that they exist and affect performance and memory usage of the rule engine.

• Compiled Rule Application Cache - This cache contains the compiled rule applications that have been consumed by the given .NET AppDomain. A compiled rule application contains related sets of rules, along with dependent end point and schema definitions for those rules.  When a rule request is sent to the engine, rule applications are compiled on demand and added to this cache if they are not already present
• Delegate Cache - This cache contains state access delegates that are used by the rule engine to read and write to state. This cache is populated on demand during rule execution.
• SQL Query Results Cache - This cache contains record sets returned from Execute SQL Query rules and Value Lists. This cache is populated on-demand, and is not used if no rules integrate with SQL queries.
• Web Service Results Cache - This cache contains result sets returned from rules that execute web service calls. This cache is populated on-demand, and is not used if no rules integrate with web services.