Ajouter des fonctions de contrôle dans des actions pour optimiser l’exécution de règles avec l’Éditeur de règles Microsoft (préversion)

S’applique à : Azure Logic Apps (Standard)

Ce guide décrit comment optimiser l’exécution de règles en ajoutant des fonctions de contrôle aux actions de vos règles avec l’Éditeur de règles Microsoft. Les fonctions de contrôle aident l’application ou l’ensemble de règles à contrôler les faits dans la mémoire de travail du moteur de règles. Cela inclut les fonctions Assert, Clear, Halt, Retract, RetractByType, Reassertet Update pour un objet .NET et les entités TypedXmlDocument que vous pouvez utiliser comme faits. L’existence de faits dans la mémoire de travail détermine les conditions évaluées par le moteur et les actions exécutées.

Prérequis

• Avoir téléchargé et installé l’Éditeur de règles Microsoft.

• Le fichier XML contenant l’ensemble de règles sur lequel travailler.

  Pour ajouter des faits, spécifiez leurs valeurs dans les documents XML vers lesquels vous pointez dans la fenêtre Explorateur d’ensemble de règles. Vous pouvez aussi utiliser un créateur de faits pour fournir un tableau contenant des objets .NET en tant que faits au moteur de règles. Pour plus d’informations, consultez Créer des créateurs et des extracteurs de faits.

Fonction Assert

Pour ajouter des instances d’objet à la mémoire de travail du moteur de règles, utilisez la fonction Assert dans l’Éditeur de règles Microsoft. Le moteur traite chaque instance d’objet 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 de conflits et action.

Le tableau suivant récapitule le comportement de la fonction Assert pour les entités déclarées et les types d’instances pris en charge, y compris le nombre d’instances résultantes créées dans le moteur pour chaque entité déclarée et le type appliqué à chaque instance pour l’identification.

Déclarer un objet .NET

Le moteur des règles prend en charge les types scalaires .NET de base en mode natif, ainsi que les objets pour les types de référence. Le traitement d’objets .NET déclarés est le type de traitement le plus simple.

Dans l’Éditeur de règles Microsoft, vous pouvez déclarer un objet .NET à partir d’une règle.

1. Dans l’Éditeur de règles Microsoft, importez le fichier XML contenant le magasin de règles sur lequel travailler.

2. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

3. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Assert en tant qu’action.

4. Dans la fenêtre Explorateur de faits, sélectionnez l’onglet Classes .NET.

5. Depuis l’onglet Classes .NET, faites glisser la méthode de constructeur pour l’objet à utiliser dans l’action Assert.

   L’Éditeur de règles Microsoft convertit la méthode de constructeur en un appel CreateObject dans la définition de règle.

   Remarque

   Même si le moteur de règles dispose d’une fonction CreateObject, celle-ci n’apparaît pas comme une fonction distincte dans l’Éditeur de règles Microsoft.

Chaque objet est déclaré dans la mémoire de travail en tant qu’instance d’objet distincte. En d’autres termes, chaque prédicat qui référence le type de l’objet (comme IF Object.Property = 1) analyse l’instance. L’instance est aussi 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.

Prenons l’exemple des règles suivantes :

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 A de valeur 1 voient leur propriété État mise à jour. Toutefois, dans la règle 2, si la condition donne vrai, toutes les instances A voient leur état mis à jour. En fait, s’il existe plusieurs instances B, les instances A sont mises à jour chaque fois que la condition donne vrai pour une instance B.

Déclarer une entité TypedXmlDocument

Dans l’Éditeur de règles Microsoft, vous pouvez déclarer une entité TypedXmlDocument à partir d’une règle.

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Assert en tant qu’action.

3. Dans la fenêtre Explorateur de faits, cliquez sur Schémas XML.

4. Depuis l’onglet Schémas XML, faites glisser le nœud à appliquer à l’argument dans l’action Assert.

Les documents XML sont essentiellement de type texte. Cependant, la valeur du champ peut être de tout type, en fonction du type spécifié lors de l’élaboration de la règle. Les champs sont des expressions XPath et peuvent renvoyer un ensemble de nœuds. Le premier élément de l’ensemble est donc utilisé comme valeur.

Quand une entité TypedXmlDocument est déclarée en tant que fait, le moteur de règles crée des instances TypedXmlDocument enfant basées sur les sélecteurs définis dans la règle. Les sélecteurs peuvent constituer un bon moyen d’isoler les nœuds d’un document XML. Les champs quant à eux peuvent servir à identifier des éléments spécifiques dans le sélecteur. Le moteur de règles regroupe tous les champs dans un sélecteur en tant qu’objet.

