Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les facteurs suivants doivent être pris en compte lors de l’implémentation du moteur de règle d’entreprise (BRE) dans une solution BizTalk Server :
Types de faits
Le moteur de règles prend moins de temps pour accéder aux faits .NET par rapport au temps nécessaire pour accéder aux faits XML et de base de données. Si vous avez le choix d'utiliser des faits .NET, XML ou de base de données dans une règle, vous devriez envisager d'utiliser des 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 petite (< 10 ou si), 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 s’il faut utiliser la liaison DataConnection ou La liaison TypedDataTable en fonction de la taille estimée du jeu de données.
Collecteurs de faits
Un récupérateur de faits implémente des méthodes standard qui sont généralement utilisées pour fournir au moteur de règles des faits à long terme et évoluant lentement avant l’exécution d’une politique. 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 soumet le fait initialement, puis actualise le fait en mémoire uniquement lorsque cela est nécessaire.
Priorité des règles
Le paramètre de priorité d’une règle peut être compris entre les deux côtés de 0, avec des nombres plus importants ayant une priorité plus élevée. Les actions sont exécutées dans l’ordre entre la priorité la plus élevée et la priorité la plus basse. Lorsque la stratégie implémente un comportement de chaînage avant en utilisant des appels Assert/Update, le chaînage peut être optimisé grâce au 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é supérieure à Rule1 signifie que Rule2 s’exécute uniquement après que Rule1 se déclenche et met à jour la valeur. À l’inverse, si Rule2 avait une priorité plus élevée, elle pourrait être déclenchée une fois, puis à nouveau après le déclenchement de Rule1 et mettre à jour le fait que Rule2 utilise une condition. Bien que cela puisse fournir un résultat correct, donner à Rule1 une priorité plus élevée dans ce scénario fournira de meilleures performances.
Appels de mise à jour
La fonction Update entraîne la réévaluation de toutes les règles à l’aide des 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 Rule1 ou Rule2 sont évaluées deux fois, une fois avant l’appel Update et une fois après l’appel Update.
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 que 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 Montant est supérieure à 5.
Utilisation des opérateurs OR logiques
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. Du point de vue des performances, vous pouvez mieux fractionner les conditions en règles atomiques qui ne contiennent pas d’opérateurs OR logiques.
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 deuxième 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 du 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, le 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 l’instance du moteur de règles associée 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 si celui-ci est disponible. De même, si le processus BizTalk demande des informations sur une stratégie à partir du service de mise à jour, le service de mise à jour recherche les informations de stratégie dans son cache s’il est disponible. 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 paramétrage pour le moteur de règles liés à ces caches : CacheEntries, CacheTimeout et PollingInterval. Vous pouvez spécifier 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 une valeur de 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 utilisiez 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 est 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 de 3600 secondes ou de 1 heure. Cela signifie que si l’entrée du cache n’est pas référencée dans un délai d’une 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 l’heure en secondes du service de mise à jour pour vérifier la base de données du moteur de règles pour les mises à jour. La valeur par défaut du paramètre PollingInterval est de 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 en une valeur plus élevée pour améliorer les performances.
SideEffects, propriété
Les classes ClassMemberBinding, DatabaseColumnBinding et XmlDocumentFieldBinding ont une propriété nommée SideEffects. Cette propriété détermine si la valeur du champ lié, membre ou colonne 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’un champ d’un document XML ou d’une colonne d’une table de base de données est accessible pour la deuxième fois ou une version ultérieure dans la stratégie, sa valeur est récupérée à partir du cache. Toutefois, lorsqu’un membre d’un objet .NET est accessible pour la deuxième fois ou une version ultérieure, la valeur est récupérée à partir de l’objet .NET, et non à partir du cache. La définition de la propriété SideEffects d’une classe .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 ne pouvez le faire que par programmation. L’outil Compositeur de règles d’entreprise n’expose pas la propriété SideEffects .
Instances et sélectivité
Les classes XmlDocumentBinding, ClassBinding et DatabaseBinding ont deux propriétés : Instances et Selectivity. La valeur des instances est le nombre attendu d’instances de la classe en 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ègle utilise ces valeurs pour optimiser l’évaluation de condition afin que les instances les plus rares possibles soient utilisées dans les évaluations de condition en premier, puis les instances restantes sont utilisées. Si vous connaissez déjà le nombre d’instances de l’objet, la définition de la propriété Instances sur cette valeur améliore les performances. De même, si vous avez connaissance préalable du pourcentage de ces objets qui passent les conditions, la définition de la propriété Selectivity sur cette valeur améliore les performances. Vous ne pouvez définir des valeurs que pour ces paramètres par programmation. L’outil Compositeur de règles d’entreprise ne les expose pas.