Optimisation des performances du moteur des règles métier
Les facteurs suivants doivent être pris en compte lors de l’implémentation du moteur de règles métiers (BRE) dans une solution BizTalk Server :
Types de faits
Le moteur de règles prend moins de temps pour accéder aux faits .NET que le temps nécessaire pour accéder aux faits XML et de base de données. Si vous avez le choix d’utiliser .NET ou XML ou des faits de base de données dans une stratégie, vous devez envisager d’utiliser les faits .NET pour améliorer les performances.
Table de données et connexion de données
Lorsque la taille du jeu de données est faible (< environ 10), la liaison TypedDataTable offre de meilleures performances que la liaison DataConnection . Toutefois, la liaison DataConnection fonctionne mieux que la liaison TypedDataTable lorsque le jeu de données est volumineux (supérieur ou égal à 10 lignes environ). Par conséquent, vous devez décider d’utiliser la liaison DataConnection ou TypedDataTable en fonction de la taille estimée du jeu de données.
Récupérateurs de faits
Un récupérateur de faits implémente des méthodes standard qui sont généralement utilisées pour fournir des faits à long terme et changeant lentement au moteur de règles avant l’exécution d’une stratégie. Le moteur met en cache ces faits et les utilise pendant plusieurs cycles d'exécution. Au lieu d’envoyer un fait statique ou assez statique chaque fois que vous appelez le moteur de règles, vous devez créer un récupérateur de faits qui envoie le fait pour la première fois, puis met à jour le fait en mémoire uniquement si nécessaire.
Priorité de la règle
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 dans l’ordre de 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 a 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 que la règle1 a déclenché et mis à jour la valeur. À 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 le déclenchement de la règle1 et mettre à jour le fait que Rule2 utilise une condition. Bien que cela puisse fournir un résultat correct, le fait d’accorder à Rule1 une priorité plus élevée dans ce scénario offre de meilleures performances.
Mettre à jour les appels
La fonction Update entraîne la réévaluation de toutes les règles utilisant les faits mis à jour. Les appels de fonction de mise à jour peuvent être coûteux, en particulier si un grand ensemble de règles est réévalué lors de la mise à jour des faits. Il existe des situations où ce comportement peut être évité. Par exemple, tenez compte des 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 Règle1 ou Règle2 sont évaluées deux fois, une fois avant l’appel de mise à jour et une fois après l’appel de mise à jour .
Pour atténuer la surcharge associée, 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 Amount est supérieure à 5 et si la fonction Update n’est pas appelée si la valeur de Amount est inférieure ou égale à 5. Par conséquent, toutes les règles à l’exception de Rule1 ou Rule2 sont évaluées deux fois seulement si la valeur du champ Amount est supérieure à 5.
Utilisation d’opérateurs OR logiques
L'utilisation d'un nombre croissant d'opérateurs OR logiques dans les conditions crée des permutations supplémentaires qui étendent le réseau d'analyse du moteur de règles. D'un point de vue des performances, il est préférable de répartir les conditions dans des règles atomiques ne contenant pas d'opérateur OR logique.
Paramètres de mise en cache
Le moteur de règles utilise deux caches. Le premier est utilisé par le service de mise à jour et le second est utilisé par chaque processus BizTalk. La première fois qu’une stratégie est utilisée, le processus BizTalk demande les informations de stratégie au service de mise à jour. Le service de mise à jour récupère les informations de stratégie de la base de données du moteur de règles, les met en cache et retourne les informations au processus BizTalk. Le processus BizTalk crée un objet de stratégie basé sur ces informations et stocke l’objet de stratégie dans un cache lorsque le moteur de règles associé instance termine l’exécution de la stratégie. Lorsque la même stratégie est appelée à nouveau, le processus BizTalk réutilise l’objet de stratégie à partir du 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, le service de mise à jour recherche les informations de stratégie dans son cache si elles sont disponibles. Toutes les 60 secondes, le service de mise à jour vérifie également s’il y a eu des mises à jour de la stratégie dans la base de données. S’il existe des mises à jour, le service de mise à jour récupère les informations et met en cache les informations mises à jour.
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 du paramètre CacheEntries est le nombre maximal d’entrées dans le cache et est définie sur la valeur 32 par défaut. Vous pouvez augmenter la valeur du paramètre CacheEntries pour améliorer les performances dans certains scénarios. Par exemple, supposons que vous utilisez 40 stratégies à plusieurs reprises ; vous pouvez augmenter la valeur du paramètre CacheEntries à 40 pour améliorer les performances. Cela permettrait au service de mise à jour de conserver les détails du cache d’un maximum de 40 stratégies en mémoire.
La valeur de CacheTimeout correspond à la durée en secondes pendant laquelle une entrée est conservée dans le 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 pour une stratégie est conservée dans le cache sans être référencée. La valeur par défaut du paramètre CacheTimeout est 3600 secondes, soit 1 heure. Cela signifie que si l’entrée de cache n’est pas référencée dans l’heure, l’entrée est supprimée. Dans certains cas, il peut être utile d’augmenter la valeur du paramètre CacheTimeout pour améliorer les performances. Par exemple, si une stratégie est appelée toutes les deux heures, les performances de l’exécution de la stratégie sont améliorées en augmentant le paramètre CacheTimeout à une valeur supérieure à deux heures.
Le paramètre PollingInterval du moteur de règles définit la durée en secondes pendant laquelle le service de mise à jour case activée la base de données du moteur de règles pour les mises à jour. La valeur par défaut du paramètre PollingInterval est 60 secondes. Si vous savez que les stratégies ne sont pas mises à jour du tout ou sont rarement mises à jour, vous pouvez modifier ce paramètre pour une valeur plus élevée pour 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 .
Instances et sélectivité
Les classes XmlDocumentBinding, ClassBinding et DatabaseBinding ont deux propriétés : Instances et Sélectivité. La valeur de Instances correspond au 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.