Losing value after split/join

Question

Hi,
In my process, there is a split/join activity. Before the split, there is an interactivity activity. User can set the BPMObject values.
Then, in the split/join, all interactive activities can change the BPMObject values. Before the join, the process works fine.
However, after join, the interactive activity only gets the original BPMObject values. All changes are lost.
Argument mapping of input ScreenFlow for the final interactive activity is: var1vpsfArg=var1
(var1 is the Instance variable)
How to get the updated value?
Sincerely,

Answer 1

Hi,
I don't think this was caused by your argument mapping. Whenever you're having trouble getting the new information out of a Join activity, the problem is usually the logic in the Join activity itself.
There are two ways you can treat a Split / Join pattern. If you right mouse click the Split -> Properties -> Advanced, you'll see a check box that allows you to either generate copies (the default) or not generate copies. This means that the transitions leaving the Split can either each have their own independent copy of the original instance variable or all the transitions leaving the split can share original instance variable.
I'd guess you're not seeing information flowing out of the Join because the Split is set to generate copies and you're not retrieving the copied information in the Join. If you're curious, here's what the engine does when it hits a Split activity that is set to generate copies:
1. Instance arrives in the Split activty
2. The engine automatically sends the original (copy 0) instance with all its variables to the Join activity
3. If there are two transitions leaving the Split, the engine automatically creates a copy of the instance for each of the transitions and sends them to the two activities that follow the Split via their respective transitions. If the two activities that followed the Split were "Check Credit" and "Check Inventory", you would now have the original instance in the Join (copy 0) and a copy (copy1) in the activity "Check Credit" and a copy (copy 2) in "Check Inventory".
4. As an end user completes the work in "Check Credit" the copy arrives in the Join activity and the logic in the Join executes
5. As an end user completes the work in "Check Inventory" the copy arrives in the Join activity and the logic in the Join executes
6. Now that all the copies have arrived and completed the Join, the engine automatically moves the original instance (copy 0) out the Join activity and downstream in the process.
Here's the logic you might want to add to your Join activity (the logic below assumes I named my activities "Check Credit" and "Check Inventory"). You'll notice that anywhere where you're refering to instance information that would have been set in either of the two activities between the Split and Join are referred to inside the Join's logic using the prefix "copy.". This "copy." is only used inside the Join activity and not in the Split (no logic needed here) or "Check Credit" or "Check Inventory".
<pre class="jive-pre"><font size= 2 color="navy">// this lets you know where this copy came from
logMessage "JOIN: previous activity was: " + copy.activity.source.name using severity = DEBUG
<br>
case copy.activity.source.name
when "CheckCredit" then
order.creditStatus = copy.order.creditStatus
when "CheckInventory" then
order.status = copy.order.status
// the "else" should not have been hit if you've done this correctly
else
order.status = "Problem"
end</font></pre>
After end users finish their work in the "Check Credit" activity this logic exectutes. The Join activity's logic uses the "copy.activity.source.name" variable to determine where the copy is coming from. Since in this example there are just two activities that immediately precede the Join, there are only two "when" clauses in the case statement. If there had been 4, then there would be 4 "when" clauses.
It's important to note the name of the activity in the logic above. Notice that the friendly labels are "Check Credit" and "Check Inventory"? Right mouse click each of your activities that immediately precede the Join -> click Properties and note the read only text in the "Activity id" field for each of these activities. In this example, even though the activity appears to be named "Check Credit" the name the logic will use will be "CheckCredit" without the space. The value in the activity's activity id field is what is passed into the Join logic's "copy.activity.source.name" variable.
What would happen if you didn't have the "case" in the logic above? You'd see the variable information in the last copy arriving into the Join overwrite the information written in previous copies. The last copy in would win.
In the second paragraph of this, I mentioned that you can choose to either generate copies (the default) or not generate copies (by unchecking the checkbox). I tend to leave it the default simply because it's the way I've always done it. You need to be careful because if you place a new activity just before your Join, the logic in the Join will need to change to accommodate the new activity in a new "when" clause. If you choose to not generate copies, then you don't need any of the logic shown above in the Join activity.
Hope this helps,
Dan