Open APIs

 View Only

TMF701 background task state transitions

  • 1.  TMF701 background task state transitions

    Posted Dec 02, 2021 17:40

    Just a couple of questions on TMF701.

    We've created a process definition comprising a number of tasks, some automated, some manual. We've found a particular scenario where the automation between two user tasks is taking an excessive duration which is problematic for our front end tier. Instead of blocking the thread, we aim to instead put the long running task into a background process thread. The question then becomes how best to represent this on the API. We'd like to deliver a user task state up indicating the waiting state, but to indicate implicit state change from the waiting task state to the next one on background process completion, e.g.

    PATCH /processFlow/123/taskFlow/456     // resumes the process,  almost immediately delivers a waiting state while we kicks off background task, say taskFlow/457
    GET /processFlow/123/taskFlow/457   // client can poll on this via GET
    eventually the process moves to another state, so when the client next polls they should get taskFlow/458
    GET /processFlow/123/taskFlow/457    // does this give a 302 redirect to /processFlow/123/taskFlow/458 ???

    Or should we perhaps get the client to simply GET on /processFlow/123 and let the payload list the tasks, which move from taskFlow 457 being active to 458 being active ?

    Alternatively the state change could be modelled by the client subscribing to notification events, but that seems a bit messy, the client is using the direct API for most progress but having to augment that with event listening

    A second simpler query, just to confirm that it's entirely valid - provided the client has sufficient understanding of the process to execute, is it valid to instigate an execution that triggers the tasks (perhaps all automated) and effectively obtain the process result with a single POST HTTP request?



    tim fulcher