Behaupten

Assertion ist der Prozess des Hinzufügens von Objektinstanzen zum Arbeitsspeicher des Geschäftsregelmoduls. Die Engine verarbeitet jede Instanz gemäß den Bedingungen und Aktionen, die anhand des Typs der Instanz festgelegt sind, mithilfe der Vergleichs-, Konfliktlösungs- und Aktionsphasen.

In den folgenden Themen werden Verhaltensweisen beschrieben, die sich aus der Verwendung der Assert-Funktion für verschiedene Faktentypen ergeben.

.NET-Objekte

Jedes Objekt wird im Arbeitsspeicher als separate Instanz bestätigt. Dies bedeutet, dass die Instanz von jedem Prädikat analysiert wird, das auf den Objekttyp verweist (z. B. WENN Object.Property = 1). Sie wird auch für Regelaktionen verfügbar gemacht, die auf den Typ verweisen, abhängig von den Ergebnissen der Regelbedingungen.

Betrachten Sie das folgende Beispiel.

Regel 1

IF A.Value = 1  
THEN A.Status = "good"  

Regel 2

IF B.Value = 1  
THEN A.Status = "good"  

In Regel 1 wird die Status-Eigenschaft nur bei den Instanzen von A aktualisiert, die den Wert 1 haben. Wenn die Bedingung jedoch in Regel 2 als wahr ausgewertet wird, werden alle Instanzen von A ihren Status aktualisiert. Wenn es mehrere Instanzen von B gibt, werden die A-Instanzen jedes Mal aktualisiert, wenn die Bedingung für eine B-Instanz als wahr ausgewertet wird.

Um ein .NET-Objekt aus einer Regel zu bestätigen, können Sie die integrierte Assert-Funktion als Regelaktion hinzufügen. Beachten Sie, dass das Regelmodul über eine CreateObject-Funktion verfügt, aber nicht als separate Funktion im Business Rule Composer angezeigt wird. Der Aufruf wird durch Ziehen der Konstruktormethode des Objekts erstellt, das Sie aus der .NET-Klassenansicht des Fakten-Explorers in den Aktionsbereich erstellen möchten. Der Business Rule Composer übersetzt dann die Konstruktormethode in einen CreateObject-Aufruf in der Regeldefinition.

TypedXmlDocument

Wenn ein TypedXmlDocument-Objekt bestätigt wird, erstellt die Business Rule Engine untergeordnete TypedXmlDocument-Instanzen basierend auf den in der Regel definierten Selektoren.

Selektoren und Felder sind beide XPath-Ausdrücke. Sie können sich Selektoren als eine Möglichkeit vorstellen, Knoten eines XML-Dokuments zu isolieren, und Felder als spezifische Elemente innerhalb des Selektors zu identifizieren. Alle Felder innerhalb eines einzigen Selektors werden von der Engine als Objekt gruppiert. Wenn Sie im Fakten-Explorer unter der Registerkarte "XML-Schemas" einen Knoten auswählen, füllt der Business Rule Composer automatisch die XPath Selector-Eigenschaft für alle Knoten und die XPath Field-Eigenschaft für alle Knoten, die keine untergeordneten Knoten enthalten. Alternativ können Sie gegebenenfalls eigene XPath-Ausdrücke für XPath Selector und XPath Field eingeben.

Wenn der Selektor mit mehreren Teilen des XML-Dokuments übereinstimmt, werden mehrere Objekte dieses Typs in den Arbeitsspeicher der Regelmaschine eingefügt oder daraus entfernt. Gehen Sie davon aus, dass Sie über den folgenden XML-Code verfügen.

<root>  
   <order customer="Joe">  
      <item name="router" quantity="10" cost="550" />  
      <item name="switch" quantity="3" cost="300" />  
   </order>  
   <order customer="Jane">  
      <item name="switch" quantity="1" cost="300" />  
      <item name="cable" quantity="23" cost="9.99" />  
   </order>  
</root>  

Wenn Sie den Selektor /root/order (oder //order) verwenden, werden dem Arbeitsspeicher zwei Objekte hinzugefügt.

1)

<order customer="Joe">  
   <item name="router" quantity="10" cost="550" />  
   <item name="switch" quantity="3" cost="300" />  
</order>  

2)

<order customer="Jane">  
   <item name="switch" quantity="1" cost="300" />  
   <item name="cable" quantity="23" cost="9.99" />  
</order>  

Innerhalb der einzelnen Selektoren werden die einzelnen Felder von XPaths referenziert.

