#webAPI#queryProcessAnalytics I got a requirement to return a taskId (tp!id

@philiposz Hi, I guess there is no surprise in it, as the initiation of a process using a!startProcess() is asynchronous. Apart from the processInfo returned by the function call, we can't guarantee about any other information. At times you may get an output and at times you may not, but you can't guarantee about its return. Especially when the user input task is very far in the process model, definitely there isn't a chance of obtaining a task id after triggering a process using a!startProcess().

To the best of my knowledge, you may need to plan for a workaround. For instance, I have used the a!startProcess() in a Tempo Report to trigger a process that export the datasets and put the same in multiple files. There exists a button by name 'Extract and export data' which actually triggers the process using a!startProcess(). Next to it, I have placed another button by name 'Refresh' which checks for the task by making a query to the analytics with the process id obtained from the call to a!startProcess(). Once when the task is available, the interface surfaces a link to the task.

An alternate design you might think of is, place the user input task immediately after the Start Event. Though the actual data required for the task should be populated prior to User Input Task, make sure that the User Input Task is activated in the very beginning after the Start Event (just to make sure that the Task Id is immediately available) and later on, refresh the contents of the Task when the required nodes are run. Or you may also place a Refresh button in the User Input Task which will get the required data by interacting with analytics or database so that the task can have all the required information to complete. But still I don't think we can guarantee the return of Task Id, as the call is asynchronous.

Let's see what other practitioner opines.

*practitioners opine.

@sikhivahans, I really appreciated your help. I followed the second design you suggested and I have created a sub process, place it after start node and did run the asynchronously with the parent process model. I got task Id all time i tested it more than 50 times. but i guess still we can't guarantee as you said.

I suggest to split up the API calls. One call to start the process and return the ID and another call to get the task IDs. The second call can then return the task ID or if the task is not available yet some information about process status. This way you do not have to rely on some timing and on hope that it will work.

I believe I have done something similar to thoughts of @stefanh. Simply speaking, we aren't relying on anything as the asynchronous calls aren't trustworthy.

@philiposz Mostly you may get the taskId as the task is triggered immediately but make sure that you also test it in the environments such as Live where the volume of processes is high.