Business Data from Process Variable required in Process Report

kumaraveln over 8 years ago

We have a process report in the context of a single process model. This process model has around 20 - 25 nested sub processes with human task(s) in it. Our requirement is to show a task report from where a group of users can view the status of various tasks (active, assigned and completed) and do reassignment if necessary.

Now we have no issue in showing the task related metrics like taskName, status, assignedTo, etc. But we also need few business process data (such as requestId, requestType, businessUnit) to be shown in the report (and option to use filters on them). All these process data are present in one particular CDT which flows across all the process models.

But here the issue is the name of process variable used in each sub process are different (since they were created by different people for various purpose and later integrated for this workf...

Discussion posts and replies are publicly visible

0 kumaraveln over 8 years ago

Yes sikhivahans. 'Include data from sub-processes' is enabled in all sub process setup and variables are available (not hidden) for reporting. Here the issue is for each task the report evaluates, its checking only in the context of the sub process where the task is present and does not care about the parent models and their variable. Since the variable itself is not present, even isnull(pv!myPvNotInThisProcess) returns false.

We spent a lot of time and tried all possible approach including the suggestion you gave. Nothing worked. Most of them does not return any result. As of now we have removed all columns related to business data and going only with the task metrics as our main purpose is task reassignment.

But parallely we have also modified all the process models to have a variable in the same name and made sure the data flows through them. Though this gives report data only for new instances, our understanding is our users may not hold on a task for more than a month max. So going forward we will get what we want and modify the report accordingly.

Its more of a lesson to keep reporting aspects in mind when modeling processes and strictly follow namings. But here nothing much could have been done as different people have designed workflows at different time and integrated at some point. Thanks for your time in this issue.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel