Partager via

Considérations relatives aux performances lors de l'utilisation du moteur de règles

  • Article

Cette rubrique explique comment le moteur de règles s'exécute dans divers scénarios et avec différentes valeurs pour les paramètres de configuration/réglage.

Types de faits

Le moteur de règles met moins de temps pour accéder aux faits .NET que pour accéder à ceux de base de données et XML. Si vous avez le choix, utilisez les faits .NET pour obtenir de meilleures performances.

Liaison de connexion de données et de table de données

Lorsque la taille du jeu de données est faible (moins de 10 lignes environ), la liaison TypedDataTable fonctionne mieux que la liaison DataConnection . Lorsque le jeu de données est volumineux (supérieur ou égal à environ 10 lignes), la liaison DataConnection fonctionne mieux que la liaison TypedDataTable . Par conséquent, vous devez décider d’utiliser la liaison DataConnection ou la liaison TypedDataTable en fonction de la taille estimée du jeu de données.

Extracteurs de faits

Vous pouvez créer un extracteur de faits, c'est-à-dire un objet qui implémente des méthodes standard et les utilise généralement pour fournir des faits à long terme et variant peu au moteur de règles avant l'exécution de la stratégie. Le moteur met en cache ces faits et les utilise pendant plusieurs cycles d'exécution. Plutôt que d'envoyer un fait statique ou relativement statique chaque fois que vous appelez le moteur de règles, créez un extracteur de faits qui envoie le fait la première fois, puis le met à jour en mémoire uniquement lorsque cela s'avère nécessaire.

Priorité des règles

Le paramètre de priorité d’une règle peut être défini de part et d’autre de 0, les nombres plus grands ayant une priorité plus élevée. Les actions sont exécutées de la priorité la plus élevée à la priorité la plus faible. Lorsque la stratégie implémente le comportement de chaînage avant à l’aide d’appels Assert/Update , le chaînage peut être optimisé à l’aide du paramètre de priorité. Par exemple, supposons que Rule2 ait une dépendance sur une valeur définie par Rule1. L’attribution d’une priorité plus élevée à Rule1 signifie que La règle2 ne s’exécutera qu’après l’exécution et la mise à jour de la valeur rule1. À l’inverse, si la règle 2 reçoit une priorité plus élevée, elle peut se déclencher une fois, puis se réactiver après que la règle1 se déclenche et met à jour le fait que Rule2 utilise dans une condition. Cela peut ou ne pas générer des résultats corrects, mais il est évident que deux déclenchement ont un impact sur les performances par rapport à un seul.

Appels de mise à jour

La fonction Update met à jour un fait qui existe dans la mémoire de travail du moteur de règles et entraîne la réévaluation de toutes les règles qui utilisent le fait mis à jour dans des conditions. Les appels de fonction de mise à jour peuvent être coûteux, en particulier si de nombreuses règles doivent être réévaluées en raison de la mise à jour des faits. Dans certains cas, la réévaluation des règles peut être évitée. Prenons par exemple les règles suivantes :

Règle1 :

IF PurchaseOrder.Amount > 5   
THEN StatusObj.Flag = true; Update(StatusObj)

Règle2 :

IF PurchaseOrder.Amount <= 5   
THEN StatusObj.Flag = false; Update(StatusObj)

Toutes les règles restantes de la stratégie utilisent StatusObj.Flag dans leurs conditions. Par conséquent, lorsque Update est appelé sur l’objet StatusObj , toutes les règles sont réévaluées. Quelle que soit la valeur du champ Montant , toutes les règles à l’exception de Rule1 et Rule2 sont évaluées deux fois, une fois avant l’appel de mise à jour et une fois après l’appel de mise à jour .

Au lieu de cela, vous pouvez définir la valeur du champ d’indicateur sur false avant d’appeler la stratégie, puis utiliser uniquement Rule1 dans la stratégie pour définir l’indicateur. Dans ce cas, La mise à jour est appelée uniquement si la valeur du champ Montant est supérieure à 5, et Update n’est pas appelée si le montant est inférieur ou égal à 5. Par conséquent, toutes les règles à l’exception de Rule1 et Rule2 sont évaluées deux fois seulement si la valeur du champ Amount est supérieure à 5.

Utilisation des opérateurs OR logiques

Le moteur de règles est optimisé pour l’exécution d’opérateurs AND logiques et il reconstruit la règle qu’il a analysée dans une forme normale disjonctive afin que l’opérateur OR soit utilisé uniquement au niveau supérieur. L’utilisation d’un nombre croissant d’opérateurs OR logiques dans des conditions crée des permutations supplémentaires qui étendent le réseau d’analyse du moteur de règles, et la normalisation de la règle peut prendre beaucoup de temps. La liste suivante contient des solutions possibles à ce problème.

  • Modifiez la règle pour qu’elle soit dans une forme normale disjonctive afin que l’opérateur OR se trouve uniquement au niveau supérieur. Notez que le développement d'une règle en forme normale disjonctive dans l'Éditeur des règles d'entreprise peut être complexe. Vous pouvez envisager de créer la règle par programme.

  • Développez un composant d’assistance qui effectue les opérations OR et retourne une valeur booléenne, puis utilisez le composant dans la règle.

  • Envisagez de fractionner la règle et d'y rechercher un indicateur défini par une règle exécutée précédemment ou utilisez un objet qui est déclaré par une règle précédemment exécutée, comme illustré dans les exemples suivants :

    • Règle 1 : IF (a == 1 OR a == 3) THEN b = true

      Règle 2 : si (b == true) THEN ...

    • Règle 1 : IF (a == 1 OR a == 3) THEN assert(new c())

      Règle 2 : SI (c.flag == true) THEN ...

