Drools 7.2: Construire un moteur de règles (mode moniteur et hautes performances)

Question

Je construis un moteur de règles qui se ferme après la correspondance de la première règle. L'ordre des règles est fait en utilisant Salience, lock-on-active (pour empêcher les correspondances) et le groupe d'activation de quitter dès que l'entrée correspond à la première règle.

L'entreprise a maintenant une nouvelle exigence pour un mode de surveillance où le moteur doit continuer à faire correspondre l'entrée à une règle qui n'est pas en mode moniteur.

Par exemple:

Object(attr1 = 1, attr2 = 2) 

monitor  Rule 1: if (attr1 = 1) 
non-monitor Rule 2: if(attr = 1 and attr2= 2) 
non-monitor Rule 3: .. 

Ici, il doit correspondre à la fois la règle 1 et la règle 2, mais MUST (pour plus performante) sortie dès que la règle 2 est adaptée car il est dans un mode non-moniteur . Les règles du mode moniteur sont simplement utilisées pour voir si elles sont évaluées et si nous déclenchons des événements sur le backend pour nos besoins professionnels. J'utilise actuellement PackageDescBuilder, RuleDescrBuilder, etc. pour charger dynamiquement nos règles à partir de la base de données. Un simple StatelessKieSession est utilisé pour évaluer et stocker les résultats dans le prédicat dans le cadre de l'ERS. Q: Comment les nouvelles règles peuvent-elles être construites et quels concepts dois-je explorer ici à cette fin?

Je fais référence à cette documentation ici: https://docs.jboss.org/drools/release/7.2.0.Final/drools-docs/html_single/#_rule_attributes

Merci!

Answer 1

Si un certain nombre de « surveiller » les règles doivent être tiré avant le tir de la règle doit arrêter après le premier « non-moniteur » règle, l'approche la plus simple serait d'appeler fireUntilHalt et appeler halt() sur la session après le premier « non "moniteur" a tiré.

Soit mettre un halt() à la fin de chaque règle "non-moniteur" ou utiliser un écouteur.

Answer 2

Si j'ai bien compris le problème, une autre solution pourrait être de séparer les règles du moniteur et des non-moniteurs dans 2 groupes d'ordres différents. Les règles surveillées n'auront aucun attribut activation-group, et les non surveillés partageront tous le même activation-group (comme vous avez aujourd'hui).

Ensuite, lors de l'exécution de vos règles, assurez-vous de définir le bon ordre agenda-group afin que les règles surveillées se déclenchent avant celles qui ne sont pas surveillées.

Dans cette approche, vous pouvez également utiliser les approches fireUntilHalt() et halt() mentionnées par Laue. Les problèmes que je vois avec cette approche sont:

• Si vous n'utilisez pas agenda-group, vous devez garantir que toutes vos règles surveillées ont une saillance plus élevé que ceux non surveillés.
• Vous devez ajouter une règle ayant la plus faible saillie possible à halt() pour les cas où vous ne correspondez pas à vos règles non surveillées.

Hope it helps,