[Drools] Changer de règles "en cours de route"

Bonjour,

j'expérimente un peu en ce moment Drools. Je ne suis pas très fier de ce que j'ai fait pour l'instant, mais le sujet m'intéresse.
J'ai écrit (en fait, modifié des règles existantes) pour réagir en fonction du déplacement d'un utilisateur, pour lui suggérer des endroits où se rendre.

Localement, ça fonctionne assez bien. Par localement, j'entends que l'utilisateur est déjà dans une "zone" où des points d'intérêt sont susceptibles de lui faire changer son trajet.

J'aurais aimé étendre le système, en ayant plusieurs zones. L'utilisateur aurait donc autant de jeu de règles que de zones traversées.
J'ai bien changé de kession en unmarshallant une ksession de la zone quand l'utilisateur s'en approche, mais il doit y avoir plus élégant.

J'imagine que je n'ai pas été très clair... :oops:
Si quelqu'un comprend quelque chose à mon charabia, j'apporterai des précisions avec plaisir.

Merci.

Citation:

---

Envoyé par tchakapoum

Si quelqu'un comprend quelque chose à mon charabia, j'apporterai des précisions avec plaisir.

Merci.

---

Comme d'autres l'ont dit avant moi, JE VOUS AI COMPRIS!

En fait, ton knowledge builder, son boulot, c'est de compiler les règles. Toutes les règles. Ta knowledge base, tu peux y mettre les packages que tu veux, depuis le knowledge builder. Son travail, c'est de déclencher des règles sur des faits.

Je ne sais pas si c'est pertinent pour ton problème, mais dans l'idée, tu peux créer une knowledge base par zone. En fonction de celle où tu es, tu utilises la bonne knowledge base.

Maintenant, pourquoi ne pas commencer ta règle par

Code:

---

1 2 3 4 5 6 7 8 9 10

rule "test zone" when User (zone == "nom de la zone de l'utilisateur") ... reste de la règle ... then action end

---

Salut,
Je ne suis pas sûr d'avoir saisi le détail de ce que tu veux faire, en particulier je me pose une question :
Est-ce que tu veux changer toutes les règles lors d'un changement de zone ou seulement un sous ensemble?
Car si c'est toutes les règles, pourquoi ne pas détruire le première ksession et en recréer une autre? (cf. réponse de rmaker).

Dans le cas ou des faits/évennèments d'une zone A impacteraitent ceux d'une zone B, cela ne marcherait pas, et il faudrait effectivement écrire un filtre dans tes règles (cf. réponse de rmaker).

Bref, il me semble qu'il est important de préciser dans quel cas tu te trouves. Faire des "Cas d'Usage" :), car cela impactera l'écriture des règles.

Merci pour vos réponses.
En fait, je ne souhaite pas changer toutes les règles au passage dans une zone, mais en ajouter, qui seront désactivées à la sortie de la zone.
En gros, je souhaiterais changer une partie des règles à chaque changement de zone.
Les événements ou faits d'une zone A n'impactent pas une zone B, mais peuvent impacter les règles plus générales.

Je n'ai pas fait de cas d'usages depuis le siècle dernier :mouarf: mais je vais essayer de transcrire ça dans un exemple ancré dans le réel.

On peut imaginer qu'un utilisateur aille de Lille à Paris à vélo avec un parcours libre, mais contenant des "checkpoints". Une espèce de "rallye" en somme.

Il est muni d'un dispositif (smartphone ou autre) qui collecte son positionnement, le guide vers le prochain checkpoint, sans oublier le but final qui est Paris.
Les règles globales l'aident à aller vers Paris et les différents checkpoints, tout en l'alertant sur la distance restant à parcourir, et en informant les responsables de son avancée.

A chaque entrée dans une zone, j'aimerais ajouter des règles qui permettront de lui suggérer d'aller voir un point d'intérêt, d'aller se restaurer, ou même d'aller "dépanner" un autre participant qui ne se déplace plus depuis un moment. Ces règles, ou au moins les faits, seraient spécifiques à chaque zone.

J'espère avoir été un peu plus clair. :oops:
Merci encore.

Citation:

---

Envoyé par tchakapoum

Merci pour vos réponses.
En fait, je ne souhaite pas changer toutes les règles au passage dans une zone, mais en ajouter, qui seront désactivées à la sortie de la zone.

---

Je réagis juste là dessus pour te dire d'être pragmatique. Le test sur la zone dans ta règle n'est pas cher à mettre en place et c'est la solution la plus simple. Ce sera drools et pas toi qui gèrera la sortie de zone. En le mettant en première condition, le RETE va commencer par ce noeud et donc, va être plus efficace.

Ensuite, quand tu connaitras mieux drools, tu auras une idée plus efficace... Mais en l'état, c'est dommage d'être ralenti pour çà. En tous cas, j'aime beaucoup ton projet :ccool:

Ok, je vois mieux ce que tu veux faire :)

En gros, j'imagine que tu as des régles génériques (qui s'exécutent indépendamment de la zone) et des règles spécifiques à chaque zone.

Je dirais que le plus simple c'est de faire comme rmaker te l'a suggéré : mettre des filtres dans tes règles.

Peut être te poses-tu le problème du passage à l'échelle (ou "scalabilité" pour les franglish) : si tu as 1000 zones, ça te ferait 1000 règles ou plus j'imagine. Là, je ne sais trop quoi te suggérer, car il me semble que Drools ne permet pas de décharger dynamiquement des règles. Ce qui est logique, vu les problèmes que ça pourrait poser pour garder la cohérence de l'automate du moteur de règles.

Cela dit, d'après ce que vend Drools, il me semble qu'avec 1000 règles, le moteur tient bien la charge. Donc tout dépend du nombre de zone que tu penses devoir gérer.

EDIT : grillé par rmaker, mais je plussoie :)

Merci à tous, je vais essayer d'avancer là dessus.:ccool:

Citation:

---

Envoyé par W.dev

il me semble que Drools ne permet pas de décharger dynamiquement des règles.

---

En fait, si. La méthode removeKnowledgePackage(String packageName) de KnowledgeBase. C'est tout l'intérêt de cette classe: ajouter ou supprimer dynamiquement des règles via les packages. Maintenant, évidemment, tu prends un méchant coup de bambou à la reconstruction de l'arbre de RETE...

Citation:

---

Envoyé par rmaker

En fait, si. La méthode removeKnowledgePackage(String packageName) de KnowledgeBase. C'est tout l'intérêt de cette classe: ajouter ou supprimer dynamiquement des règles via les packages. Maintenant, évidemment, tu prends un méchant coup de bambou à la reconstruction de l'arbre de RETE...

---

Pas mal comme fonctionnalité, je ne connaissais pas. A utiliser avec prudence j'imagine du coup (ou en sachant ce que l'on fait, si ça a un sens :)).

Merci pour le complément d'information.

Merci de votre aide, j'ai réussi à faire à peu près ce que je voulais. :ccool: