Rules
Rules are used to govern the behavior of the HumanOS® Kernel structures. There exist different types or rules:
Type | Description |
---|---|
GenericRule | Generic condition-action rule |
InstantiationRule | Rule managing schema instances within a group of nodes. |
PortMatchingRule | Special rule used for processing networks. Allows to dynamically connect ports and data nodes in a given group of nodes. |
Generic Rule
The TRule
class can be used in many ways, like building groups, starting commands or workflows etc. Generic rules are made of three components:
- Trigger Event: The event that triggers the rule
- Trigger Condition: The condition that triggers the rule
- Rule Action: Action to be performed if the rule is executed
Trigger Events
Following trigger events are valid:
OnObjectAppeared
: Event if a node is added to a groupOnObjectDisappeared
: Event if a node is removed from a groupOnPropertyChanged
: Event if a property of a node has been changedOnTimer
: Event if a timer trigger has occured
Trigger Condition
The trigger condition is a lambda expression that validates the event and the node causing the event. Two objects are passed:
- Node: referencing the node causing the event.
- Relation: referencing the relation between node and the group (valid for
OnObjectAppeared
andOnObjectDisappeared
events).
Example:
Context.Node is IWorkflow
Context.Node.getProperty<int>("TotalRuns") == 0
Expression Rule Action
Two objects are passed to the lambda expression
- Call: Action call. Can be used to reference action arguments.
- Kernel: Kernel access interface
Example:
{
"Id": "C9FFEE4C-2320-49B7-879C-D71605315BE0",
"Name": "WorkflowStartRule",
"Type": "GenericRule",
"TriggerEvent": "OnObjectAppeared",
"TriggerCondition": "Context.Node is IWorkflow",
"Action": {
"Type": "Expression",
"Arguments": [
{
"Name": "workflow",
"Predicate": "Node.hasProperty<string>('Name', 'HostSetup Workflow')"
}
],
"NativeExpression":
"Kernel.WorkflowManager.triggerWorkflow(Call.getNodeArgument('workflow').GlobalId"
}
}
Command Rule Action
The commanded rule action can be used to reference commands and workflows and passing arguments.
Example:
{
"Id": "C9FFEE4C-2320-49B7-879C-D71605315BE0",
"Name": "WorkflowStartRule",
"Type": "GenericRule",
"TriggerEvent": "OnObjectAppeared",
"TriggerCondition": "Context.Node is IWorkflow && Context.Node.Name == \"MyWorkflow\"",
"Action": {
"Type": "Command",
"Arguments": [
{
"Name": "Node",
"Predicate": "Node.getProperty<int>('TotalRuns') == 0"
}
],
"CommandExpression": {
"Node": "$(Node)",
"Arguments": []
}
}
}
Scripted Rule Action
The scripted rule action allows to execute complex source code if a rule is triggered.
The script files are located in $(ConfigPath)\Scripts\Rules
.
Example:
{
"Name": "Test.Schema.ScriptedRules",
"Id": "D666E8F0-5180-4DE5-BB99-4475F081BE8B",
"Rules": [
{
"Name": "Test.ScriptedRule1",
"Type": "GenericRule",
"TriggerEvent": "OnObjectAppeared",
"TriggerCondition": "",
"Action": {
"Type": "ScriptFile",
"Arguments": [
{
"Name": "NodeToAdd",
"Predicate": "Node.Name == 'Node1'"
},
{
"Name": "Group",
"Predicate": "Node.Name == 'Group1'"
}
],
"ScriptFile": "TTestRule_Script1.cs"
}
}
]
}
Script:
public class TTestRule_Script1 : TAbstractRuleScriptObject
{
///<see cref="TAbstractRuleScriptObject"/>
public override void execute(IKernelAccess Kernel, IVariablePool Pool)
{
IGroupRelation Group1 = Pool.getValue<IGroupRelation>("Group");
INode Node1 = Pool.getValue<INode>("NodeToAdd");
Kernel.NodeSpace.addNodeToGroup(Group1.GlobalId, Node1.GlobalId);
}
}
Instantiation Rules
Instantiation rules are used to instantiate schema dynamically based on some happening in the observed group or space.
Like generic rules, instantiation rules are mode of TriggerCondition and RuleAction.
The TriggerEvent can be set to None
because instantiation rules handle the events OnObjectAppeared
and OnObjectDisappeared
likewise.
The RuleAction part is specified by the following fields:
Attribute | Description | Data Type |
---|---|---|
SchemaId | Id of the schema to be loaded | System.Guid |
SynchronProcessing | Flag if the instantiation is synchronously or asynchronously | System.Boolean |
Property::FullCleanup | Flag if the instances and its sub elements are fully removed upon OnObjectDisappeared events. | System.Boolean |
Example 1:
{
"Name": "WorkflowInstantiationRule",
"Id": "4A0AB232-CEB8-42E3-B71F-FAEED03584DE",
"Type": "InstantiationRule",
"TriggerEvent": "None",
"TriggerCondition": "Context.Node.hasProperty<Guid>('DriverId', Guid.Parse('{BE79A86B-38EE-4FAA-805A-1DB46A06E65D}')) && Context.Node.hasProperty('HostName')",
"SchemaId": "8E5BEB09-8BA9-456A-957C-10444A26096D",
"SynchProcessing": true,
"Properties": [
{
"Name": "FullCleanup",
"DataType": "System.Boolean",
"Value" : true
}
]
}
Example 2:
The condition expresses that the rule is executed once an object with the property "DriverId" == {51F3D53D-8353-4BDC-B037-39C2644D0D6A}
appears..
{
"Name": "Rule1",
"Id": "4A0AB232-CEB8-42E3-B71F-FAEED03584DE",
"Type": "InstantiationRule",
"TriggerEvent": "None",
"TriggerCondition": "Context.Node.hasProperty<Guid>('DriverId', Guid.Parse('{51F3D53D-8353-4BDC-B037-39C2644D0D6A}'))",
"SchemaId": "8E5BEB09-8BA9-456A-957C-10444A26096D"
}
Port Matching Rules
Port matching rules are used to auto-wire ports with each other. They are mainly used to load processing network schema dynamically.
{
"Id": "13E8EBE5-71D9-4D54-9EA2-FFB29641FFBD",
"Name": "HumanOS.PeSeL.Correlations.PortMatchingRule",
"Type": "PortMatchingRule"
}
Additionally, the port matching property name can be set. Default value is PortMatchId
. Name of the property is PortMatchingPropertyName
.
Example:
{
"Id": "13E8EBE5-71D9-4D54-9EA2-FFB29641FFBD",
"Name": "HumanOS.PeSeL.Correlations.PortMatchingRule",
"Type": "PortMatchingRule",
"Properties":[
{
"Name": "PortMatchingPropertyName",
"Value": "MatchingId"
}
]
}