Question

Retrieving over association in a subflow

0

I am running into some strange behavior when trying to retrieve an object over association in a subflow, that is also being used in the main flow. The situation is this: An object (object A) goes through the main flow, in that mainflow the object is changed and an object of the same entity is retrieved (object B), and the main flow is run again as a subflow using object B. In a subflow of the main flow with object B, object A is again retrieved, using an object of a different entity object A and B are both associated to. Some attributes of object A are however different from the object A that is being used in the first instance of the main flow, while having the same ID (it is neither the same as object A before as well as after the change event). The object did not get changed anywhere else in the microflow. I realize that this logic may not seem optimal, but to refacture this is a lot of work and would preferable be avoided. What I would like to know is why is this happening and is there anything I can do to fix it?

asked 2016-02-11

Robbert Hagendoorn

4 answers

Jeff Alexander · Answer 1 · 2016-02-11

Unless I misunderstand your question, you have have answered it yourself. :) Object A is changed in the first microflow, so naturally, the values would be different in the sub microflow? In the first microflow, you could make the changes to A and then don't commit or refresh. In the sub microflow, retrieve over database (old, saved changes) rather than association (most recent and unsaved changes) to get the data, and then commit at the end of the sub microflow.

Just a thought.

Charles Bronzwaer · Answer 2 · 2016-02-11

I presume the difference is caused by change actions that have not yet been committed to the database. In this case it is possible to have 2 objects with the same ID with different attribute values.

This occurs when you change an object without committing. When you then re retrieve the object (over database!) you get the same object but from the database and not from memory. If you want the object from memory (so with the changed attributes) you should use the retrieve over association action.

Ronald Catersels · Answer 3 · 2016-02-11

To debug this I would start with checking the attributes of A that have different value. Goto object A and search for microflows that changes that attribute. Because in my opinion the only reason that Object A differs is when something else has changed the object in the mean time.

You could also use an after commit action on the object with a breakpoint so you can check the data each time the object gets committed. When after these checks the object still has different values file a bug report. But my gut feeling is that somthing else is changing the object in between.

Regards,

Ronald

Robbert Hagendoorn · Answer 4 · 2016-02-12

I have found that the cause was by a webservice that I called in an earlier stage. After calling the webserivce I change the attributes of the object, and the microflow continues with the logic of the changed object. When retrieving the object over association though, I get the object that was sent with the webservice. This seems like strange behaviour to me but at least I was able to come up with a workaround.