We have a "taskMetrics" SQL table for our applications that contains d

We have a "taskMetrics" SQL table for our applications that contains data for the "lag()" and "work()" expressions related to a task. We have found that the we need to retrieve the lag/work time for a task by running a Execute Process Report smart service node (since we cannot simply save these times in the task outputs), but have encountered some instances where the lag/work time aren't returned by the Execute Process Report node if it is implemented in a process flow directly after the task node. Adding a slight delay (3 seconds seems to work) allows the lag/work time can be consistently retrieved, but this sometimes causes issues when we would like to chain through the task write (for storing the created primary key from our taskMetrics table in a chained task in the process, for example).

My question is this: is there a way to guarantee that lag/work time can be queried for a task after it is complete? We are going to start using queryprocessan...

OriginalPostID-217691

OriginalPostID-217691

  Discussion posts and replies are publicly visible

Parents
  • Good question. I always try to keep stuff like this out of my models. So an idea could be to create a model with the only purpose to accept a task id, get some values by querying analytics and save it to DB. You could start this process using a!startProcess in the output tab. This hides some of the complexity, so from a maintenance perspective a send message event or a async subprocess could be another option. An additional delay inside the model should not be needed, but would not cause any issues if you add it.
Reply
  • Good question. I always try to keep stuff like this out of my models. So an idea could be to create a model with the only purpose to accept a task id, get some values by querying analytics and save it to DB. You could start this process using a!startProcess in the output tab. This hides some of the complexity, so from a maintenance perspective a send message event or a async subprocess could be another option. An additional delay inside the model should not be needed, but would not cause any issues if you add it.
Children
No Data