en en en en en en en en en en en pt en en en en en en en en en kn en en en en en en en en en en en en en en en en en en en en en en en en en pt en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en fr en en kn en en fr de en en en en en en en en en en en en en en en en en en en en en az en pl kn en en en hu en en en en en en kn de en pl en en en kn tr en en en en en en kn de en en en en fr tr en en en en en en en en en en kn tr en en my en en ja en en en en en en en kn en en en en en en en en en en en en en en en en pt en sv fr fr en en en en en en pt en en en en en en en en en kn en en en
RuleSet is an in-memory container that holds logic models and gives an addressing capability to access an already loaded model. RuleSet allows the categorizing of rules in a nested (hierarchical) manner. This function allows logic and rules to be grouped conceptually based on your problem domain. Although we call this container RuleSet, please note that it is a container that stores all of the rules and logic in-memory. This logic can be business rules, application flow, procedure, validation, decision, decision table, etc., as well as anything that implements IElementModel. All models can be grouped and stored in one or more RuleSets.
The way you group and organize these models varies by system. Depending on your architecture and the complexity of the scenario and logic, you may have more than one RuleSet for a scenario. Grouping and organizing rules and logic sources into folders is common sense, especially when you have many of these and you need to selectively load them as part of different user stories or scenarios.
Each logic document can be identified with two names:
Therefore addressing logic documents inside a ruleset can be done either by using:
When a ruleset is created from a RuleFile then the address of the logic documents inside a ruleset can be achieved using a relative path and filename.
sub1, sub2, sub3,…: These are categories you can define to organize your rules in a RuleSet. It is very similar to organizing your files in a File System.
logic name: The name you defined for the logic. This is not the logic’s file name. It is the actual model name for specific logic.
Where DateCheck is the name of the validation logic.
You may store your logic in a RuleSet directly, without organizing it in a different hierarchy (e.g., sub folders). In this case you will have the following format.
As you can see, the above format still follows the original, but does not include any category (e.g. sub folder)
How to Build a RuleSet
There are multiple ways to build a ruleset:
Create from a folder structure
Create from a Package file (standard zip package)
Manually loading models into a ruleset
When building a ruleset using DirectoryInfo, you can create two types of ruleset that each support different addresses based on
Relative path and filename
Using RuleSetFactory.FromRuleFiles will create a ruleset in which each logic document can be addressed by a relative path and filename.
var path= @"ADDRESS\TO\RULES\FOLDER"; var rulesLocation = new DirectoryInfo(path); // we can build the ruleset now var ruleset = RuleSetFactory.FromRuleFiles(rulesLocation);
Using RuleSetFactory.FromDirectory creates a ruleset in which each logic document can be identified by a protocol address
var path= @"ADDRESS\TO\RULES\FOLDER"; var rulesLocation = new DirectoryInfo(path); // we can build the ruleset now var ruleset = RuleSetFactory.FromDirectory(rulesLocation);
The manual process of building a ruleset allows you to selectively add different logic documents to the collection.
Using FromRuleFiles(IEnumerable ) creates a ruleset in which each document can be addressed by relative path and filename.
var rs = RuleSetFactory.FromRuleFiles(new List () { new RuleSetFactory.RuleFile("doc1.xml", null, File.ReadAllBytes(Path.Combine(Folders.Data, "Database", "doc1.xml"))), new RuleSetFactory.RuleFile("doc2.xml", null, File.ReadAllBytes(Path.Combine(Folders.Data, "Database", "doc2.xml"))), new RuleSetFactory.RuleFile("doc3.xml", "folder1", File.ReadAllBytes(Path.Combine(Folders.Data, "Database", "doc3.xml"))) });
You can also pick different files from different locations and build your ruleset manually:
Loading your model using LoadAdapterUtility
Adding each model to Hierarchical RuleSet
Use AddModel extension method below:
///   /// Allows the addition of individual models as part of a ruleset ///   ///  Ruleset to append the model to in a specific location as    ///  Address of a model. Can be nested by / (i.e., rules/flows/purchase ) ///  List of models to be added into the   section  public static void AddModel(this IRuleSet rs, string query, params IElementModel[] models)
public IRuleSet LoadFlowRuleSet() { var ruleset = RuleSet.HierarchicalRuleSet(); // adding all activities ruleset.AddModel("flow/activities", ReadModel("SendEmail.xml"), ReadModel("AssignToManager.xml"), ReadModel("AssignToUser.xml") ); // adding libraries procedures ruleset.AddModel("flow/library", ReadModel("CreateAssignment.xml")); // adding the main flow ruleset.AddModel("flow", ReadModel("CaseHandlingWorkflow.xml")); return ruleset; } private IElementModel ReadModel(string path) { // _basePath is the base location that all models are located var fullPath = Path.Combine(_basePath, path); return LoadAdapterUtility.LoadModel(fullPath); }
Where RuleSet can be used
1. ProcSource command of CallProc
In a procedural engine, multiple procedures can be interlinked. This means that a procedural rule can execute another rule; thus, the context of the parent rule can be shared, and the result can be copied back to the root context. Different scenarios can be managed in several ways.
In all bellow commands uri can refer to a RuleSet address ruleset:// when the execution plan is loaded by the RuleSet or RuntimeEngine with RuleSet is used:
If your application logic is complex and requires multiple Procedural rules, this command can call an externally defined rule and return the result to the running execution context.
ProcSource command of CallProc
Description: Sets the context for the called procedure
Creates a new context and uses such context for execution; in this
case, the variable of the new context must be registered by the Param
Shared: Uses the current context for execution and the
new procedure after finishing the procedure execution; the current
execution variable context (of only out-variables) is copied to the
This attribute is set when the target procedure has variables that need
to be accessed via the root executing procedure.
None: Does not copy
AddBoth: Copies both in- and out-variables
Description: Sets a value of a parameter as a return value of the operation/call
Types: String (name of a parameter
This command passes a value to the procedure and registers new variables in a new context if required.
This command provides the rule with a source to be loaded and executed. It can be a relative or absolute file path or a RuleSet address. If it is a relative file path, the location is initiated from your application’s execution folder. If it is a RuleSet address, it should be a valid address, and the engine should be initialized using RuleSet overload.
2. FlowSource command of CallFlow
CallFlow allows calling a flow with another logic.
Description: How the parameters are shared with the calling Flow
Description: Where is the source of flow to be run
Type: Physical file or RuleSet address
3. DecisionTableSource command of CallDecisionTable
Description: Set context behaviour to call to other rules and logic. If set to Shared, the current context will be used for the target rule. Otherwise a new one is created.
Description: Where is the source of the external DecisionTable to be run?
Type: Physical file or RuleSet address
DecisionTable integrated into a Flow.
DecisionTable integrated into a Procedure.
4. DrdSource command of CallDrd
5. GlossarySource command of GlossarySource
Description: Sets address to a glossary, it can be relative file system address or a ruleset address
Mandatory: Yes (when it is the container for defining Terms)
Note in the Condition section (lone 10 to 15) no expression is used and instead term is used.
true   false   false         High   R1
6. ValidatorSource command of Validator
Also the RuleSet address can be used in the Include command
source setting of Include
This command enables you to split your procedural rules into more dynamic scopes and to import each scope to the body of the rule during the execution process. By supplying the source to be imported as a string or IElementModel type, the scope will be considered as part of your rule body.
If the imported scope is a string type, it must be encoded as a valid XML or RuleSet address. If it is an XML, its special characters must be respected. Also, the imported string must be encapsulated with a Scope command. If it is a RuleSet address, it should be a valid address, and the engine should be initialized using RuleSet overload.
The behavior included will not be executed. In order to do so, the Call command must be used. The included source parameter can accept a ruleset address as well (e.g., ruleset://flow/main?parameter:name=CreateCaseOfficer)
Description: Assigns a source that is imported by the command, as well as a variable name or ruleset address. If it is variable name, the variable type must be defined as a String or IElementModel.
Type: String (variable name)
For example, in Validation logic you can use the Include command to reference a loaded Logic. For more information please check Referencing external logic.
You can use a RuntimeEngine to create an instance of an engine directly from a RuleSet address.
// Here we assume the ruleset is for path and filename addressing: var engine = RuntimeEngine.FromRuleSet(rs, "Premiums DRD.xml");
All execution plans can be created using a RuleSet address.
var engine = RuntimeEngine.FromRuleSet(rs, "ruleset:///Premiums DRD"); var flow = new Flows.Flow(ruleset, "ruleset://Flows/Purchase/OrderRuleFlow");