Wenn Sie den Selektor /root/order/item (oder (/order/item oder //item) verwenden, werden dem Arbeitsspeicher des Regelmoduls vier Objekte hinzugefügt, die beiden Elemente für Joe und die beiden Elemente für Jane.

<root>  
   <order customer="Joe">  
  
   </order>  
   <order customer="Jane">  
  
   </order>  
</root>  

Jedes Objekt hat Zugriff auf drei Felder – @name, @quantityund @cost. Da das Objekt ein Verweis auf das ursprüngliche Dokument ist, können Sie auf übergeordnete Felder verweisen (z. B. ".. /@customer").

Im selben Dokument können Sie mehrere Selektoren verwenden. Auf diese Weise können Sie verschiedene Teile des Dokuments anzeigen (z. B. wenn ein Abschnitt die Bestellung ist und ein anderer Abschnitt die Versandadresse enthält). Beachten Sie jedoch, dass die erstellten Objekte durch die XPath-Zeichenfolge definiert werden, die sie erstellt hat. Bei der Verwendung eines anderen XPath-Ausdrucks, selbst wenn er auf denselben Knoten verweist, entsteht ein einzigartiges TypedXmlDocument.

Das Regelmodul unterstützt systemeigene .NET-Skalartypen sowie Objekte für Referenztypen. XML-Dokumente sind im Wesentlichen Text, aber basierend auf dem Typ, der beim Erstellen der Regel angegeben wurde, kann der Feldwert beliebiger Art sein. Da die Felder XPath-Ausdrücke sind, können sie einen Knotensatz zurückgeben, in diesem Fall wird das erste Element im Satz als Wert verwendet.

Hinter den Kulissen kann das Regelmodul einen Textfeldwert in einen der unterstützten Typen über die XmlConvert-Funktion konvertieren. Sie können dies angeben, indem Sie den Typ im Geschäftsregel-Designer festlegen. Eine Ausnahme wird ausgelöst, wenn eine Konvertierung nicht möglich ist. Die Typen bool und double können nur als deren jeweiligen Typ, Zeichenfolgen oder Objekte abgerufen werden.

GetypteDatentabelle

Wenn eine TypedDataTable bestätigt wird, werden alle in der DataTable enthaltenen DataRows automatisch als TypedDataRows in die Engine bestätigt. Jedes Mal, wenn eine Tabelle oder Tabellenspalte als Regelargument verwendet wird, wird der Ausdruck für die einzelnen TypedDataRows und nicht für die TypedDataTable ausgewertet.

Angenommen, Sie haben die folgende Regel, die für die Tabelle "Kunden" erstellt wurde:

IF Northwind.Customers.CustomerID = 001  
THEN Northwind.Customers.ContactTitle = "Purchasing Manager"  

Angenommen, Sie übergeben die folgende DataTable mit drei DataRows an die Engine (als TypedDataTable).

Das Modul fügt drei TypedDataRows ein: 001, 002 und 003.

Jede TypedDataRow wird unabhängig von der Regel ausgewertet. Der erste TypedDataRow erfüllt die Regelbedingung, und die beiden anderen nicht. Die Ergebnisse werden wie folgt angezeigt.

Der DataSetName.DataTableName wird als eindeutiger Bezeichner betrachtet. Wenn also eine zweite TypedDataTable mit demselben DataSet - und DataTable-Namen bestätigt wird, wird die erste TypedDataTable ersetzt. Alle TypedDataRow-Elemente, die der ersten TypedDataTable zugeordnet sind, werden zurückgezogen, und die zweite TypedDataTable wird bestätigt.

DataConnection

Wie bei einer TypedDataTable führt das Ziehen einer Tabelle oder Spalte als Regelargument im Business Rule Composer zu Regeln, die mit den zurückgegebenen TypedDataRow-Objektenim Gegensatz zu dataConnection selbst erstellt wurden.

Angenommen, die folgende Regel wird erstellt und eine DataConnection festgelegt, die eine SqlConnection zu Northwind.Customers enthält.

IF Northwind.Customers.CustomerID = 001  
THEN Northwind.Customers.ContactTitle = "Purchasing Manager"  

Wenn das Modul die im TypedDataTable-Abschnitt verwendete Regel auswertet, erstellt es dynamisch eine Abfrage, die wie folgt aussieht:

SELECT *  
FROM Northwind.Customers  
WHERE CustomerID = 1  

Da nur eine Zeile in der Datenbank dieses Kriterium erfüllt, wird nur ein TypedDataRow erstellt und in die Engine zur weiteren Verarbeitung eingefügt.

Zusammenfassung der assertionierten Entitäten und Instanztypen

In der folgenden Tabelle wird das Assert-Verhalten für die verschiedenen Typen zusammengefasst, wobei die Anzahl der im Modul für jede bestätigten Entität erstellten Instanzen sowie der Typ angezeigt wird, der auf jede dieser Instanzen angewendet wird, um sie zu identifizieren.

Siehe auch

Motorsteuerungsfunktionen