Les sélecteurs sont aussi des expressions XPath. Lorsque vous sélectionnez un nœud sous l’onglet Schémas XML dans l’Explorateur de faits, l’Éditeur de règles Microsoft renseigne automatiquement la propriété Sélecteur XPath pour tous les nœuds et la propriété Champ XPath pour tout nœud ne contenant pas de nœud enfant. 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 dans la mémoire de travail du moteur de règles ou en sont retirés.

Vous pouvez utiliser plusieurs sélecteurs dans le même document. Vous pouvez ainsi afficher différentes parties du document (par exemple, une section est la commande et une autre contient l’adresse d’expédition). Cependant, n’oubliez pas que les objets créés sont définis par la chaîne XPath qui les a créés. Si vous utilisez une autre expression XPath, le résultat est une entité TypedXmlDocument unique, même si l’expression est résolue sur le même nœud.

Prenons l’exemple 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), les objets suivants s’ajoutent à la mémoire de travail :

Objet 1

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

Objet 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 XPath font référence aux champs individuels. Ainsi, si vous utilisez le sélecteur /root/order/item, //order/item ou //item, les objets suivants s’ajoutent à la mémoire de travail du moteur de règles : deux éléments pour Joe et deux pour Jane :

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

Chaque objet peut accéder à trois champs : @name, @quantity et @cost. Comme l’objet est une référence dans le document d’origine, vous pouvez faire référence à des champs parent (par exemple ../@customer).

En arrière-plan, le moteur de règles peut convertir une valeur de champ de texte en l’un des types pris en charge via la fonction XmlConvert. Vous pouvez spécifier cette option en définissant le type dans l’Éditeur de règles Microsoft. Si la conversion est impossible, le moteur génère une exception. Vous ne pouvez extraire les types bool et double que sous la forme de leur type respectif, chaînes ou objets.

Fonction Clear

Pour réinitialiser la mémoire de travail et l’agenda d’une instance du moteur de règles, utilisez la fonction Clear dans l’Éditeur de règles Microsoft. Pour plus d’informations sur la mémoire de travail et l’agenda, consultez Optimisation du moteur de règles.

Réinitialiser la mémoire de travail et l’agenda du moteur de règles

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle dans laquelle effacer la mémoire de travail et l’agenda de moteur de règles.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Clear en tant qu’action.

   La fonction Clear n’utilise aucun argument.

Fonction Halt

Pour arrêter l’exécution actuelle avec le moteur de règles, utilisez la fonction Halt dans l’Éditeur de règles Microsoft.

Arrêter l’exécution de l’ensemble de règles

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle dans laquelle arrêter l’exécution de l’ensemble de règles.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Halt en tant qu’action.

La fonction Halt admet un seul argument booléen. Si vous spécifiez la valeur comme vraie, le moteur de règles efface également l’agenda contenant les règles candidates en attente.

La méthode Ruleset.Execute est un wrapper autour de la méthode RuleEngine.Execute qui utilise un code similaire à ce qui suit :

RuleEngine.Assert(facts);
RuleEngine.Execute();
RuleEngine.Retract(facts);

Si vous exécutez une méthode Ruleset.Execute pour exécuter un ensemble de règles, le moteur de règles rend le contrôle à la méthode Ruleset.Execute lorsque la fonction Halt s’exécute. La méthode Ruleset.Execute retire les faits et rend le contrôle à l’appelant. Dans ce cas, l’exécution interrompue de l’ensemble de règles ne peut pas reprendre.

Cependant, si vous utilisez directement la méthode RuleEngine.Execute pour exécuter l’ensemble de règles, vous pouvez reprendre l’exécution interrompue de l’ensemble de règles avec la règle en attente suivante, en appelant RuleEngine.Execute, à condition qu’aucun objet nécessaire n’ait été retiré entre les deux appels.

L’exemple de code suivant montre comment reprendre l’exécution interrompue de l’ensemble de règles :

// Assert facts into working memory of the rules engine instance.
RuleEngine.Assert(facts);

// Execute the ruleset.
RuleEngine.Execute();

// The ruleset invokes the Halt method when executing actions.
// Control returns here when the Halt function is called. 
// When engine halts, do the following tasks.

// Add your code here.

// Resume the halted rules engine execution.
RuleEngine.Execute();

// Retract or remove facts from working memory in the rules engine.
RuleEngine.Retract(facts);

Fonction Retract