Paramètres de mise en cache

Le moteur de règles utilise deux caches. Le premier se trouve dans le service de mise à jour et le deuxième dans chaque processus BizTalk. Lors de la première utilisation d'une stratégie, le processus BizTalk demande les informations de stratégie auprès du service de mise à jour. Le service de mise à jour les extrait de la base de données du moteur de règles, les met en cache et les retourne au processus BizTalk. Le processus BizTalk crée un objet de stratégie en fonction de ces informations et le stocke dans un cache lorsque l'instance de moteur de règles associée termine l'exécution de la stratégie. Lorsque cette même stratégie est de nouveau appelée, le processus BizTalk réutilise l'objet de stratégie disponible dans le cache, le cas échéant.

De même, si le processus BizTalk demande des informations sur une stratégie auprès du service de mise à jour, ce dernier les recherche d'abord dans son cache. Le service de mise à jour procède également à des vérifications toutes les 60 secondes (1 minute) afin d'identifier les mises à jour éventuelles apportées à la stratégie dans la base de données. Si des mises à jour ont été effectuées, il extrait les informations et les met en cache.

Il existe trois paramètres de réglage pour le moteur de règles liés à ces caches : CacheEntries, CacheTimeout et PollingInterval. Vous pouvez définir les valeurs de ces paramètres dans le registre ou dans un fichier de configuration.

La valeur de CacheEntries est le nombre maximal d’entrées dans le cache. La valeur par défaut de CacheEntries est 32. Vous pouvez augmenter la valeur du paramètre CacheEntries pour améliorer les performances dans certains cas. Supposons par exemple que vous utilisez 40 stratégies de façon répétée. Dans ce cas, vous pouvez augmenter la valeur de CacheEntries à 40 pour améliorer les performances. Cela permettra au service de mise à jour de mettre en cache les informations de 40 stratégies maximum, et au service BizTalk de mettre en cache jusqu'à 40 instances de stratégie en mémoire. Le cache du service BizTalk peut comporter plusieurs instances d'une stratégie.

La valeur de CacheTimeout est la durée (en secondes) pendant laquelle les entrées sortent du cache du service de mise à jour. En d’autres termes, la valeur CacheTimeout fait référence à la durée pendant laquelle une entrée de cache d’une stratégie est conservée dans le cache s’il n’y a aucune référence. La valeur par défaut de CacheTimeout est 3600 secondes (une heure). Cela signifie que, si l'entrée en mémoire cache n'est pas référencée dans un délai d'une heure, elle est supprimée. Dans certains cas, vous pouvez augmenter la valeur CacheTimeout pour améliorer les performances. Supposons par exemple que la stratégie est appelée toutes les deux heures. Vous pouvez améliorer les performances de l’exécution de la stratégie en augmentant la valeur du paramètre CacheTimeout à une valeur supérieure à deux heures.

Le paramètre PollingInterval pour le moteur de règles définit la durée en secondes de l’intervalle auquel le service de mise à jour vérifie les mises à jour de la base de données du moteur de règles. La valeur par défaut du paramètre PollingInterval est 60 secondes (une minute). Si vous savez que les stratégies ne seront pas mises à jour ou le seront rarement, augmentez cette valeur afin d'améliorer les performances.

Propriété SideEffects

Les classes ClassMemberBinding, DatabaseColumnBinding et XmlDocumentFieldBinding ont une propriété nommée SideEffects. Cette propriété détermine si la valeur du membre, de la colonne ou du champ lié est mise en cache. La valeur par défaut de la propriété SideEffects dans les classes DatabaseColumnBinding et XmlDocumentFieldBinding est false. La valeur par défaut de la propriété SideEffects dans la classe ClassMemberBinding est true. Par conséquent, lorsqu'une colonne d'une table de base de données ou qu'un champ d'un document XML est accédé pour la deuxième fois ou ultérieurement dans la stratégie, sa valeur est extraite du cache. Toutefois, lorsqu'un membre d'un objet .NET est accédé pour la deuxième fois ou ultérieurement, la valeur est extraite de cet objet, et non pas du cache. La définition de la propriété SideEffects d’un .NET ClassMemberBinding sur false améliore les performances, car la valeur du champ est récupérée à partir du cache à partir de la deuxième fois. Vous pouvez uniquement le faire par programme. L’outil Compositeur de règles métiers n’expose pas la propriété SideEffects .

Propriétés Instances et Sélectivité

Les classes XmlDocumentBinding, ClassBinding et DatabaseBinding ont deux propriétés : Instances et Sélectivité. La valeur d’Instances est le nombre attendu d’instances de la classe dans la mémoire de travail. La valeur de Selectivity est le pourcentage des instances de classe qui réussissent à passer les conditions de règle. Le moteur de règles utilise ces valeurs pour optimiser l'évaluation des conditions afin que le moins d'instances possible soient utilisées dans les évaluations de conditions dans un premier temps, puis que les instances restantes soient utilisées. Si vous avez une connaissance préalable du nombre d’instances de l’objet, définir la propriété Instances sur cette valeur améliorerait les performances. De même, si vous avez une connaissance préalable du pourcentage de ces objets qui passent les conditions, la définition de la propriété Selectivity sur cette valeur améliorerait les performances. Vous pouvez uniquement définir les valeurs de ces paramètres par programme. L'outil Éditeur des règles d'entreprise ne les expose pas.