Arbres de décision et moteurs de règles (bave)

Question

Dans l'application sur laquelle je travaille actuellement, je dois vérifier périodiquement l'admissibilité de dizaines de milliers d'objets pour une sorte de service. Le diagramme de décision lui-même est sous la forme suivante, bien plus grand:

Dans chacun des nœuds d'extrémité (cercles), je dois exécuter une action (modifier le champ d'un objet, les informations de journal, etc.). J'ai essayé d'utiliser Drool Expert Framework, mais dans ce cas, je devrais écrire une longue règle pour chaque chemin du diagramme menant à un nœud final. Le flux de bave ne semble pas non plus être construit pour un tel cas d'utilisation - je prends un objet, puis, selon les décisions en cours de route, je me retrouve dans l'un des nœuds d'extrémité; Et puis encore pour un autre objet. Ou est-ce? Pourriez-vous me donner quelques exemples / liens vers de telles solutions?

METTRE À JOUR:

Les appels de flux de bave peuvent ressembler à ceci:

// load up the knowledge base
KnowledgeBase kbase = readKnowledgeBase();
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
Map<String, Object> params = new HashMap<String, Object>();

for(int i = 0; i < 10000; i++) {

    Application app = somehowGetAppById(i);

    // insert app into working memory
    FactHandle appHandle = ksession.insert(app);

    // app variable for action nodes
    params.put("app", app);

    // start a new process instance
    ProcessInstance instance = ksession.startProcess("com.sample.ruleflow", params);
    while(true) {
        if(instance.getState() == instance.STATE_COMPLETED) {
            break;
        }
    }

  // remove object from working memory
    ksession.retract(appHandle);
}

C'est-à-dire: je prendrais un objet d'application, démarrer un nouveau processus pour cela, lorsque le processus sera terminé (le nœud d'action final modifierait l'application d'une manière ou d'une autre), je supprimerais l'objet de la mémoire de travail et répéterait le processus pour un nouvel objet d'application. Que pensez-vous de cette solution?

LA SOLUTION:
J'ai fini par utiliser du flux de billets et cela a fonctionné très bien. Mon processus de décision n'est pas aussi simple que Drools L'expert demande et en fonction de l'endroit où dans l'arbre de décision, le processus est qu'il doit charger des listes d'objets de la base de données, les transformer, prendre des décisions, tout enregistrer, etc. J'utilise un objet de processus Cela est transmis au processus en tant que paramètre et stocke toutes mes variables globales (pour le processus) et certaines méthodes de commodité qui sont répétées à différents points de l'arborescence (comme écrivant du code Java dans le Script Task Les nœuds ne sont pas très pratiques eux-mêmes). J'ai également fini par utiliser Java pour prendre des décisions (et non mvel ou des règles) - C'est plus rapide et je dirais plus facile à contrôler. Tous les objets avec lesquels je travaille sont passés comme paramètres et utilisés comme variables Java normales dans le code.

Answer 1

Expert en bave est définitivement la voie à suivre.

Si vous voulez éviter de vous répéter pour les nœuds supérieurs, alors l'astuce consiste à utiliser insertLogical (ou juste insert Si vous êtes dans une session sans état) et que pour comprendre que les règles peuvent déclencher des règles (ce n'est pas la requête SQL de votre père). Par exemple:

// we just insert Customer objects in the WM

rule "evaluateRetired"
when
    $c : Customer(age > 65)
then
    insertLogical(new Retiree($c));
end

rule "evaluteRetireeIsFemale"
when
    $r : Retiree(customer.gender == Gender.FEMALE, $c : customer)
then
    ...
end

Si le diagramme de décision change fréquemment (et que vous voulez que les non-programmeurs le modifient), jetez un œil à la documentation sur tables de décision (et DSL). Dans ce cas, vous répétez probablement tout le chemin pour chaque règle, mais c'est en fait OK dans la plupart des cas.

Answer 2

J'ai eu un problème similaire et utilisé la base de données de nœuds Neo4J comme moteur de règles simples et très flexibles. Vous pouvez l'utiliser avec une interface de service de repos afin qu'elle soit indépendante de l'application principale. Vous pouvez également avoir une application distincte pour configurer les règles (même par les utilisateurs finaux).

Answer 3

Vous pouvez essayer le moteur des règles du framework ilog.