Optimisation pour l’exécution du moteur de règles Azure Logic Apps (aperçu)
S’applique à : Azure Logic Apps (Standard)
Important
Cette fonctionnalité est en préversion et est soumise aux conditions d’utilisation supplémentaires des préversions de Microsoft Azure.
Le moteur de règles Azure Logic Apps fournit le contexte d’exécution d’un ensemble de règles, que vous pouvez créer avec l’éditeur de règles Microsoft. Ce guide explique les concepts fondamentaux relatifs au fonctionnement du moteur de règles et fournit des suggestions d’optimisation pour les opérations et l’exécution.
Composants de base
Exécuteur d'ensemble de règles
Ce composant implémente l'algorithme responsable de l'évaluation des conditions de règle et de l'exécution des actions. L'exécuteur d'ensemble de règles par défaut est un moteur d'inférence de discrimination en réseau à chaînage avant qui est conçu pour optimiser les opérations en mémoire.
Convertisseur d'ensemble de règles
Ce composant utilise un objet RuleSet en entrée et produit une représentation exécutable de l'ensemble de règles. Le convertisseur en mémoire par défaut crée un réseau de discrimination compilé à partir de la définition de l'ensemble de règles.
Intercepteur de suivi de l'ensemble de règles
Ce composant reçoit le résultat de l'exécuteur de l'ensemble de règles et transmet ce résultat aux outils de suivi et de contrôle de l'ensemble de règles.
Évaluation de condition et exécution d’action
Le moteur de règles Azure Logic Apps est un moteur d’inférence très efficace qui peut lier des règles à des objets .NET ou des documents XML. Le moteur de règles utilise un algorithme en trois étapes pour l’exécution de l’ensemble de règles avec les étapes suivantes :
Correspondance
À cette étape, le moteur de règles fait correspondre les faits avec les prédicats qui utilisent le type de fait, qui sont des références d'objet conservées dans la mémoire de travail du moteur des règles, en se servant des prédicats définis dans les conditions de règle. Pour des raisons d'efficacité, la mise en correspondance avec un modèle est appliquée à toutes les règles de l’ensemble de règles. Les conditions partagées par ces règles ne sont mises en correspondance qu'une seule fois. Des correspondances de condition partielles peuvent être stockées dans la mémoire de travail par le moteur de règles pour accélérer les opérations ultérieures de mise en correspondance avec un modèle. Le résultat de la phase de mise en correspondance avec un modèle contient des mises à jour de l'agenda du moteur de règles.
Résolution de conflits
À l’étape de résolution des conflits, les règles qui peuvent être exécutées sont examinées par le moteur de règles pour déterminer le prochain ensemble d'actions de règle qui doit être exécuté sur la base d'un schéma de résolution prédéterminé. le moteur de recherche ajoute toutes les règles candidates trouvées lors de l'étape de mise en correspondance à l'agenda du moteur des règles.
Le schéma de résolution des conflits par défaut est basé sur des priorités de règle dans un ensemble de règles. La priorité est une propriété de règle que vous pouvez configurer dans l’éditeur de règles Microsoft. Plus le nombre est élevé, plus la priorité est haute. Si plusieurs règles sont déclenchées, le moteur de règles exécute d’abord les actions de priorité supérieure.
Action
À l’étape de l’action, les moteurs de règles exécutent les actions contenues dans la règle résolue. Des actions de règle peuvent déclarer de nouveaux faits dans les moteurs des règles, ce qui engendre la poursuite du cycle, également appelée chaînage avant.
Important
L’algorithme ne précède jamais la règle en cours d’exécution. Le moteur de règles exécute toutes les actions de la règle en cours d’exécution avant la répétition de la phase de correspondance. Toutefois, les autres règles de l'agenda du moteur de règles ne seront pas exécutées tant que la phase de correspondance n'aura pas recommencé. La phase de correspondance peut entraîner le moteur de règles à supprimer ces règles de l’agenda avant qu’elles ne s’exécutent.
Exemple
L'exemple suivant illustre comment l'algorithme en trois étapes de correspondance, de résolution des conflits et d’action fonctionne :
Règle 1 : évaluation des revenus
Représentation déclarative
Vérifiez si un client peut prétendre à un crédit que si son taux de solvabilité est inférieur à 0,2.
Représentation IF—THEN à l'aide d'objets métier
IF Application.Income / Property.Price < 0.2 THEN Assert new CreditRating( Application)
Règle 2 : évaluation du taux de solvabilité
Représentation déclarative
Approuvez un candidat que si ses conditions de crédit sont supérieures à 725.
Représentation IF—THEN à l'aide d'objets métier :
IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725 THEN SendApprovalLetter(Application)
Le tableau suivant récapitule les faits :
| Fact | Description | Fields |
|---|---|---|
| Application | Un document XML représentant une demande de prêt immobilier. | - Revenus : 65 000 $ - SSN : XXX-XX-XXXX |
| Propriété | Un document XML représentant la propriété à acheter. | - Prix : 225 000 $ |
| CreditRating | Un document XML contenant les conditions de crédit du candidat. | - Valeur : 0-800 - SSN : XXX-XX-XXXX |
Mises à jour de la mémoire de travail et de l’agenda
L'agenda et la mémoire de travail du moteur de règles sont initialement vides. Une fois que votre application a ajouté les faits Application et Property, le moteur de règles met à jour son agenda et sa mémoire de travail comme suit :
| Mémoire de travail | Agenda |
|---|---|
| - Application - Propriété |
Règle 1 |
Le moteur de règles ajoute la Règle 1 à son agenda car la condition Application.Income/Property.Price < 0,2 est considérée comme vraie au cours de la phase de correspondance.
Aucun fait CreditRating n'existe dans la mémoire de travail. La condition de Règle 2 n'est donc pas évaluée.
La règle 1 est la seule règle présente dans l'agenda, donc la règle exécute, puis disparaît de l'agenda.
La Règle 1 définit une action unique qui aboutit à un nouveau fait, qui est le document du CreditRating du candidat ajouté à la mémoire de travail.
Lorsque l'exécution de la Règle 1 est terminée, le contrôle revient à la phase de correspondance.
Le seul nouvel objet correspondant est le fait CreditRating, donc les résultats de la phase de correspondance sont les suivants :
Mémoire de travail Agenda - Application
- Propriété
- CreditRatingRègle 2 La Règle 2 s’exécute maintenant, ce qui appelle une fonction qui envoie une lettre d’approbation au candidat.
Après la fin de la Règle 2, le contrôle revient à la phase de correspondance. Toutefois, aucun nouveau fait n’est disponible pour correspondre, et l’agenda est vide, de sorte que le chaînage avant se termine et l’exécution de l’ensemble de règles est terminée.
Agenda et priorité
Pour comprendre comment le moteur de règles Azure Logic Apps évalue les règles et exécute des actions, vous devez comprendre les concepts d'agenda et de priorité.
Agenda
L’agenda du moteur de règles est une planification qui met en file d’attente les règles d’exécution. L'agenda est lié à une instance de moteur et agit sur un ensemble de règles, pas sur plusieurs. Lorsqu’un fait est déclaré en mémoire de travail et que les conditions d’une règle sont remplies, le moteur place la règle dans l’agenda et exécute cette règle en fonction de la priorité. Le moteur exécute les actions d’une règle de haut en bas, puis exécute les actions de la règle suivante dans l’agenda.
Le moteur de règles traite les actions d’une règle en tant que bloc, de sorte que toutes les actions s’exécutent avant que le moteur passe à la règle suivante. Toutes les actions d'un bloc de règle s'exécutent indépendamment les unes des autres. Pour plus d’informations sur l’assertion, consultez la section Optimiser votre moteur de règles avec des fonctions de contrôle .
L’exemple suivant montre comment l’agenda fonctionne :
Règle 1
IF
Fact1 == 1
THEN
Action1
Action2
Règle 2
IF
Fact1 > 0
THEN
Action3
Action4
Lorsque le fait Fact1, dont la valeur est 1, est déclaré dans le moteur, la Règle 1 et la Règle 2 ont leurs conditions remplies. Ainsi, le moteur déplace les deux règles vers l’agenda pour exécuter leurs actions.
| Mémoire de travail | Agenda |
|---|---|
| Fait 1 (valeur=1) | Règle 1 : - Action1 - Action2 Règle 2 : - Action3 - Action4 |
Priorité
Par défaut, toutes les règles ont une priorité d’exécution définie sur 0. Toutefois, vous pouvez modifier la priorité de chacune des règles. La priorité peut être positive ou négative. Les nombres les plus élevés correspondent aux priorités les plus importantes. Le moteur exécute les actions de la priorité la plus élevée à la priorité la plus faible.
L'exemple suivant montre l'incidence de la priorité sur l'ordre d'exécution des règles :
Règle 1 (priorité = 0)
IF
Fact1 == 1
THEN
Discount = 10%
Règle 2 (priorité = 10)
IF
Fact1 > 0
THEN
Discount = 15%
Bien que les conditions des deux règles soient remplies, la Règle 2 s’exécute en premier en raison de sa priorité plus élevée. La remise finale est de 10 % en raison du résultat de l'action exécutée pour Règle 1, comme l'illustre le tableau suivant :
| Mémoire de travail | Agenda |
|---|---|
| Fact1 (valeur = 1) | Règle 2 : Remise : 15 % Règle 1 : Remise : 10 % |
Effets secondaires d’une action
Si l'exécution d'une action affecte l'état d'un objet ou un terme d'une condition, cette action est considérée comme ayant un « effet secondaire » sur l'objet. Cela ne signifie pas que l’action a des effets secondaires, mais plutôt que l’objet ou le terme est potentiellement affecté par une ou plusieurs actions.
Prenons l'exemple des règles suivantes :
Règle 1
IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"
Règle 2
IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")
Dans cet exemple, OrderForm.UpdateStatus a un « effet secondaire » sur OrderForm.Status, ce qui veut dire que OrderForm.Status est potentiellement affecté par une ou plusieurs actions.
La propriété SideEffects des membres de la classe .NET est définie sur vraie par défaut, ce qui empêche le moteur de règles de mettre en cache un membre qui a des effets secondaires. Dans cet exemple, le moteur de règles ne met pas en cache OrderForm.Status dans la mémoire de travail. Au lieu de cela, le moteur obtient la valeur la plus récente de OrderForm.Status chaque fois que le moteur évalue la Règle 1. Si la valeur de propriété SideEffects est fausse, le moteur de règles met en cache la valeur lorsque le moteur évalue OrderForm.Status pour la première fois. Toutefois, pour les évaluations ultérieures dans les scénarios de chaînage avant, le moteur utilise la valeur mise en cache.
L’éditeur de règles Microsoft ne vous permet actuellement pas de modifier la valeur de propriété SideEffects . Toutefois, vous pouvez programmer la valeur de propriété SideEffects par le biais de l’infrastructure des règles d’entreprise, qui est une bibliothèque de classes compatible avec Microsoft .NET. La valeur est définie au moment de la liaison à l'aide de la classe ClassMemberBinding afin de spécifier les méthodes, les propriétés et les champs de l'objet utilisés dans des conditions et des actions de règles. La classe ClassMemberBinding a une propriété, nommée SideEffects, qui contient une valeur booléenne indiquant si l'accès au membre change sa valeur.
Considérations relatives aux performances
Cette section explique comment le moteur de règles Azure Logic Apps s'exécute dans divers scénarios et avec différentes valeurs pour les paramètres de configuration et de réglage.
Types de faits
Le moteur de règles met moins de temps pour accéder aux faits .NET que pour accéder aux faits XML. Si vous avez le choix entre utiliser des faits .NET ou des faits XML dans un ensemble de règles, envisagez d’utiliser des faits .NET pour améliorer les performances.
Priorité des règles
Le paramètre de priorité d'une règle peut être supérieur ou inférieur à 0, les nombres les plus élevés ayant une priorité plus élevée. Les actions s’exécutent de la priorité la plus élevée à la priorité la plus faible. Lorsque l’ensemble de règles implémente un comportement de chaînage avant à l'aide des appels Déclarer/Mettre à jour, le chaînage peut être optimisé en utilisant la propriété de priorité.
Supposons par exemple que la Règle 2 présente une dépendance sur une valeur définie par la Règle 1. Si la Règle 1 a une priorité plus élevée, la Règle 2 s’exécute uniquement après que la Règle 1 se déclenche et met à jour la valeur. Inversement, si la Règle 2 a une priorité plus élevée, elle se déclenchera une seule fois, puis à nouveau après que la Règle 1 se déclenche et met à jour le fait dans la condition pour la Règle 2. Ce scénario peut ou non générer des résultats corrects, mais il est évident que deux déclenchements ont un impact sur les performances contrairement à un seul.
Pour plus d’informations, consultez la section Créer des règles à l’aide de l’éditeur de règles Microsoft.
Opérateurs OR logiques
Le moteur de règles est optimisé pour exécuter les opérateurs logiques AND. Il reconstruit la règle que le moteur a analysée sous forme normale disjonctive de sorte que l'opérateur OR ne soit utilisé qu'au niveau supérieur.
Si vous utilisez des opérateurs OR logiques en conditions, l’augmentation crée davantage de permutations qui étendent le réseau d’analyse du moteur de règles. Par conséquent, le moteur de règles peut prendre beaucoup de temps à normaliser la règle.
La liste suivante fournit des solutions possibles à ce problème :
Modifiez la règle en forme normale disjonctive afin que l'opérateur OR soit uniquement présent au niveau supérieur.
Envisagez de créer la règle par programmation, car vous pouvez constater que la création d’une règle sous forme normale disjonctive dans l’éditeur de règles Microsoft peut être difficile.
Développez un composant d'assistance qui effectue les opérations OR et renvoie ensuite une valeur booléenne, puis utilisez-le dans la règle.
Fractionnez la règle et recherchez un indicateur défini par une règle exécutée précédemment ou utilisez un objet déclaré par une règle précédemment exécutée, par exemple :
Règle 1 :
IF (a == 1 OR a == 3) THEN b = trueRègle 2 :
IF (b == true) THEN …Règle 1 :
IF (a == 1 OR a == 3) THEN Assert(new c())Règle 2 :
IF (c.flag == true) THEN …
Appels de mise à jour
La fonction Mettre à jour met à jour un fait existant dans la mémoire de travail du moteur de règles, et entraîne la réévaluation de toutes les règles qui utilisent ce fait mis à jour dans leurs conditions. Ce comportement signifie que Mettre à jour des appels de fonction peut être coûteux, en particulier si de nombreuses règles nécessitent une réévaluation en raison de faits mis à jour. Dans certains cas, vous pouvez éviter de réévaluer des règles.
Prenons par exemple les règles suivantes :
Règle 1
IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)
Règle 2
IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)
Toutes les règles restantes de l’ensemble de règles utilisent StatusObj.Flag dans leurs conditions. Lorsque vous appelez la fonction Mettre à jour sur l’objet StatusObj, toutes les règles sont réévaluées. Quelle que soit la valeur du champ correspondant au Montant, toutes les règles exceptées les Règle 1 et Règle 2 sont évaluées deux fois, une fois avant l'appel Mettre à jour et une autre fois après l'appel Mettre à jour.
Au lieu de cela, vous pouvez définir la valeur de l’Indicateur sur fausse avant d’appeler l’ensemble de règles, puis utiliser uniquement la Règle 1 dans l’ensemble de règles pour définir l’indicateur. Dans ce cas, la fonction Mettre à jour est appelée uniquement si la valeur du Montant est supérieure à 5. La fonction Mettre à jour n’est pas appelée si la quantité est inférieure ou égale à 5. De cette façon, toutes les règles, sauf la Règle 1 et la Règle 2 sont évaluées deux fois seulement si la valeur du Montant est supérieure à 5.
Comportement de la propriété SideEffects
Dans les classes XmlDocumentFieldBinding et ClassMemberBinding, la propriété SideEffects détermine s’il faut mettre en cache la valeur du champ lié, du membre ou de la colonne.
Dans la classe XmlDocumentFieldBinding, la valeur par défaut de la propriété SideEffects est fausse. Cependant, la valeur par défaut de la propriété SideEffects dans la classe ClassMemberBinding est vraie.
Par conséquent, si le moteur accède à un champ dans un document XML pour la deuxième fois ou plus dans l’ensemble de règles, le moteur obtient la valeur du champ à partir du cache. Cependant, si le moteur accède à un membre d’un objet .NET pour la deuxième fois ou plus dans l’ensemble de règles, le moteur obtient la valeur de l’objet .NET, pas celle du cache.
Ce comportement signifie que si vous définissez la propriété SideEffects dans un ClassMemberBinding .NET sur fausse, vous pouvez améliorer les performances, car le moteur obtient la valeur du membre à partir du cache à partir de la deuxième fois et plus. Toutefois, vous ne pouvez définir par programme que la valeur de la propriété, car l’éditeur de règles Microsoft n’expose pas la propriété SideEffects .
Instances et sélectivité
Les classes XmlDocumentBinding et ClassBinding ont chacune les propriétés suivantes, dont les valeurs sont utilisées par le moteur de règles pour optimiser l’évaluation des conditions. Ces valeurs de propriété permettent au moteur d’utiliser les instances les plus rares possibles d’abord dans les évaluations de condition, puis d’utiliser les instances restantes.
Instances : nombre attendu d’instances de classe dans la mémoire de travail.
Si vous connaissez au préalable le nombre d’instances d’objet, vous pouvez définir la propriété Instances sur ce nombre pour améliorer les performances.
Sélectivité : pourcentage des instances de classe qui remplissent les conditions de règle.
Si vous connaissez le pourcentage d’instances d’objet qui remplissent les conditions au préalable, vous pouvez définir la propriété Sélectivité sur ce pourcentage pour améliorer les performances.
Vous ne pouvez définir ces valeurs de propriété que par programmation, car l’éditeur de règles Microsoft ne les expose pas.
Prise en charge de l’héritage des classes
L’héritage est la possibilité d’utiliser toutes les fonctionnalités d’une classe existante et d’étendre ces fonctionnalités sans réécrire la classe d’origine, ce qui est une fonctionnalité clé dans les langages de programmation orientée objet (OOP).
Le moteur de règles Azure Logic Apps prend en charge les types suivants d’héritage de classe :
L'héritage de l'implémentation : la capacité à utiliser les propriétés et les méthodes d'une classe de base sans codage supplémentaire.
L'héritage de l’interface : la possibilité d’utiliser uniquement des noms de propriétés et des noms de méthode, mais la classe enfant doit fournir l’implémentation.
Avec le moteur de règles, les règles peuvent être écrites dans une classe de base commune, mais les objets déclarés dans le moteur de règles peuvent provenir de classes dérivées.
L’exemple suivant contient une classe de base nommée Employee, tandis que les classes dérivées sont nommées RegularEmployee et ContractEmployee :
class Employee
{
public string Status()
{
// member definition
}
public string TimeInMonths()
{
// member definition
}
}
class ContractEmployee : Employee
{
// class definition
}
class RegularEmployee : Employee
{
// class definition
}
Dans cet exemple, supposons que vous ayez les règles suivantes :
Règle 1
IF Employee.TimeInMonths < 12
THEN Employee.Status = "New"
At run time, if you assert two objects, a **ContractEmployee** instance and a **RegularEmployee** instance, the engine evaluates both objects against the Rule 1.
You can also assert derived class objects in actions by using an **Assert** function. This function causes the engine to reevaluate rules that contain the derived object and the base type in their conditions as shown in the following example, which demonstrates implementation inheritance:
**Rule 2**
```text
IF Employee.Status = "Contract"
THEN Employee.Bonus = false
Assert(new ContractEmployee())
Après l’assertion, le moteur évalue de nouveau toutes les règles dont les conditions contiennent le type Employee ou le type ContractEmployee. Bien que seule la classe dérivée soit déclarée, la classe de base est également déclarée si les règles sont écrites à l'aide des méthodes dans la classe de base plutôt que celles de la classe dérivée.