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

Question

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

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

UPDATE:

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

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

Эксперт по слюнам - это определенно правильный путь.

Если вы хотите избежать повторения себя для более высоких узлов, то хитрость заключается в использовании insertLogical (или просто * 1006).* если вы находитесь в сеансе без сохранения состояния) и понять, что правила могут вызывать правила (это не 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

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

Answer 3

Вы можете попробовать механизм правил cum правил iLog.