How Can We Help?
Issue
I am using XMPro 5.1.0.
I have a process that splits off into two branches of the same process (ID).
When I try to reference or check a value on one branch of the tree from the other than I always retrieve a blank result.
The one branch of the process is basically no longer aware of activities that exist in the other.
I need this to check if the process can continue because the one branch relies on feedback from the other.
Any feedback or opinions on this one?
Resolution
When splitting processes into various trees they are only aware of their tree upwards, they cannot access their siblings to view or retrieve info.
I need this to check if the process can continue because the one branch relies on feedback from the other.
This can be done in the trigger of the activityA specific step in a process. It will be the user interface for that step (web form or a screen), for example, the Leave Application (screen interface or web form) will be the first Activity in the Leave Requisition process. The Leave Application Authorization will be the second step or Activity in the Leave Requisition process. One Process can have multiple activities. that you need to merge. The script to assist would be:
public object OBJECTNAME_OnSubmit()
{
if (process.CountPendingEvents("") == 1)
return "ACTIVITYNAME";
else
return String.Empty;
}
On the question of needing data from both trees, I would suggest using a custom table to save the two siblings data and then reading it out from the merged activity.
From v5.1.3 onwards the tracking will display the branches as part of the history, where prior to v5.1.3 these branches were “missing”.
The archive currently displays the entire process with all transactions for the various trees.
What it currently doesn’t do is nicely diagrammatically illustrate the various transaction trees, but instead displays everything as a per their date/time stamps.
Most definitely an area worth discussing, especially given the scenario as outlined, thanks for the feedback.
A correction is required here from v6 and v5.1.4 onwards is the tracking updated to indicate all the branches completed for the given transaction.
The activity count code snippet above will definitely help resolve one of the issues created by the split.
Although it will only tell you if there are any pending items not what is pending.
I also have resorted to using a custom table to store and make actions visible to other members of the split.
In this case again it seems like a bit of an unwieldy way of doing it.
One more worrying thing is the way the history, tracking and archive is displayed.
I have looked at the tracking and it appears to ‘lose’ the information on certain branches of the process.
This is obviously an issue for anyone trying to track parts of the process.
Could you elaborate on the intended behaviour of the tracking and archive in the case of a process split?
Also, is there a good business reason why branches of the process cannot share information?
I am not convinced that the current behaviour adds any real value to the process architects, users and owners.
My opinion is that the way it currently works is best, check the scenario below to see why.
If we have a typical process say;
(1) Request Approval,
(2) (3) (4) Give Approval and
(5) Complete Request.
Step 1 is request approval for something,
Steps 2, 3 and 4 are standard approvals required, in this case in parallel (hence a split process), say these approvals require an attachment and perhaps an amount to be approved.
If you have inherit values on and the first approval activity (step 2) is completed by the user attaching a document and entering an approved amount. When the next approver opens the approval activity (say step 3 or 4) then those values captured by the first approver (Step 2) will be inherited to the recently opened approval activity (Step 3 or 4), that shouldn’t happen.
So let’s say we decide to turn off inherit values.
Then the approval process even split will work as required, but when we get to the final activity and we want to reference the attachments and the values, which one of the three activities values will the activity.GetControlValue or GetHistoryValue method retrieve, remember it only retrieves one value the latest so you are stuck with the same issue of having to put the values of those fields into a custom table anyway.
I can definitely see that if a process splits into different activities it would be helpful to be able to reference “sibling trees” like we used to be able to do in v2 up to r21, remember those days but if the same process splits into identical trees, most of the time you wouldn’t want to reference a sibling tree as the current tree is distinct and detached from its other siblings, calculations and business rules based on control values become a nightmare as which control value will you receive and how do you get it?
Maybe there is cause for a new property on the process to distinguish between these two types of process, visible siblings or invisible siblings??
One more worrying thing is the way the history, tracking and archive is displayed.
I have looked at the tracking and it appears to ‘lose’ the information on certain branches of the process.
This is obviously an issue for anyone trying to track parts of the process.
Could you elaborate on the intended behaviour of the tracking and archive in the case of a process split?
From v5.1.3 onwards the tracking will display the branches as part of the history, where prior to v5.1.3 these branches were “missing”.
The archive currently displays the entire process with all transactions for the various trees.
What it currently doesn’t do is nicely diagrammatically illustrate the various transaction trees but instead displays everything as a per their date/time stamps.
Maybe there is cause for a new property on the process to distinguish between these two types of process, visible siblings or invisible siblings?
Most definitely an area worth discussing, especially given the scenario as outlined, thanks for the feedback!
Thank you for providing valuable feedback and giving another perspective on process splitting.
It has helped me understand the slight nuances that were not evident from my case.
I am planning on upgrading the site to v5.1.3 and that should resolve some of the immediate queries on the tracking and archive.
Step one is to provide visibility of the process and that sounds like it works.
I am sure you will find a clean way to graphically represent the branches in later versions J
I think in future we can definitely investigate ways to make the process more ‘aware’ of parallel activities.
One potential change right now is to keep the behaviour the same when the same activity splits into parallel, but when the process splits into different parallel activities to include them in the process XML.
What this could do is cater for the case of inheriting values and also cater for my case where the split happens for distinctly different activities.
Just thinking about parallel processes there are a number of difficulties that can arise and we definitely need to have a longer discussion on it.
From v5.1.3 onwards the tracking will display the branches as part of the history, where prior to v5.1.3 these branches were “missing”. The archive currently displays the entire process with all transactions for the various trees. What it currently doesn’t do is nicely diagrammatically illustrate the various transaction trees but instead displays everything as a per their date/time stamps.
Hope this finds you well, a quick comment on the above thread.
I have upgraded the client site to XMPro 5.1.3 and there are still claims that the process tracking is not showing the different branches of the process.
As you have noted above the archive does display the correct values but I was under the impression that the tracking will also work correctly.
Was the tracking tested prior to deployment? Please note that it is not the same activity being triggered multiple times, but three different activities being triggered together.
From v5.1.3 onwards the tracking will display the branches as part of the history, where prior to v5.1.3 these branches were “missing”.
The archive currently displays the entire process with all transactions for the various trees.
What it currently doesn’t do is nicely diagrammatically illustrate the various transaction trees but instead displays everything as a per their date/time stamps.
Most definitely an area worth discussing, especially given the scenario as outlined, thanks for the feedback.
A correction is required here from v6 and v5.1.4 onwards is the tracking updated to indicate all the branches completed for the given transaction.