194424 - no subject - I am creating a Tempo Report for listing

We've accomplished similar use cases by either granting view access to the model and handling quick tasks / related actions permissions accordingly (blocking said group), or creating a process that runs periodically loading task data into CDT, writes to the data store, then is visible in a Tempo/SAIL report via query rule. At this time you can also put a little note on the form that the data is updated periodically (can show last updated datetime), while also giving them a 'Refresh' button that utilizes the start process writer to refresh the data, calling & chaining through the same update process (so data is automatically refreshed on the form once chaining completes).

@miteshp Here goes an approach how you can actually display the data and refresh it on need basis.

Step - 1:
Create a process model that queries the analytics and stores the resultant data in the PV of type CDT as desired by you. Run this process model atleast once and keep one instance active all the time. Further add a message event in this process model and upon triggering this event, make sure that the analytics data in the process is refreshed. That is, when the message is sent to the process, query to the analytics should be made again which reloads the PV with fresh values.


Step - 2:
Create another process model which will take process id as input and refreshes the PV of the corresponding process (associated with process id) .

Step - 3:
And finally in the SAIL interface, display the data from the process created in Step - 1. That is, run a!queryProcessAnalytics on the processes per process model created in Step - 1. (Just in case, you can always limit the result to 1 and sort by descending order if you think that there is a possibility of more than once process instance.)

Step - 4:
If you want to refresh the data held in the PV in the process created in Step - 1, invoke the process model created in Step - 2 with the help of fn!startprocesswrite(). The input to this process should be the process id from which we query analytics data, that is process id of process model created in Step - 1. You can do this with help of a SAIL component that has 'saveInto' attribute. Let's say you have a button component namely 'Refresh' and upon clicking this you can actually invoke the process created in Step - 2. Refresh the query anayltics data (as mentioned in Step - 3) in the SAIL interface after the completion of invoking the process. This is equivalent to a conditional refresh strategy.

Example:
fn!startprocesswrite(
\tprocessModelId:
\tprocessParameters:{
\ tprocessId:
\t}
)

Note:
1. If you aren't interested in triggering a process instance before hand as mentioned in Step - 1, you can also make your implementation run a process instance only when there aren't any instances in the system or reuse a process instance (without creating any further process instances) if one such already exists.
2. The obvious downside of this implementation is that, the process contains huge chunks of data in form of PV. As the object the user interacts with is a Report, we don't know when to terminate the process. If you are in the idea to terminate the process, then you need to add an additional mechanism of triggering the process to obtain the data (that is, add a button component on the SAIL interface which will initiate the request and get the data) and also terminating the process (that is, add a button component on the SAIL interface which will close the request by terminating the process instance). To the best of my knowledge, this mechanism complicates the system and it's better to leave one instance always in the system with data and users will access it and refresh it (on need basis).
3. If the time taken to query the analytics data takes longer duration(generally this happens when there is loads of data), fn!startprocesswrite() or a webservicequery will fail in showing the data immediately after triggering a process instance. In this case, triggering a process instance before hand (and further keeping it active all the time), and querying from it would be the best fit.

The above was just an idea, probably you can improvise it, once you start working on it.

Thanks guys, for sharing your thoughts on this. Will definitely give it a try.