Alberi decisionali e motori delle regole (sbavature)
-
28-10-2019 - |
Domanda
Nell'applicazione su cui sto lavorando in questo momento, devo controllare periodicamente l'ammissibilità di decine di migliaia di oggetti per una sorta di servizio. Il diagramma decisionale stesso è nella seguente forma, proprio molto più grande:
In ciascuno dei nodi finali (cerchi), devo eseguire un'azione (modificare il campo di un oggetto, le informazioni di registro ecc.). Ho provato a usare il framework Expert Drool, ma in quel caso avrei dovuto scrivere una lunga regola per ogni percorso nel diagramma che porta a un nodo finale. Shrools Flow non sembra essere costruito nemmeno per un caso d'uso del genere - prendo un oggetto e poi, a seconda delle decisioni lungo la strada, finisco in uno dei nodi finali; e poi di nuovo per un altro oggetto. O è? Potresti darmi alcuni esempi/collegamenti a tali soluzioni?
AGGIORNARE:
Le chiamate a flusso di sbava potrebbero sembrare così:
// 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);
}
Cioè: prenderei un oggetto dell'applicazione, avviare un nuovo processo per esso, al termine del processo (il nodo Azione finale modificherebbe l'applicazione in qualche modo), rimuoverei l'oggetto dalla memoria di lavoro e ripeterei il processo per un nuovo oggetto app. Cosa ne pensi di questa soluzione?
SOLUZIONE:
Ho finito per usare Drools Flow e ha funzionato abbastanza bene. Il mio processo decisionale non è così semplice come lo Shrools Expert chiede e a seconda di dove nell'albero decisionale è necessario caricare elenchi di oggetti dal database, trasformarli, prendere decisioni, registrare tutto ecc. Uso un oggetto di processo Ciò viene passato al processo come parametro e memorizza tutte le mie variabili globali (per il processo) e alcuni metodi di convenienza che si ripetono in diversi punti dell'albero (come scrittura del codice Java nel Script Task
I nodi non sono molto convenienti). Ho anche finito per usare Java per prendere decisioni (e non mvel
o regole) - È più veloce e direi più facile da controllare. Tutti gli oggetti con cui lavoro sono passati come parametri e usati come normali variabili Java nel codice.
Soluzione
Drools Expert è sicuramente la strada da percorrere.
Se vuoi evitare di ripeterti per i nodi più alti, allora il trucco è usare insertLogical
(o semplicemente insert
Se sei in una sessione apolida) e per capire che le regole possono innescare regole (non è la query SQL di tuo padre). Per esempio:
// 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
Se il diagramma decisionale cambia frequentemente (e si desidera che i non programmatori lo modifichino), dai un'occhiata alla documentazione su tabelle decisionali (e DSL). In tal caso probabilmente ripeterai l'intero percorso per ogni regola, ma in realtà è OK nella maggior parte dei casi.
Altri suggerimenti
Ho avuto un problema simile e ho usato il database del nodo NEO4J come motore di regole semplice e molto flessibile. È possibile utilizzare è con un'interfaccia di servizio REST, quindi è indipendente dall'applicazione principale. Puoi anche avere un'applicazione separata per configurare le regole (anche dagli utenti finali).
È possibile provare il motore delle regole Cum Framework ILOG.