Chained Rules sind ein fortgeschrittenes Szenario – komplizierte Anforderungen können hierüber gelöst werden. Hierzu muss man Befehle wie Assert/Update und Retract verstehen.

Vocabularies

Alle Beispiele benutzen folgendes Sample Schema:

Gemäß Best Practice wurden für die Beispiele Vocabularies benutzt, um Get/Set Accessors für die Schema-Elemente inklusive Aliases zu definieren.
Es wäre schön dasselbe öfters in der Praxis zu sehen …

Am Beispiel für Get Operation Field 1:

Assert/Retract Commands

Das erste Beispiel ist eine Kombination der Befehle Assert und Retract. In einem Dokument wird ein bestimmtes Element mit einem neuen Wert versehen, der Assert Befehl überführt das upgedatete Dokument in die Rule Engine Memory. Dies führt dann zur Evaluierung der zweiten Rule, welche dann in der Action zur Vermeidung einer endless loop das Dokument aus der Rule Engine Memory mit Retract entfernt.

Dies ist die Initial Rule. Falls Field1 den Wert „letschain“ enthält wird Feld2 mit dem Wert „chainit“ versehen, sodass die nachfolgende Rule mithilfe des Assert Command getriggert wird:

Anmerkung: In diesem und allen nachfolgenden Beispielen sollte in der Praxis mit der exists Expression gegen nicht vorhandene Elemente im bereitgestellten Xml Document getestet werden. Dies ist in diesem Artikel nicht erläutert.

Das Beispieldokument sieht so aus:

Und hier die ChainedRule:

Das Dokument, das in der InitialRule asserted wurde, muss wieder mit Retract aus der Rule Engine Memory entfernt werden – ansonsten implementiert man eine endless loop und bekommt eine out-of-memory bzw. execution loop exception:

Testen mit Rule Engine Composer

Beim Test im Rule Engine Composer kann man mittels Add Instance ein xml Dokument mitgeben.

Tipp: Auch .Net Objekte können für diese Tests verwendet werden durch Bereitstellung von FactCreators. Hierbei kann man zusätzlich custom code gesteuert durch die BRE ausführen.

Nach Testen der Policy sieht das Beispieldokument so aus:

Feld1 wurde durch die ChainedRule gesetzt und Feld 2 durch die InitialRule.

Policy Trace

Beim Entwickeln der Policy mit dem Rule Engine Composer lohnt sich ein Blick in den Rule Engine Trace nach dem Testen einer Policy. Hierbei kann man eventuelle Ungereimtheiten beim Ausführen der Policy studieren.

Tipp: Die Rule Engine Logik basiert auf dem Rete Algorithmus. Diesen muss man nicht unbedingt auswendig kennen aber ein Studium der Prinzipien lohnt sich.
https://de.wikipedia.org/wiki/Rete-Algorithmus

Tipp: Es ist möglich, Teile dieses Policy Traces nach Deployment einer Applikation in der BizTalk Admin Console einzusehen (z.B. welche Rules gefired wurden …). Hierzu muss die Policy in einer Orchestration aufgerufen werden und Tracking auf der Policy aktiviert sein. Der Message Flow enthält dann einen Link zur Policy Execution. Dies kann bei der Fehlersuche sehr hilfreich sein und bei Bedarf aktiviert werden (Host Instance Restart benötigt …).

Der folgende Screenshot zeigt den Policy Trace vom Business Rules Composer:

Die grün umrahmten Einträge beweisen, dass beide Rules gefired wurden (d.h. die Actions werden ausgeführt).

Die blau umrahmten Einträge zeigen Fact Assertions und Retracts.

Die Maximum Execution Loop Depth wurde für die Entwicklung (only) auf Minimal Wert gesetzt um das Testen zu beschleunigen und die eventuellen out-of-memory exceptions zu umgehen.

Update Command

Das Update Command re-asserted den angegebenen Fact (z.B. Xml Document) in die Rule Engine Memory. Dies führt zu einer Re-Evaluierung von Rules, welche dieses Fact benutzen.

In der InitialRule stellen wir sicher, dass die darauffolgende Rule getriggert, aber die jetzige Rule nicht mehr evaluiert wird.

Das Dokument haben wir für das Update Command nicht aus dem Vocabulary geholt, sondern ausnahmsweise über den Fact Explorer (XML Schemas) rübergezogen. Hierüber lassen sich auch einzelne Records auswählen (Root in dem Beispiel).

Voraussetzung für die Funktionsweise der beschriebenen Rule ist natürlich, dass wir den entsprechenden Input haben:

In der Chained Rule setzen wir dann einen neuen Wert für Feld 1. Die Chained Rule wird in diesem Fall nur ausgeführt wenn das Dokument mit dem Update Command in der Initial Rule zur Re-Evaluierung bereitgestellt wird:

Beide Rule Actions werden nun ausgeführt mit dem Resultat:

Senior Solution Architect QUIBIQ Schweiz AG