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.
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 „Evaluation Stategy“ (FirstMatch, BestMatch oder LeastMatch). Entsprechend kann eine Überprüfung der weiteren im RuleSet enthaltenen "Rules" übersprungen, die „zutreffendste“ oder die letzte zutreffende "Rule" everwendet 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 |
|---|---|
Evaluation Strategy |
Es kann zwischen FirstMatch, BestMatch oder LeastMatch, also erster, bester oder letzter Übereinstimmung, entschieden werden. Die Voreinstellung ist „FirstMatch“. |
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. |
Conditions – Name |
optional, Bezeichnung der Bedingung eingeben |
Conditions – Value |
optional – sofern kein Name/ key definiert wurde, Wert aus dem Context, body, header oder selbstdefiniert |
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 – Into |
Folgeblock bestimmen, wenn notwendig |
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 RuleEngine-Block
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 (Pollgroup im OPC UA-Modul).
Nun werden die grundlegenden Elemente im Stream Processor angelegt bzw. konfiguriert (Grundeinstellungen im Stream Processor):
-
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
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 (Einstellungen in Message Template "default")
-
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 (Einstellungen in Message Template "Rule1").
Anschließend wird der Context des Block "UsingRules" konfiguriert, hier optional die Eingabe von Kontext mit Inhalten, und das default und ein weiteres RuleSet angelegt (befüllter Context, erstelltes DefaultRuleSet und RuleSet-1).
Es folgt die Konfiguration der RuleSets:
-
DefaultRuleSet (DefaultRuleSet ausgefüllt)
-
Evaluation Strategy eintragen: FirstMatch
-
Rules: Add Default → DefaultRule erstellt
-
Context und Into wurden leer gelassen
-
Im Obsolete Context werden die Elemente Kontext2 und Kontext3 entfernt
-
Message Template "default" angeben
-
-
Ruleset-1
-
Evaluation Strategy eintragen: FirstMatch
-
Ist das RuleSet-1 erstellt, müssen die Rules mit ihren Bedingungen konfiguriert werden.
-
Add Rule → Rules-1 erstellt
-
Conditions
-
Name: "dynUint >= 35000"
-
Value: es wird die Bedingung "body_dynUint >= 30000" eingetragen.
-
-
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
-
-
Add Rule → Rules-2 erstellt (Ruleset-2 Rules2 ausgefüllt)
-
Conditions
-
Name: dynUint kleiner gleich 10000 – dies ist nur eine Beschreibung der Bedingung.
-
Value: 'body_dynUint < = 10000' – dies ist die Bedingung
-
-
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 (Verbindung der konfigurierten Blöcke).
Mit dieser Konfiguration kann nun über den MQTT oder über andere Schnittstellen die fertige Nachricht ausgegeben werden.