Created attachment 809799 [details] process definition with the intermediate catch event Description of problem: I have an intermediate catch event containg: p: org.kie.api.runtime.process.WorkflowProcessInstance() personId: Integer() from p.getVariable("personId") org.jboss.qa.brms.domain.Person(id == personId, name == "John") when the name of person is changed to "John" and updated in session, nothing will happen and the process won't proceed further. The update is done the same way as it was in jbpm5, it means: FactHandle personHandle1 = ksession.insert(person1); // start process instance // update person1 ksession.update(personHandle1, person1); There was a similar issue (https://issues.jboss.org/browse/JBPM-3626) in jbpm5 that the name of workflow process instance couldn't be other than processInstance but it's NOT this case because I have tried it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Ivo, are you also inserting the process instance itself into the ksession after starting it?
yes, sure I add the process instance too. Here is the whole java code http://pastebin.com/78GUmkDi
I was too hurry, the issue is with the first process http://pastebin.com/YnGmLSKY
the behavior has changed in the way how rules are activated. In v6 drools uses lazy activation and thus fireAllRules must be invoked to trigger the evaluation. In comparison to v5 where activation happened on insert/update/retract. That means that whenever conditional events are used fireAllRules must be used to properly trigger rules after facts were inserted/update/retracted. So I believe this is not a bug but expected behavior which requires most likely documentation update that rule engine uses lazy activation and requires fireAllRules to be invoked.
Maciej, rules could also be defined as @eager (see for example https://github.com/droolsjbpm/jbpm/blob/master/jbpm-flow-builder/src/main/java/org/jbpm/compiler/ProcessBuilderImpl.java#L408) to avoid this. It seems most of the generated rules use this, although gateway constraints and start event constraints don't seem to have that annotation yet. So I believe adding that annotation there as well would make sense and solve this issue.
Kris, I am aware of this but unfortunately it does not mean the rule will be activated on insert/update/retract basis and thus fireAllRules is still mandatory to get that working. I double checked that with drools team and the @Eager places rules only on top of the processing queue. There are some discussion on how that might be supported on drools side but currently there is no way to activate the rule without fireAllRules.
Based on modifications applied on drools side now we can configure ksession to activate rules that are marked as @Eager on insert/update/retract basis. Configuration by default is done for RuntimeManager: config.setOption(ForceEagerActivationOption.YES); where config is KieSessionConfiguration jbpm master: https://github.com/droolsjbpm/jbpm/commit/b1c09c26c03d6e0523beb4abf40dbd8e7efa2250 https://github.com/droolsjbpm/jbpm/commit/f644b7565f7f28f7d68fc6ec11a28ae6863be58a 6.0.x https://github.com/droolsjbpm/jbpm/commit/0720077005125d8d141210197869864dbcbfe322 https://github.com/droolsjbpm/jbpm/commit/5c580eeca837758541124972d735c0b20d6b4fef
Verified in BPMS 6.0.0.ER5. Seems, ForceEagerActivationOption is set by default because I didn't have to change anything. I just removed the fireAllRules method for the test with rules condition.