Description of problem: I have a process definition with a single rule task. The rules gets the process variable "results" and adds strings. After the rules task is finished, I print the process variable in script task to see all the set strings (that is correct and they are printed well). Then, the process is completed and when I see the history log of the process variable "results", there is only initialization [] and none changes. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Start the attached process definition which uses the business rules drl file (also attached) 2. See output in server log: 14:01:26,638 INFO [stdout] (http-localhost/127.0.0.1:8080-11) Before RuleTask 14:01:26,641 INFO [stdout] (http-localhost/127.0.0.1:8080-11) firstRule 14:01:26,644 INFO [stdout] (http-localhost/127.0.0.1:8080-11) secondRule 14:01:26,646 INFO [stdout] (http-localhost/127.0.0.1:8080-11) After RuleTask 14:01:26,646 INFO [stdout] (http-localhost/127.0.0.1:8080-11) [firstRule, secondRule] // here is the content of "results" variable 14:01:26,653 INFO [stdout] (http-localhost/127.0.0.1:8080-11) thirdRule 3. Check the process variable history log in Process Variables view in Business central Actual results: Expected results: Additional info:
Created attachment 846065 [details] the process definition with a single rule task
Created attachment 846066 [details] RuleTask.drl
Ivo, the problem is that you are actually modifying the same variable and not really changing it. To be more specific you add items to the same instance of the list. Then when you set this variable on process instance, engine compares if the new value is different than the old one - using equals method. And since you have not changed the instance engine has now way to figure out that the object has changed since both and old value are actually the same object instance so they are equal to each other. You can modify following line in the rule: java.util.List results = (java.util.List) processInstance.getVariable("results"); to: java.util.List results = new java.util.ArrayList((java.util.List) processInstance.getVariable("results")); and with that the history will be properly updated. While we could remove the check if the new is equal to the old, I believe that in majority of cases that makes sense as we would end up in duplicated entires for variables in the history which would be worse in my opinion. Wdyt?
Hi Maciej, oh, of course :) I was thinking about it and I found a possible solution. I suppose you create a new variable instance log in setVariable method or anywhere when a user set the new variable. So, as you have the "equals" condition there, I would add one more "equals" comparison between toString() method of the object and the last variable instance log value. Will it work as I expect? After all we only save the returned value of toString method, so it would make sense to compare them. So, there would be 3 situations: 1) equals = true, toString().equals = true => do not add any history log 2) equals = false, toString().equals = any (true or false) => add new history log 3) equals = true, toString().equals = false => add new history log (currently this log is missing)
Ivo, that's unfortunately not the case. Let me explain how it works: - user sets variable on process instance that in turn will first check if the object given is different than the value currently stored in process instance variables - if it's difference then it first an event "variable changed" - that event is observed by the history log process event listener and saves the old and new value into data base so the problem is actually in the first step - we are comparing exactly the same object instance. Moreover, in your rule you don't even have to use setVariable to have the values available in process instance as you directly changing the living object instance that is already stored in process instance as variable. so using toString would give us exactly same results - the values are already in the list as rule added value to list that was part of the process instance (which is considered old value). Does that make sense?
Ivo, this seems to be working as expected: the variable is like a pointer to an object, and in this case you are not really changing the pointer (it keeps pointing to the exact same list), you are only changing the contents of the list that is pointed to. The engine is only capable of keeping track of when the pointer has changed (keeping track of the contents as well is practically very difficult). Could we close this off as not a bug?
Yes, I understand that we compare the same object but I thought it could be possible to compare toString() content with the last variable instance log content which would prevent this situation. Never mind, if you are satisfied with it, you can close this bug.
Ivo, the main issue here is that engine notifies about the variable change when it discovers it and the delegates what should be done to the listeners - jpa db listener that stores the information in the database. Although engine is completely isolated from the underlain implementation and cannot get previous entries from the backend store. A perfect example of it is when mms audit log listener is used - it's asynchronous operations and we cannot expect any reply back from it until transaction is completed because at that time mms message will be actually sent. Does that make the issue more visible why we cannot simply compare on previous entry for given variable?
Maciej, thank you for the explanation. I looked at the source codes ( https://github.com/droolsjbpm/jbpm/blob/master/jbpm-flow/src/main/java/org/jbpm/process/instance/context/variable/VariableScopeInstance.java#L56 https://github.com/droolsjbpm/jbpm/blob/master/jbpm-audit/src/main/java/org/jbpm/process/audit/JPAWorkingMemoryDbLogger.java#L123 https://github.com/droolsjbpm/jbpm/blob/master/jbpm-audit/src/main/java/org/jbpm/process/audit/event/DefaultAuditEventBuilderImpl.java#L116 ) and I understand it more than before. It is a pity, I hoped this would make setting variables for a user easier.