Assert

L’assertion est le processus d’ajout d’instances d’objet dans la mémoire de travail du moteur de règle d’entreprise. Le moteur traite chaque instance selon les conditions et actions écrites d'après le type de l'instance. Ce traitement se déroule en trois étapes : correspondance, résolution des conflits et action.

Les rubriques suivantes décrivent les comportements résultant de l’utilisation de la fonction Assert pour différents types de faits.

Objets .NET

Chaque objet est déclaré dans la mémoire de travail sous la forme d'une instance distincte. Cela signifie que l'instance est analysée par chaque prédicat référençant le type de l'objet (par exemple IF Object.Property = 1 ). Elle est également mise à la disposition des actions de règles qui font référence au type, en fonction des résultats des conditions de règle.

Considérez l'exemple suivant.

Règle 1

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

Règle 2

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

Dans la règle 1, seules les instances de A dont la valeur est 1 auront leur propriété Status mise à jour. Toutefois, dans la règle 2, si la condition prend la valeur true, toutes les instances de A auront leur status mis à jour. En fait, s’il existe plusieurs instances de B, les instances A sont mises à jour chaque fois que la condition prend la valeur true pour un instance B.

Pour affirmer un objet .NET à partir d’une règle, vous pouvez ajouter la fonction Assert intégrée en tant qu’action de règle. Notez que le moteur de règles a une fonction CreateObject , mais qu’elle n’est pas affichée en tant que fonction distincte dans le compositeur de règles d’entreprise. Son appel est généré en faisant glisser la méthode de constructeur de l'objet à créer du volet Classe .NET de l'Explorateur de faits vers le volet d'action. Le compositeur de règles d’entreprise traduit ensuite la méthode du constructeur en appel CreateObject dans la définition de règle.

TypedXmlDocument

Lorsqu’un TypedXmlDocument est déclaré, le moteur de règles d’entreprise crée des instances TypedXmlDocument enfants basées sur les sélecteurs définis dans la règle.

Les sélecteurs et les champs sont tous deux des expressions XPath. Les sélecteurs peuvent constituer un bon moyen d'isoler les nœuds d'un document XML ; les champs peuvent quant à eux servir à identifier des éléments spécifiques dans le sélecteur. Tous les champs à l'intérieur d'un sélecteur sont regroupés sous la forme d'un objet par le moteur. Lorsque vous sélectionnez un nœud sous l’onglet Schémas XML dans la Explorer Faits, le Compositeur de règles d’entreprise remplit automatiquement la propriété XPath Selector pour tous les nœuds, et la propriété XPath Field pour tout nœud qui ne contient pas de nœuds enfants. Vous pouvez également entrer vos propres expressions XPath pour XPath Selector et XPath Field si nécessaire.

Si le sélecteur correspond à plusieurs parties du document XML, plusieurs objets de ce type sont déclarés dans la mémoire de travail du moteur de règles ou en sont retirés. Supposons que vous disposiez du XML suivant.

<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>  

Si vous utilisez le sélecteur /root/order (ou //order), deux objets sont ajoutés à la mémoire de travail.

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>  

Dans chaque sélecteur, les différents champs sont désignés par des XPath.

Si vous utilisez le sélecteur /root/order/item (ou (//order/item ou //item), quatre objets sont ajoutés à la mémoire de travail du moteur de règles, les deux éléments pour Joe et les deux éléments pour Jane.

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

Chaque objet a accès à trois champs : @name, @quantity, et @cost. Parce que l'objet est une référence dans le document d'origine, vous pouvez faire référence à des champs parents (par exemple « ../@customer »).

Vous pouvez utiliser plusieurs sélecteurs dans le même document. Ceci vous permet d'afficher différentes parties du document (par exemple, si une section est la commande et qu'une autre contient l'adresse de livraison). N'oubliez pas cependant que les objets créés sont définis par la chaîne XPath qui les a créés. L’utilisation d’une autre expression XPath, même si elle est résolue en le même nœud, génère un TypedXmlDocument unique.

Le moteur des règles prend en charge les types scalaires .NET de base de façon native, ainsi que les objets pour les types de référence. Les documents XML sont essentiellement de type texte, mais la valeur du champ peut être de n'importe quel type en fonction du type spécifié lors de l'élaboration de la règle. Par ailleurs, dans la mesure où les champs sont des expressions XPath, ils peuvent renvoyer un ensemble de nœuds dans lequel le premier élément est utilisé comme valeur.

En arrière-plan, le moteur de règles peut convertir une valeur de champ de texte en un des types pris en charge via la fonction XmlConvert . Vous pouvez spécifier cela en définissant le type dans l'Éditeur des règles d'entreprise. Si une conversion est impossible, une exception est levée. Les types bool et double peuvent être récupérés uniquement en tant que type, chaînes ou objets respectifs.

TypedDataTable

Lorsqu’un TypedDataTable est déclaré, tous les DataRows contenus dans le DataTable sont automatiquement déclarés dans le moteur en tant que TypedDataRows. Chaque fois qu’une table ou une colonne de table est utilisée comme argument de règle, l’expression est évaluée par rapport à typedDataRows individuel, et non à typedDataTable.

Supposez par exemple que vous avez construit la règle suivante à partir d'une table Customers :

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

Supposons que vous affirmiez le DataTable suivant avec trois DataRows dans le moteur (sous la forme d’un TypedDataTable).

Le moteur insère trois TypedDataRows : 001, 002 et 003.

Chaque TypedDataRow est évalué indépendamment par rapport à la règle. Le premier TypedDataRow remplit la condition de règle et les deux deuxièmes échouent. Les résultats apparaissent comme suit.

DataSetName.DataTableName est considéré comme un identificateur unique. Par conséquent, si un deuxième TypedDataTable est déclaré avec le même nom DataSet et le même nom DataTable , il remplace le premier TypedDataTable. Tous les TypesdDataRowassociés au premier TypedDataTable sont retirés et le deuxième TypedDataTable est déclaré.

DataConnection

Comme avec un TypedDataTable, le fait de faire glisser une table ou une colonne en tant qu’argument de règle dans Le Compositeur de règles métiers entraîne la création de règles sur les types TypedDataRowretournés par opposition à DataConnection lui-même.

Supposons que la règle suivante soit créée et qu’un DataConnection soit déclaré qui contient une connexion SqlConnection vers Northwind.Customers :

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

Lorsque le moteur évalue la règle utilisée dans la section TypedDataTable , il génère dynamiquement une requête qui ressemble à ceci :

SELECT *  
FROM Northwind.Customers  
WHERE CustomerID = 1  

Étant donné qu’une seule ligne de la base de données répond à ce critère, un seul TypedDataRow est créé et déclaré dans le moteur pour un traitement ultérieur.

Résumé des entités déclarées et des types d'instance

Le tableau suivant récapitule le comportement de déclaration des différents types, en illustrant le nombre d'instances résultantes créées dans le moteur pour chaque entité déclarée, ainsi que le type qui est appliqué à chacune de ces instances pour les identifier.

Voir aussi

Fonctions de contrôle de moteur