Policies contain a list of rules and provide some basic search and filtering to find the rules you are looking for. Policies can be active or inactive and can be locked. A history is kept of rule changes and each can be compared to see differences with the option to rollback to old versions. For each policy team members can be assigned and given various permissions. In addition a set of test facts can be assigned. Each of these is expressed as a JSON object. Basic checking of the editing of these objects is included.
Each rule has a name, condition, action and results. The condition handles situations in which the rule should not be evaluated (missing data, date ranges etc). The action defines the rule itself along with any variables. Result defines what is returned to the calling application – a JSON structure to hold the results for instance. Rules can be tested using any of the defined test data. The structure of the data in the test data is available in a type ahead editor when writing conditions or actions.
The rule engine is invoked with a set of data and a policy name or id passed to a REST API .It can be executed on a single fact set or a collection and can execute one policy or several. When the rule engine is involved for a policy the results will include a node for each of the rules executed – the results of each rule execution are passed back as a set. In addition a .NET client library is available with other languages planned (Java, PHP etc).
The environment also has some management tools, letting you view rule execution/usage. Payment is a subscription model with customers paying for a certain number of rule executions. Invocation is protected by an API key that is passed as part of the execution.
Future plans include unit test management, improved rule validation and editing, scheduling, more languages and more detailed outcome reporting.
You can get more details on RulePlex here.