Hi Tom.
I had a quick look into the Drools code committed in the current jBPM codebase. Introducting the "ExecutionGlobals" may be a good idea, to be able to access anything in the process. But from an architectural point of view it couples the rules pretty tight to the process?
And globals actually shouldn't be used in Drools Rules too much if avoidable anyway. Maybe the performance downside of it doesn't count much in this environment, but having rules like in the example is a bit annoying:
rule "LessThen3IsIrrelevant"
when
eval(amount < 3)
then
outcome.set("irrelevant");
end
Instead this should be e.g., wthout the eval:
rule "LessThen3IsIrrelevant"
when
order.amount < 3
then
outcome.set("irrelevant");
end
So I think it should better be done like in jbpm 3: to configure which process variables should be inserted in the working memory. This could even be an addition to the ExecutionGlobals?
Additionaly, as I already mentioned in Berlin, I think using Drools DecisionHandler is not really the best practice, since again, you tie the rules to your specific process flow (e.g. you have to change both, if you get new transitions). Better is to have a RulesActivity, evaluating the rules and providing some result, and interpreting it afterwards in a "normal" jBPM decision.
What do you think?
Cheers
Bernd
