Summary

Currently in Corticon if you want to create a new operator you have to write it in java and add it to Studio for all rule authors. You also have to add it to the Server (which will require restarting server). Sometimes this is necessary to add functionality that Corticon does not support. But sometimes the operator may be implementable using Corticon functionality.

The basic idea here is to allow a rule sheet to implement an operator so that other rule sheets can call it just like an extended operator. Then that functionality can easily be added to any rule project and can be deployed without restarting the server.

To achieve this today you would have to create the rule sheet and add it to the rule flow somewhere prior to the rule sheet that uses its result.

Example

An operator named "BMI" that takes the height and weight as inputs and returns a body mass index classification could be defined as a rule sheet (or rule flow) like this:

And then used in another rule sheet like this:

A More Complex Example

Consider this rule sheet:

Suppose each of the inputs A...H is derived in a separate rule sheet.

Currently Corticon will require you to put all those rule sheets in the rule flow prior to executing this rule sheet.

But suppose 99% of the time its rule 1 that fires (which only requires that we execute rule sheet A). We may have unnecessarily executed rule sheets B...H. If these were large or complex rule sheets this could impact performance.

If instead rule sheets A...H are implemented as operators then they will only be executed when needed.

Restrictions

In order to avoid disrupting the execution of the "calling " rule sheet, the "operator" rule sheet would probably have to be restricted to operating on its own local data and just like a normal extended operator, only return a single value conforming to one of the basic data types.  Maybe it uses its own local vocabulary so that such a rule sheet can easily be dropped into any rule project.