◷ Reading Time: 6 minutes
Model Container and Packaging
The plumbing in the load process allows the model loader to have access to the source and navigate or reload it to a ModelContainerprovided by your application; then you have all the rules and logic you want ready in the container. The ModelContainer can implement an IModelAccess interface if you want to navigate to different sections of the container. A model container consists of multiple sections with a name and an Array of IElementModels.
Moreover, there is a PackageBuilder class that allows you to package a ModelContainerinto binary format and to add encryption and a signature during the packaging process. The FlexRule framework provides a Power Shell command line console application that allows you to load multiple models inside a ModelContainer and create a package from it as a source package.
Packages can be password-protected and digitally signed. These two mechanisms protect the application rules from disclosure and unwanted changes. To create a model container, first you need to create your rules and then, by using the FlexRule Shell application, collect them into a package. Your application will then be able to load that package into a ModelContainer and use the loaded models to create and run different rule engines. The physical, persisted representation of the rules and logic may be in either XML, S-expression, or binary package format, but once they are loaded and ready to use, they will be available as models inside a ModelContainer.
RuleSet
RuleSet is a programmatic group of multiple model containers already loaded into the application. RuleSet provides uniform resource locator (URL)–based addressing of each model.
When a RuleSet is created populated access to models happens in the memory and the engine can read models directly via ruleset:// protocol.
In each RuleSet, multiple ModelContainers can be stored, each able to have multiple rule and logic models.
This grouping allows your engines (e.g. procedural, flow and validation) to load logic and rules based on virtual addressing of a model inside a rule set. Therefore, in instantiating an engine, instead of passing an IElementModel, you can pass the RuleSet object and an address to load the model.
There are different types of RuleSet. Each of them allows organizing model containers in different structures. Depending on the type of RuleSet different addressing and behaviour is expected.
Flat RuleSet
In this type of RuleSet all the model containers will be organized in the root level.The address of this RuleSet is based on the container names and sections that follow this format:
Ruleset://{ModelContainerName}/{ModelContainerSetctionName}?{Parameter1=Value1}…
{ModelContainerName} is a name that your application will give a model container when you add it to a RuleSet. {ModelContainerSectionName} is a section name for the location of a model.
Parameters follow a specific format when you want to address a model based on its name:
parameter:{ParameterName}={ParameterValue}
For example, a parameter that specifies a rule model named MainFlow is written as parameter:name:=MainFlow.
The address will be ruleset://invoice/ver3?parameter:name=MainFlow, where invoice is the {ModelContainerName} and ver3 is the {ModelContainerSectionName}.
It is also possible to address a model based on an index of its ModelContainer inside a RuleSet, such as ruleset://0/ver3?parameter:name=MainFlow&HostType=Index. As you can see, a HostType parameter has passed the Index value to show that the {ModelContainerName} is an index, not a name. The default value for the HostType parameter is Name, which is not required to be passed.
An advantage of using a RuleSet and URL model addressing in the application is that the model’s address is abstracted, and when different engines require the loading of other rules and their execution, they do not need to know the physical location of the model—for instance, a Flow, interlink procedural rules, or [Include] commands in a procedural rule engine.
Note that when we talk about a ModelContainer, we mean any type that implements IModelAccess. By default, a ModelContainer type implements an IModelAccess interface.
This setting allows you to implement your own model access and use it in RuleSet. For example, if you are using a file system or database for your rule model repository, you can implement your own IModelAccess.
To create an instance of this RuleSet, default constructure or static method [SimpleRuleSet] can be used.
Hierarchical RuleSet
This RuleSet provides a more flexible structure to organize the model containers. Think of it as an in-memory folder structure. It allows for a nested grouping of model containers. Addressing of models would depend on where the model container is located in RuleSet.
Ruleset://{RootName}/{Name1}/{Name2}/{Name3}/… /{ModelName}
The first section of the address is Root and the last section is ModelName. During the construction of RuleSet multiple roots can also be used to organize models.
To create an instance of this RuleSet,a default constructor or static method [HierarchicalRuleSet] can be used. A default method creates a simple RuleSet that will structure rules and logic based on its underlying model container. There is a [RuleSetFactory] that allows you build a RuleSet simply by calling one method to load a RuleSet from: Directory hierarchy structure, Xml or Zip package.