Деревья принятия решений и механизмы правил (Drools)

Question

В приложении, над которым я сейчас работаю, мне нужно периодически проверять право на получение десятков тысяч объектов для какой-либо службы. Сама диаграмма принятия решений имеет следующий вид:

В каждом из конечных узлов (кругов) мне нужно запустить действие (изменить поле объекта, информацию журнала и т. Д.). Я попытался использовать Drool Expert framework, но в этом случае мне нужно написать длинное правило для каждого пути на диаграмме, ведущей к конечному узлу. Drools Flow, похоже, не создан для такого использования: я беру объект, а затем, в зависимости от решений на этом пути, я заканчиваю на одном из конечных узлов; а затем снова для другого объекта. Или это? Не могли бы вы привести несколько примеров/ссылок на такие решения?

UPDATE:

Drools потока вызовов может выглядеть следующим образом:

// 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); 
} 

То есть: я бы объект Application, начать новый процесс для него, когда процесс закончен (конечный, узел действия каким-то образом изменил бы приложение), я удалю объект из рабочей памяти и повторю процесс для нового объекта приложения. Что вы думаете об этом решении?

РЕШЕНИЕ:
Я закончил с использованием Drools Flow и она работает достаточно хорошо. Мой процесс решения не так прост, как Drools Expert запрашивает и в зависимости от того, где в дереве решений процесс должен загружать списки объектов из базы данных, преобразовывать их, принимать решения, записывать все и т. Д. Я использую объект Process который передается процессу в качестве параметра и хранит все мои глобальные переменные (для процесса) и некоторые методы удобства, которые повторяются в разных точках дерева (поскольку запись кода Java в узлах Script Task не очень удобна). Я также использовал Java для принятия решений (а не mvel или правил) - это быстрее, и я бы сказал, что легче контролировать. Все объекты, с которыми я работаю, передаются как параметры и используются в качестве обычных переменных Java в коде.

Answer 1

Эксперт Drools - это, безусловно, путь.

Если вы хотите, чтобы избежать повторений себя для более высоких вершин, то хитрость заключается в том, чтобы использовать insertLogical (или просто insert, если вы в сессионном) и понять, что правила могут привести правила (Это не SQL вашего отца запрос). Например:

// 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 

Если схема решения часто меняется (и вы хотите непрограммистам редактировать), посмотрите на документацию по таблиц решений (и DSL). В этом случае вы, вероятно, повторите весь путь для каждого правила, но в большинстве случаев это нормально.

Answer 2

Вы можете попробовать iLog framework cum rules engine.

Answer 3

У меня была знакомая проблема и использовалась база данных узлов Neo4J как простой и очень гибкий механизм правил. Вы можете использовать это с сервисным интерфейсом REST, поэтому он не зависит от основного приложения. У вас также может быть отдельное приложение для настройки правил (даже для конечных пользователей).