RuleEngine
Funktionsbeschreibung und Anwendung
Der RuleEngine-Block dient der Beschreibung von Zustandsübergängen anhand einlaufender Nachrichten in Abhängigkeit von Vorbedingungen. Dabei können Form und Inhalt der Ausgangsnachricht frei definiert werden.
-
Es existiert ein Kontext in dem Informationen abgelegt werden können, die bei der Auswertung der Bedingungen oder in der Ausgangsnachricht verwendet werden können. Der Kontext kann initial mit Informationen gefüllt werden.
-
Es gibt eine Menge von "RuleSets", welche (Vor-)Bedingungen beinhalten.
-
Jedes RuleSets kann eine Menge von "Rules" enthalten, die ebenfalls über Bedingungen verfügen.
-
Weiterhin können ein "defaultRuleSet" sowie in RuleSets "defaultRules" angelegt werden, die keine Bedingungen enthalten.
Jede Bedingung muss einen boolschen Zustand zurückgeben. Jede Bedingung, die keinen boolschen Zustand zurückgibt, ist automatisch "Falsch" (false). In den Bedingungen kann auf Inhalte des Kontextes und der eingehenden Nachricht (header & body & context) zugegriffen werden. Damit eine "Rule" zutrifft, müssen alle Bedingungen von dieser erfüllt sein.
Die Tabelle conditions wurde durch den Condition-Builder ersetzt.
Der Condition Builder ermöglicht die Konfiguration über den Visual Editor. Es können folgende Werte konfiguriert werden:
-
Source (header, body, context)
-
Property
-
Operator
-
Comparison value
Im Text Editor werden die konfigurierten conditions angezeigt.
Zuerst werden die Bedingungen der definierten RuleSets der Reihe nach, von RuleSet-1 ausgehend, geprüft. Sobald ein RuleSet die Bedingungen erfüllt, wird dieses RuleSet für die weitere Verarbeitung der Nachricht ausgewählt. Erfüllt kein RuleSet die Bedingung, wird das defaultRuleSet gewählt, sofern es angegeben ist, andernfalls erfolgt ein Abbruch.
Anschließend werden im ausgewählten RuleSet die Rules geprüft. Die Reihenfolge der Prüfung ist abhängig von der definierten Reihenfolge der Rules in der Baumstruktur. Entsprechend kann eine Überprüfung der weiteren im RuleSet enthaltenen "Rules" übersprungen, die „zutreffendste“ oder die letzte zutreffende "Rule" verwendet werden. Erfüllt keine Rule die Bedingungen erfolgt ein Abbruch. Folglich wird im RuleEngine-Block nur ein RuleSet und darin nur eine Rule verarbeitet.
Das Ergebnis einer "Rule" wird in dem Kontext abgelegt, der Inhalt des Kontext wird gepatched. Es können gezielt Inhalte aus dem Kontext nach dem Patchen entfernt werden.
-
Wird das angegebene Message Template nicht gefunden, wird das Message Template "default" genommen.
-
Die Ausgangsnachricht wird anhand des Message Templates erzeugt.
-
Ist in dem Message Template kein Header definiert, werden die Informationen "source" und "scope" aus der Eingangsnachricht übernommen.
-
Ist in dem Message Template Header kein "source" und/oder "scope" definiert, werden die Informationen aus der Eingangsnachricht übernommen.
-
Ist in dem Message Template kein Body definiert, enthält die Ausgangsnachricht keine Informationen im Body.
-
Nach dem Erfüllen einer "Rule" wird eine Ausgangsnachricht an alle zugewiesenen Input bzw. Output Topics gesendet.
Bezeichnungen und Syntax
Die in den folgenden Tabellen erläuterten Parameter sind in einer beispielhaften Konfiguration und deren Abbildungen im folgenden Absatz zu finden.
| Parameter | Beschreibung |
|---|---|
Name |
Name der Blockinstanz |
Context |
Optionaler Bereich in dem Variablen mit oder ohne initialen Inhalt initialisiert werden. Jedes Contextelement kann in den Bedingungen verwendet werden. |
RuleSets |
Zusammenstellung von Bedingungspfaden/Zustandsüberwachungen. Es können beliebig viele erstellt werden. Die angelegten RuleSets erscheinen als Reiter unterhalb der Eingabemöglichkeit. Die Namen "RuleSets-n" können nicht geändert werden, n steht hierbei für eine fortlaufende Zahl. Hier kann auch ein „DefaultRuleSet“ definiert werden. |
Message Templates |
Beliebig viele Vorlagen für die Ausgabe von Nachrichten und Daten. Es können hier alle Elemente aus dem Nachrichtenbereich Header und Body bearbeitet werden. |
| Parameter | Beschreibung |
|---|---|
Name |
optional, Name des Kontextelementes |
Value |
optional, Inhalt des Kontextelementes |
| Parameter | Beschreibung |
|---|---|
DefaultRuleSet |
Zu befüllen wie ein normales RuleSet mit Rules – jedoch ohne Bedingungen. In diesem RuleSet können wiederum Rules angelegt werden, die diverse Bedingungen enthalten. |
Conditions |
optional, globale Bedingung(en) damit in diesem RuleSet die Rules auf Übereinstimmung geprüft werden. |
Rules |
Es kann zwischen den Reitern per Pfeiltasten gewechselt werden. Zusammenstellung von Bedingungspfaden/ Zustandsüberwachungen zur Verfeinerung der Bedingungspfade. Es können beliebig viele erstellt werden. Die angelegten Rules erscheinen als Reiter unterhalb der Eingabemöglichkeit. Die Namen können nicht geändert werden – Rules-n, n steht hierbei für eine fortlaufende Zahl. Hier kann auch ein „DefaultRule“ definiert werden. |
Rules – Context |
Beliebige Anzahl von Contextelementen |
Rules – Context – Name |
Name des Contextelementes |
Rules – Context – Value |
Inhalt des Contextelementes |
Rules – Obsolete context |
Hier können Elemente des Context entfernt werden. |
Rules – Message Template |
Optionale Eingabe eines Namens für das Message Template zur Erstellung der Output-Nachricht |
| Parameter | Beschreibung |
|---|---|
Header – Name |
optional, Name des zu erstellenden keys |
Header – Value |
optional, sofern kein Name/ key definiert wurde, Wert aus dem Context, Body, Header oder selbstdefiniert |
Body – Name |
optional, Name des zu erstellenden keys |
Body – Value |
optional, sofern kein Name definiert wurde, Wert aus dem Context, Body, Header oder selbstdefiniert |
Verwendung von Elementen aus Header, Body und Context:
-
Groß- und Kleinschreibung ist zu beachten
-
Um das Element source aus dem Nachrichtenbereich Header zu erhalten, muss header_ für den zu verwendenden Bereich und source für das Element eingegeben werden. → header_scope
Verwendung einer Zeichenkette/ String
-
Eine Zeichenkette wird mit einem vorangehenden „ ‘ „ und einem abschließenden „ ‘ „ gekennzeichnet. Bsp.: ‘Zeit verstrichen‘
-
Werden die Zeichen nicht verwendet, so wird die Eingabe wie eine Variable verwendet.
Beispielkonfiguration
Die schrittweise Konfiguration im Stream Processor wird am folgenden Beispiel dargestellt. Es werden Daten eines OPC UA Servers verarbeitet. Die Reihenfolge sollte wie beschrieben erfolgen, da so alle angezeigten Auswahlmöglichkeiten im Zuge der Konfiguration zur Verfügung stehen. Auswahlwahlmöglichkeiten stehen immer erst nach einem Speichervorgang zur Verfügung.
Voraussetzung: Im Modul OPC UA wurde ein OPC UA Server mit dem Output Topic „OpcuaOut1“ konfiguriert (Abbildung 1).
Nun werden die grundlegenden Elemente im Stream Processor angelegt bzw. konfiguriert (Abbildung 2):
-
Topic "OpcuaOut1" unter "Settings" als Input Edge Topic hinzufügen
-
Input-Block "switch1" anlegen und Source (OPCUA) und Scope (OpcuaOut1$) konfigurieren
-
RuleEngine-Block anlegen mit Name "UsingRules"
-
Output-Block "OUTBlock" anlegen
Die Konfiguration der RuleEngine erfolgt unter Context, RuleSets und Message Templates.
Im Tab RuleSets bzw. Message Templates steht eine Baumstruktur zur Verfügung. Um die Reihenfolge der Elemente in der Baumstruktur zu verändern, lassen sich diese via drag & drop verschieben.
Neue Unterelemente können über ein "+" im Baum neben dem übergeordneten Element angelegt werden.
Die Unterelemente können über über die Schaltfläche 
entfernt werden.
Um die Konfiguration zu übernehmen, muss diese über die Schaltfläche 
gespeichert werden.
Weiter in der Beispielkonfiguration RuleEngine-Block:
Es folgt die Definition der Message Templates "default" und "Rule1" im RuleEngine-Block:
-
default: Änderung des Inhaltes des Headers von Source mit einer Zeichenfolge und des Inhaltes Zusatzinformation mit einer Zeichenfolge im Body (Abbildung 3)
-
Rule1: Änderung des Inhaltes des Headers von Source mit einer Zeichenfolge und Scope mit dem Inhalt eines Elementes vom Context. Der Body wird mit Werten aus dem ursprünglichen Body - statUint und dynUint – befüllt und mit während der Abarbeitung der Rules generierten Werten – Kontext1 und Zusatz (Abbildung 4).
Anschließend wird der Context des Block "UsingRules" konfiguriert, hier optional die Eingabe von Kontext mit Inhalten(Abbildung 5).
Es folgt die Konfiguration der RuleSets:
-
DefaultRule (Abbildung 6)
-
RuleSets: Add Default → DefaultRuleSet erstellt
-
DefaultRuleSet:Add Default-→DefaultRule erstellt
-
Context und Into wurden leer gelassen
-
Im Obsolete Context werden die Elemente Kontext2 und Kontext3 entfernt
-
Message Template "default" angeben
-
Ist das RuleSet-1 erstellt, müssen die Rules mit ihren Bedingungen konfiguriert werden.
-
Rule Set-1-→Add Rule → Rule-1 erstellt
-
Konfiguration der Conditions im Visual Editor
-
Source: body
-
Property: dynUint
-
Operator: >=
-
Comparison value: 30000
-
-
Im Context werden zwei Elemente mit einem neuen Wert beschrieben:
-
RulesetTest mit der Zeichenfolge 'RuleSet1 Rule1'
-
Kontext1 mit der Zeichenfolge 'dynUint >= 35000'
-
-
Obsolete Context wird leer gelassen
-
Message Template mit Rule1 angeben
-
-
Rule Set-1-→Add Rule → Rule-2 erstellt (Abbildung 9)
-
Konfiguration der Conditions im Visual Editor
-
Source: body
-
Property: dynUint
-
Operator: ⇐
-
Comparison value: 10000
-
-
-
Im Context werden zwei Elemente mit einem neuen Wert beschrieben:
-
RulesetTest mit der Zeichenfolge 'RuleSet1 Rule2'
-
Kontext1 mit der Zeichenfolge 'dynUint < = 10000'
-
-
Obsolete Context wird leer gelassen
-
Message Template mit Rule1 angeben
Abschließend müssen die konfigurierten Blöcke verbunden werden (Abbildung 11).
Mit dieser Konfiguration kann nun über den MQTT oder über andere Schnittstellen die fertige Nachricht ausgegeben werden.