Pour supprimer des objets d’un ensemble de règles et de la mémoire de travail du moteur de règles, utilisez la fonction Retract dans l’Éditeur de règles Microsoft.

Retirer un objet .NET

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Retract en tant qu’action.

3. Dans la fenêtre Explorateur de faits, sélectionnez l’onglet Classes .NET.

4. Depuis l’onglet Classes .NET, faites glisser la classe souhaitée (et non l’assembly ou la méthode) dans l’argument du paramètre Retract.

   Si vous faites glisser une méthode dans la fonction Retract, le moteur essaie de retirer l’objet renvoyé par cette méthode.

Le retrait d’un objet .NET a les répercussions suivantes :

• Les actions de l’agenda qui utilisent les objets sont supprimées de celui-ci.

  Remarque

  Les actions supérieures de l’agenda peuvent avoir été exécutées avant que vous ayez utilisé la fonction Retract.

• Les règles qui utilisent l’objet dans un prédicat voient leurs actions supprimées de l’agenda (si des actions figurent dans l’agenda).

• Le moteur n’évalue plus l’objet.

Retirer une ou plusieurs entités TypedXmlDocument

Vous pouvez retirer l’entité TypedXmlDocument d’origine déclarée dans le moteur de règles. Vous pouvez aussi retirer l’une des entités TypedXmlDocument enfant créées à partir de l’entité TypedXmlDocument parent.

Prenons l’exemple du code XML suivant :

<order>
    <orderline customer="Joe" linenumber="001">
        <product name="router" quantity="10" cost="550" />
    </orderline>
    <orderline customer="Jane" linenumber="002">
        <product name="switch" quantity="1" cost="300" />
    </orderline>
</order>

Vous pouvez soit retirer l’entité TypedXmlDocument associée à un objet Order, soit retirer l’une des entités TypedXmlDocument associées à l’objet Orderline ou les deux. Toutes les entités TypedXmlDocument sont associées à l’entité TypedXmlDocument de niveau supérieur qui a été déclarée à l’origine (et non à l’entité TypedXmlDocument qui apparaît au-dessus du nœud TypedXmlDocument supérieur dans la hiérarchie d’arborescence XML).

Par exemple, Product est une entité TypedXmlDocument sous l’objet Orderline et est associée à l’entité TypedXmlDocument pour Order (et non à l’entité TypedXmlDocument pour Orderline). Dans la plupart des cas, cette distinction n’a pas d’importance. Cependant, si vous retirez l’objet Order, les objets Orderline et Product le sont également. Si vous retirez l’objet Orderline, seul celui-ci est concerné : l’objet Product ne l’est pas.

Le moteur utilise et suit uniquement les instances d’objet (à savoir TypedXmlDocument) qu’il a créées lorsque l’entité TypedXmlDocument a été déclarée à l’origine. Si vous créez des nœuds supplémentaires (par exemple, les nœuds frère d’un nœud sélectionné dans l’ensemble de règles via un sélecteur), ces nœuds ne sont pas évalués dans des règles, sauf si les entités TypedXmlDocument ont été créées et déclarées pour eux. Si vous déclarez de nouvelles instances TypedXmlDocument inférieures, le moteur les évalue dans les règles. Cependant, l’entité TypedXmlDocument supérieure n’a pas connaissance de ces instances. Lorsque vous retirez l’entité TypedXmlDocument supérieure, les nouvelles entités TypedXmlDocument déclarées indépendamment ne le sont pas automatiquement. Si de nouveaux nœuds sont créés, vous devez donc exécuter les fonctions Retract et Reassert sur l’ensemble du XmlDocument. Cette étape est la plus simple et la plus directe.

La classe TypedXmlDocument fournit des méthodes utiles que vous pouvez appeler dans un membre .NET personnalisé dans le cadre d’une action. Ces méthodes incluent la possibilité d’obtenir le XmlNode associé au TypedXmlDocument ou au TypedXmlDocument parent.

Retirer l’entité TypedXmlDocument supérieure

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Retract en tant qu’action.

3. Dans la fenêtre Explorateur de faits, cliquez sur Schémas XML.

4. Depuis l’onglet Schémas XML, faites glisser le nœud supérieur du schéma dans l’argument de la fonction Retract.

   Ce nœud supérieur se termine par l’extension .xsd et représente le nœud racine du document (et non le nœud d’élément du document). Le nœud a un sélecteur / qui fait référence au TypedXmlDocument initial. Lorsque vous retirez le TypedXmlDocument parent, toutes les entités TypedXmlDocument enfant associées au TypedXmlDocument sont supprimées de la mémoire de travail. Cela comprend toutes les entités TypedXmlDocument créées en appelant la fonction Assert sur la base des sélecteurs utilisés dans l’ensemble de règles.

