Wonka Rules Engine : Introduction to Data Domains

In order for the Wonka rules engine to be instantiated with the XML markup rules, the user must first instantiate the data domain. This domain establishes the lexicon that is used when writing the rules in order to refer to specific data points. For example, the following rule:

<eval id="pop1">(N.BankAccountName) POPULATED</eval>>

mentions the data point 'BackAccountName', which must be defined beforehand (the data type, the length, etc.). We refer to these data points as Attributes. The user can define these Attributes by manually adding them or by supplying a Data Source that can be ingested. Once the data domain has been established, the user can then use Attributes to create a record (i.e., WonkaProduct) that can be submitted to this rules engine, which will evaluate (and possibly manipulate) the record through the execution of a RuleTree.

The "N" portion before the Attribute (as seen above) refers to the Data Source, which we will describe farther below.

Ways to Instantiate a Data Domain

In order for an user to manually define the data domain, they must create a class that implements the IMetadataRetrievable interface and supply it via the CreateInstance() method:

WonkaRefEnvironment.CreateInstance(bool bAllMetadata, IMetadataRetrievable pMetadataRetrievable)

However, in the case that the user understandably does not want to manually define the data domain, there are various ways to leverage provided functionality found in the libraries, including the following:

• WonkaRefDeserializeLocalSource --> This class (that implements the IMetadataRetrievable interface) will provide the data domain by deserializing a XML file that describes all intended Attributes.
• WonkaImportFactory.ImportSource(string psDatabaseTable, SqlConnection poDbConn) --> This method will examine the columns of the table 'psDatabaseTable' and return an instance of WonkaImportSource (that implements IMetadataRetrievable), which will describe all intended Attributes.

Using the Data Domain to Create Records

Once the data domain has been defined, the user can refer to the Attributes when creating the records that will be consumed by the rules engine. For example, the lines below show how to create a record (i.e., WonkaProduct) and then set the value of an Attribute on the record:

WonkaProduct TestProduct = new WonkaProduct(); TestProduct.SetAttribute("BankAccountName", "MyNameIsMud");

Once all values have been provided to the record, we can then submit the record to an instance of the rules engine:

var Report = MyRulesEngine.Validate(TestProduct);

Each instance of the rules engine is instantiated with a provided Ruletree.

Data Sources

Even though a data domain has been defined, these Attributes only represent the definition of the data. However, we still need to know from where to draw the data. In other words, we need to know the Data Source. Currently, when executing an instance of the rules engine within the .NET domain, there are two Data Sources used by default (and they are the only ones currently allowed):

• "N" --> Refers to the record supplied via the Validate() method on the rules engine.
• "O" --> Refers to an alternate (or "other") record that can be assembled via a supplied delegate (i.e., RetrieveOldRecordDelegate on the rules engine).

In the future, other Data Sources might be allowed. Currently, the rules engine does have a property called SourceMap, but these Data Sources are used for serializing the rules engine to its sibling Solidity contract and for interacting with Ethereum when executing a Ruletree on the blockchain. This topic will be discussed later, in a different doc.