Business Data from Process Variable required in Process Report

...low however the data is same through out the lifetime of process). For example the below names were used in different process models allthough they are of same data type and holding same data,

pv!gblRequestDetails_cdt
pv!gblRequestInfo_cdt
pv!globalRequestInfo_cdt
pv!globalRequestDetails_cdt
pv!requestDetail_cdt
pv!requestDetails_cdt
pv!requestInfo_cdt
pv!request_cdt
pv!requests_cdt

We have enabled the 'Allow data from this sub-process to be included in reports on the parent process model' in all the sub processes.

We tried the following to bring up the process data in report column but failed,

1. if we use only index(pv!gblRequestDetails_cdt, "requestId", ""), we get the requestId only for certain tasks whose process model contains the variable with this particular name. For other tasks, the result is empty.

2. if we use a condition as given in attached screenshot to conver all possible variable names, the report is getting a time out message "The per-resource...

... time limit for generating this report has been exceeded. Please review the report performance details for guidance on tuning the report" which i guess is mainly due to high evaluation time taken for each task. This is for a single column. If we add a similar condition for all the required columns, the overhead of column value evaluation will even go high.

3. if we define new set of primitive variables only in parent process model and capture the required metrics in first step (so that atleast new instances has the report data), we are getting the data only for tasks in this particular process model. This issue is similar to #1 as the variable is not present in other process models.

Now we cannot rename variables in all the process to match the parent process model due to the required development and testing effort.

We got only one more options left to try

1. Modify all the sub processes to have a new parameter variable as of parent model say 'gblRequestDetails_...

... cdt'. Doing so will work at least for new instances when we use index(pv!gblRequestDetails_cdt, "requestId", "") for column

Appreciate if anyone could give some better idea or throw some pointers. Our priority is to achieve this with minimal changes in process models as they are heavily nested. In worst case the process data should be available in report at least for the new instances if not for all instances. Any possible work around in the process report too would be great.

@kumaraveln I believe doing something as follows while working on a similar use-case but for an in-flight modification. Not sure how far the following works but I would suggest giving it a try and let us know if it worked. I retrieved the PVs based on pm!version so assuming that it should be possible with pm!id as well.

In case if gblRequestDetails_cdt is of type single:

fn!property(
\tfn!displayvalue(
\ tpm!id,
\ t{
\ t/*Either you can use the integer type process model ids or process model type constants here*/
\ tcons!MY_PM1,
\ tcons!MY_PM2,
\ tcons!MY_PM3,
\ t..
\ t},
\ t{
\ tpv!identicalPVWIthDifferentNameInPM1,
\ tpv!identicalPVWIthDifferentNameInPM2,
\ tpv!identicalPVWIthDifferentNameInPM3,
\ t..
\ t},
\ tnull
\t),
\t"requestId",
\t""
)

In case if gblRequestDetails_cdt is of type multiple:

fn!property(
\tfn!choose(
\ tfn!wherecontains(
\ tpm!id,
\ t/*Either you can use the integer type process model ids or process model type constants here*/
\ t{
\ tcons!MY_PM1,
\ tcons!MY_PM2,
\ tcons!MY_PM3,
\ t..
\ t}
\ t),
\ t{
\ tpv!identicalPVWIthDifferentNameInPM1,
\ tpv!identicalPVWIthDifferentNameInPM2,
\ tpv!identicalPVWIthDifferentNameInPM3,
\ t..
\ t}
\t),
\t"requestId",
\tnull
)

Thanks sikhivahans. Looks like a good option to try. Will let you know the results. And gblRequestDetails_cdt is single.

No worries, sure. fn!displayvalue() should suffice then.

Hi sikhinvahans. I have tried this approach but the data is not coming in report. Here is what I have done,

1. Added a column for pm!id and executed the report.
2. Extracted unique process models ids. Got a total of 21.
3. Defined 21 constants of type Number(Integer) to hold these values.
3. Found corresponding process model names by id. Inspected each process model and identified the variable name used in it.
4. Built the rule as attached (last two process models does not even have any process variable of expected data type defined hence mapped null)


I tried both pasting this content directly in report column definition (not sure if there is any character limit here) / calling a rule from there and passing process varaiables as parameter. Both did not give any result. Also tried replacing fn!property with index function but no luck.

Even if the process variable is single, return type of displayvalue function is list. Does it make any difference for property function?
Good thing is report timeout issue did not happen at any point so tweaking the code a bit may get us close. Any suggestion ?

Below code returns "123" for the entire column. What does it mean ? Im sure "requestId_int" exist in the pv

= fn!property(
fn!displayvalue(
1,
{
1
},
{
pv!gblRequestDetails_cdt
},
null
),
"requestId_int",
"123"
)

@kumaraveln I will look into this today and will get back to you, apologies for the delay.

@kumaraveln This scenario worked for me. Few things I would like to check:
1. Did you check the 'Include data from sub-processes' option?
2. Are the variables available for reporting?

I have tried the two options mentioned by me earlier and they worked well and another one that worked is as follows:

fn!displayvalue(
\tpm!id,
\t{1,2,3},
\t{
\ tindex(pv!myPV1,"reqId",null),
\ tindex(pv!myPV2,"reqId",null),
\ tindex(pv!myPV3,"reqId",null)
\t},
\tnull
)