Bug 1017095 - A rule condition is not performed when a fact is updated
A rule condition is not performed when a fact is updated
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
high Severity high
: ER5
: 6.0.0
Assigned To: Maciej Swiderski
Ivo Bek
Depends On:
  Show dependency treegraph
Reported: 2013-10-09 05:13 EDT by Ivo Bek
Modified: 2014-08-06 16:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:13:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
process definition with the intermediate catch event (6.69 KB, application/xml)
2013-10-09 05:13 EDT, Ivo Bek
no flags Details

  None (edit)
Description Ivo Bek 2013-10-09 05:13:52 EDT
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:

Actual results:

Expected results:

Additional info:
Comment 1 Kris Verlaenen 2013-10-09 07:16:07 EDT
Ivo, are you also inserting the process instance itself into the ksession after starting it?
Comment 2 Ivo Bek 2013-10-09 07:49:12 EDT
yes, sure I add the process instance too. Here is the whole java code http://pastebin.com/78GUmkDi
Comment 3 Ivo Bek 2013-10-09 07:53:12 EDT
I was too hurry, the issue is with the first process http://pastebin.com/YnGmLSKY
Comment 4 Maciej Swiderski 2013-10-09 09:46:35 EDT
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.
Comment 5 Kris Verlaenen 2013-10-14 08:46:47 EDT
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.
Comment 6 Maciej Swiderski 2013-10-15 02:50:53 EDT
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.
Comment 7 Maciej Swiderski 2013-10-21 06:58:46 EDT
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:


where config is KieSessionConfiguration


Comment 8 Ivo Bek 2013-12-09 04:54:17 EST
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.

Note You need to log in before you can comment on or make changes to this bug.