Data Block – Using Object Group Tree Hierarchy in Another Activity

How Can We Help?

Data Block – Using Object Group Tree Hierarchy in Another Activity

< Back

Issue

One of the object groups in the form has no rows which resulting in an error to approve.

Analysis

The data was checked and figured out that this is a Split Test request in the same process.

Activity 1 triggers Activity 2 and creates 2 tasks with same controls from Activity 2 only information is different. Process ID is the same.

Activity 2 first task triggers Activity 3 and creates one task.

Activity 2 second task triggers Activity 3 and created one task.

The user now opens the tasks. Below is the order that was followed.

Firstly, the user opens the Activity 2 First task and approves it which creates Activity 3 first task.

Now, the user opens the Activity 2 second task and approves it which creates Activity 3 second task.

In the third step, User opens the Activity 3 first task and tries to approve it and it throws an error object group has no values.

Now, the user tries to approve the Activity 3 second task and its successfully approves it.

The same issue can be replicated by creating a request.

This split request gets successfully approved only when

User approves Activity 2 first task and then activity 3 first task and then Activity 2 second task and then activity 3 Second task.

If any other order is followed, then Activity 3 First task doesn’t get approved.

Activity 3 second task irrespective of the order is approved.

The fcEventvalues for Activity 2 for both Activity 3 tasks have been checked. It has object group values populated for them in Activity 2 tasks.

A request has been submitted with the Support Team.

Resolution

When branching a process into two simultaneous branches that can function together they can only interact with their path back in the history when using Process.Curent of which the data block is one.

To illustrate

Path A.2 cannot access Path B.1 form fields as it’s in a different workflow branch, it can only access pathA.1 and up from there.

If the path to merge was Path A.2 (I.E. the last step to trigger the merge path) then the process.current and data block would reference Path A.2 and path A.1 etc. up the tree. It isn’t possible to get to Path B.1 or Path B.2 form data.

To get around this workflow pattern, if there is a possibility of a task being triggered multiple times and having to read data from other branches, etc., it should be saved into an intermediate table and then read from in the appropriate activities to ensure no fancy routing logic or fancy XML manipulation is required in the loading of the object group.

Comments are closed.

This is the legacy version of the XMPro Documentation site. For the latest XMPro documentation, please visit documentation.xmpro.com

X