#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.

@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.