Retirer une entité TypedXmlDocument enfant

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Retract en tant qu’action.

3. Dans la fenêtre Explorateur de faits, cliquez sur Schémas XML.

4. Depuis l’onglet Schémas XML, faites glisser le nœud enfant dans l’argument de la fonction Retract.

Fonction RetractByType

Pour supprimer tous les objets d’un type donné de la mémoire de travail du moteur de règles, utilisez la fonction RetractByType dans l’Éditeur de règles Microsoft. Celle-ci diffère de la fonction Retract qui ne supprime que les éléments spécifiques d’un type donné.

Retirer tous les objets .NET d’un type donné

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée RetractByType en tant qu’action.

3. Dans la fenêtre Explorateur de faits, sélectionnez l’onglet Classes .NET.

4. Depuis l’onglet Classes .NET, faites glisser la classe sur l’argument de la fonction RetractByType.

Retirer toutes les entités TypedXmlDocument d’un type donné

La fonction RetractByType supprime toutes les entités TypedXmlDocument avec le même DocumentType.Selector.

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée RetractByType en tant qu’action.

3. Dans la fenêtre Explorateur de faits, cliquez sur Schémas XML.

4. Depuis l’onglet Schémas XML, faites glisser le nœud correspondant sur la fonction RetractByType.

Comme pour la fonction Retract, si vous exécutez la fonction RetractByType sur le nœud racine du document, toutes les entités TypedXmlDocument déclarées avec ce DocumentType sont retirées. De plus, toutes les entités TypedXmlDocument enfant (ou tous les nœuds XmlNode dans la hiérarchie d’arborescence) associées à ces entités TypedXmlDocument parent sont également retirées.

Fonction Reassert

Pour appeler la fonction Assert sur un objet qui existe déjà dans la mémoire de travail du moteur, utilisez la fonction Reassert dans l’Éditeur de règles Microsoft. Ce comportement revient à émettre une commande Retract pour l’objet, suivie d’une commande Assert.

Par exemple, si vous utilisez la fonction Reassert sur un objet .NET, le moteur de règles procède comme suit :

1. Il retire l’objet .NET de la mémoire de travail.

2. Il supprime toutes les actions de l’agenda pour les règles qui utilisent cet objet dans un prédicat ou une action.

3. Il redéclare l’objet .NET dans la mémoire de travail et l’évalue en tant qu’objet nouvellement déclaré.

4. Il réévalue toutes les règles qui utilisent l’objet dans un prédicat et ajoute les actions de ces règles à l’agenda en fonction des besoins.

5. Il rajoute les actions à l’agenda pour toutes les règles qui ont été évaluées comme vraies et qui n’utilisent l’objet que dans leurs actions.

Redéclarer un objet .NET

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Reassert en tant qu’action.

3. Dans la fenêtre Explorateur de faits, sélectionnez l’onglet Classes .NET.

4. Depuis l’onglet Classes .NET, faites glisser la classe sur l’argument de la fonction Reassert.

Redéclarer une entité TypedXmlDocument

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Reassert en tant qu’action.

3. Dans la fenêtre Explorateur de faits, cliquez sur Schémas XML.

4. Depuis l’onglet Schémas XML, faites glisser le nœud d’entité à appliquer à l’argument dans la fonction Reassert.

Si vous redéclarer une entité TypedXmlDocument supérieure, les entités TypedXmlDocument enfant (créées lorsque l’entité TypedXmlDocument supérieure a été déclarée pour la première fois) peuvent se comporter différemment, en fonction de l’état de chaque entité TypedXmlDocument enfant.

Par exemple, si une entité enfant (nouvelle ou existante) est « compromise » (au moins un champ de l’ensemble de règles a été modifié via une action), la fonction Assert ou Reassert s’exécute alors sur cet enfant. Tout enfant existant non compromis reste dans la mémoire de travail.

L’exemple suivant présente un scénario simplifié décrivant le comportement des nœuds enfant quand l’entité parent est redéclarée. Imaginons que vous disposez des entités TypedXmlDocument suivantes dans la mémoire de travail : Parent, Child1, Child2 et Child3.

