Affirmer

L’assertion est le processus d’ajout des instances d'objets dans la mémoire de travail du moteur de règles métier. Le moteur traite chaque instance selon les conditions et les actions établies pour le type de l’instance, en utilisant les phases de correspondance, résolution de conflit 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 en tant qu’instance distincte. Cela signifie que l’instance est analysée par chaque prédicat qui fait référence au type de l’objet (par exemple, IF Object.Property = 1). Il est également disponible pour les actions de règle qui référencent le type, dépendant 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 d’A dont la valeur est 1 auront leur propriété Status mise à jour. Toutefois, dans la règle 2, si la condition a la valeur true, toutes les instances d’A auront leur état 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 une instance B.

Pour déclarer 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ègle a une fonction CreateObject , mais qu’il n’est pas affiché comme une 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 que vous souhaitez créer à partir de l’affichage Classe .NET de l’Explorateur de faits vers le volet d’action. Le compositeur de règles d’entreprise traduit ensuite la méthode de constructeur en un appel CreateObject dans la définition de règle.

TypedXmlDocument

Lorsqu’un TypedXmlDocument est déclaré, le moteur de règles métiers 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 les deux expressions XPath. Vous pouvez considérer les sélecteurs comme un moyen d’isoler les nœuds d’un document XML et les champs comme identifiant des éléments spécifiques dans le sélecteur. Tous les champs à l’intérieur d’un sélecteur sont regroupés en tant qu’objet par le moteur. Lorsque vous sélectionnez un nœud sous l’onglet Schémas XML dans l’Explorateur de faits, le compositeur de règles d’entreprise remplit automatiquement la propriété du sélecteur XPath pour tous les nœuds et la propriété champ XPath pour tout nœud qui ne contient pas de nœuds enfants. Si nécessaire, vous pouvez aussi taper vos propres expressions XPath pour Sélecteur XPath et Champ XPath.

Si le sélecteur correspond à plusieurs parties du document XML, plusieurs objets de ce type sont déclarés ou retirés de la mémoire de travail du moteur de règles. Supposons que vous disposez du code 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 champs individuels sont référencés par XPaths.

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, @quantityet @cost. Étant donné 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. Cela vous permet d’afficher différentes parties du document (par exemple, si une section est la commande et qu’une autre section contient l’adresse d’expédition). Toutefois, gardez à l’esprit que les objets créés sont définis par la chaîne XPath qui les a créées. L’utilisation d’une autre expression XPath, même si elle se résout sur le même nœud, entraîne un TypedXmlDocument unique.

Le moteur de règle prend en charge les types scalaires .NET de base en mode natif, ainsi que les objets pour les types de référence. Les documents XML sont essentiellement du texte, mais en fonction du type spécifié lors de la génération de la règle, la valeur du champ peut être de n’importe quel type. En outre, étant donné que les champs sont des expressions XPath, ils peuvent retourner un ensemble de nœuds, auquel cas le premier élément de l'ensemble est utilisé comme valeur.

En arrière-plan, le moteur de règle peut convertir une valeur de champ de texte en un des types pris en charge par le biais de la fonction XmlConvert . Vous pouvez le spécifier en définissant le type dans le compositeur de règles d’entreprise. Une exception est levée si une conversion n’est pas possible. 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 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 à l’objet TypedDataRows individuel, et non par rapport à TypedDataTable.

Par exemple, supposons que vous ayez la règle suivante établie pour une table « Clients » :

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

Supposons que vous insérez le DataTable suivant contenant trois DataRows dans le moteur d'exécution (sous forme de 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 répond à la condition de règle et les deux secondes échouent. Les résultats s’affichent comme suit.

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

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 génère des règles générées par rapport aux types TypedDataRowretournés par opposition à dataConnection elle-même.

Supposons que la règle suivante soit créée et qu’une DataConnection soit déclarée qui contient une connexion SqlConnection à 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 , elle 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, une seule ligne TypedDataRow est créée et déclarée dans le moteur pour un traitement ultérieur.

Résumé des entités déclarées et des types d’instances

Le tableau suivant récapitule le comportement d’assertion pour les différents types, montrant le nombre d’instances résultantes créées dans le moteur pour chaque entité déclarée, ainsi que le type appliqué à chacune de ces instances pour les identifier.

Voir aussi

Fonctions de contrôle du moteur