• Parent est l’entité TypedXmlDocument supérieure.
• Chaque enfant contient un champ nommé ExampleField dont la valeur est définie sur 1. Par exemple, Child1.ExampleField = 1`.

Imaginons qu’une action de règle effectue les opérations suivantes sur les entités enfant :

• La valeur ExampleField pour Child2 est mise à jour de 1 à 0.
• Le code utilisateur supprime Child3.
• Le code utilisateur ajoute une nouvelle entité TypedXmlDocument enfant nommée NewChild à Parent.

L’exemple suivant montre la nouvelle représentation des objets dans la mémoire de travail :

Parent
Child1 // Where Child1.ExampleField = 1
Child2 // Where Child2.ExampleField = 0
NewChild

Imaginons maintenant que vous redéclarez l’entité Parent. Cela provoque les comportements suivants auprès des entités enfant :

• Child2 est redéclarée, car elle a été compromise à l’issue de la mise à jour de son champ.
• Child3 a été retiré de la mémoire de travail.
• NewChild a été déclaré dans la mémoire de travail.
• Child1 reste inchangé dans la mémoire de travail, car il n’a pas été mis à jour avant que Parent soit redéclaré.

Fonction Update

Pour redéclarer un objet dans le moteur de règles à des fins de réévaluation, et en fonction des nouvelles données et du nouvel état, utilisez la fonction Update dans l’Éditeur de règles Microsoft. L’objet peut avoir un type de classe .NET ou un type TypedXmlDocument. Vous pouvez utiliser la fonction Update pour améliorer les performances du moteur et empêcher les scénarios de boucle infinie.

Mettre à jour un objet .NET

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Update en tant qu’action.

3. Dans la fenêtre Explorateur de faits, sélectionnez l’onglet Classes .NET.

4. Depuis l’onglet Classes .NET, faites glisser la classe sur l’argument de la fonction Update.

En général, vous utilisez la fonction Assert pour placer un nouvel objet dans la mémoire de travail du moteur de règles et la fonction Update pour mettre à jour un objet déjà dans la mémoire de travail. Lorsque vous déclarez un nouvel objet en tant que fait, le moteur réévalue les conditions dans toutes les règles. Toutefois, lorsque vous mettez à jour un objet existant, le moteur réévalue uniquement les conditions utilisant le fait mis à jour et ajoute les actions à l’agenda si ces conditions sont évaluées comme vraies.

Par exemple, imaginons que vous ayez les règles suivantes et que les objets nommés ItemA et ItemB se trouvent déjà dans la mémoire de travail.

• La règle 1 évalue la propriété Id pour ItemA, définit la propriété Id pour ItemB, puis redéclare ItemB après la modification. Quand ItemB est redéclaré, le moteur traite ItemB comme un nouvel objet et réévalue toutes les règles qui utilisent ItemB dans les prédicats ou les actions. Ce comportement garantit que le moteur réévalue la règle 2 par rapport à la nouvelle valeur d’ItemB.Id, comme défini dans la règle 1.

  Règle 1

  IF ItemA.Id == 1
  THEN ItemB.Id = 2
  Assert(ItemB)
  

• La règle 2 peut échouer à la première évaluation, mais prendre la valeur vraie à la deuxième évaluation.

  Règle 2

  IF ItemB.Id == 2
  THEN ItemB.Value = 100
  

La possibilité de redéclarer les objets dans la mémoire de travail offre à l’utilisateur un contrôle explicite sur le comportement des scénarios de chaînage avant. Toutefois, cet exemple révèle un effet secondaire de la réévaluation, où la règle 1 est également réévaluée. Comme ItemA.Id n’a pas été modifié, la règle 1 est encore évaluée comme vraie et l’action Assert(ItemB) est à nouveau déclenchée. Par conséquent, la règle crée une situation de boucle infinie.

Empêcher les boucles infinies

Vous devez pouvoir redéclarer les objets sans créer de boucles infinies. Pour éviter de tels scénarios, vous pouvez utiliser la fonction Update. Comme la fonction Reassert, la fonction Update exécute les fonctions Retract et Assert sur les instances d’objets associées modifiées par les actions de règle, mais avec les principales différences suivantes :

• Sur l’agenda, les actions liées aux règles restent dans l’agenda lorsque le type d’instance n’est utilisé que dans les actions (et non dans les prédicats).

• Les règles qui utilisent le type d’instance uniquement dans les actions ne sont pas réévaluées.

Par conséquent, les règles qui utilisent les types d’instances uniquement dans les prédicats ou dans les prédicats et les actions sont réévaluées et leurs actions sont ajoutées à l’agenda en conséquence.

En modifiant l’exemple précédent pour utiliser la fonction Update, vous pouvez vous assurer que le moteur réévalue uniquement la règle 2, car la condition de la règle 2 utilise ItemB. Le moteur ne réévalue pas la règle 1, car ItemB n’est utilisé que dans les actions de la règle 1*, ce qui élimine le scénario de bouclage.

Règle 1

IF ItemA.Id == 1
THEN ItemB.Id = 2
Update(ItemB)

Règle 2

IF ItemB.Id == 2
THEN ItemB.Value = 100

Même en utilisant la fonction Update de cette façon, il est toujours possible de créer des scénarios de bouclage. Observez par exemple la règle suivante :

IF ItemA.Id == 1
THEN ItemA.Value = 20
Update(ItemA)

Le prédicat utilise ItemA. Ainsi, le moteur réévalue la règle lorsque Update est appelée sur ItemA. Si la valeur d’ItemA.Id n’est pas modifiée ailleurs, la règle 1 continue d’être évaluée comme vraie, ce qui provoque un nouvel appel d’Update sur ItemA.

En tant que concepteur de règles, vous devez éviter de créer de tels scénarios de bouclage. L’approche à adopter pour corriger ce problème dépend de la nature des règles.

L’exemple suivant montre un moyen simple de résoudre le problème dans l’exemple précédent en ajoutant une vérification sur ItemA.Value. Celle-ci empêche la règle de l’évaluer à nouveau comme vraie après avoir exécuté les actions de la règle pour la première fois.

IF ItemA.Id == 1 and ItemA.Value != 20
THEN ItemA.Value = 20
Update(ItemA)

Mettre à jour une entité TypedXmlDocument

1. Dans la fenêtre Explorateur d’ensemble de règles, recherchez et sélectionnez la règle souhaitée.

2. Dans le volet THEN (alors), sous Actions, ajoutez la fonction intégrée Update en tant qu’action.

3. Dans la fenêtre Explorateur de faits, cliquez sur Schémas XML.

4. Depuis l’onglet Schémas XML, faites glisser le nœud d’entité à appliquer à l’argument dans la fonction Update.

Prenons l’exemple des règles suivantes :

• La règle 1 évalue le nombre total d’éléments dans un message de bon de commande.

  IF 1 == 1
  THEN ProcessPO.Order:/Order/Items/TotalCount = (ProcessPO.Order:/Order/Items/TotalCount + ProcessPO:/Order/Items/Item/Count)  
  

• La règle 2 définit l’état sur « Besoin d’approbation » lorsque ce nombre total est supérieur ou égal à 10.

  Règle 2

  IF ProcessPO.Order:/Order/Items/TotalCount >= 10
  THEN ProcessPO.Order:/Order/Status = "Needs approval"
  

Si vous transmettez le message de bon de commande suivant comme entrée dans cet ensemble de règles, vous remarquez que l’état n’est pas défini sur « Besoin d’approbation », même si la valeur TotalCount est 14. Ce comportement se produit, car la règle 2 est évaluée uniquement au début, lorsque la valeur TotalCount est 0. La règle n’est pas évaluée chaque fois que TotalCount est mis à jour.

<ns0:Order xmlns:ns0="http://ProcessPO.Order">
    <Items>
        <Item>
            <Id>ITM1</Id>
            <Count>2</Count>
        </Item>
        <Item>
            <Id>ITM2</Id>
            <Count>5</Count>
        </Item>
        <Item>
            <Id>ITM3</Id>
            <Count>7</Count>
        </Item>
        <TotalCount>0</TotalCount>
    </Items>
    <Status>No approval needed</Status>
</ns0:Order>

Pour que le moteur réévalue les conditions à chaque mise à jour de TotalCount, vous devez appeler la fonction Update sur le nœud parent (Items) du nœud modifié (TotalCount). Si vous modifiez la règle 1 comme suit et que vous testez la règle une fois de plus, le champ Status est défini sur « Besoin d’approbation » :

Règle 1 (mise à jour)

IF 1 == 1
THEN ProcessPO.Order:/Order/Items/TotalCount = (ProcessPO.Order:/Order/Items/TotalCount + ProcessPO:/Order/Items/Item/Count) AND
Update(ProcessPO.Order:/Order/Items)

Contenu connexe

• Créer des règles avec l’Éditeur de règles Microsoft
• Ajouter des opérateurs arithmétiques et logiques aux règles
• Tester vos ensembles de règles
• Créer un projet de moteur de règles Azure Logic Apps