As an Operator, I have visibility into the status of each task within a workflow so that I can determine the success or failure of individual tasks

[mike-gangl]

By running our workflows entirely within a single node of an ADES, we do not get the insight into individual task status and workflows:

workflow A: Find data --> process data (application package)--> catalog data

The entire workflow shows up via WPS-T as "success, failure, or inprogress"

Each atomic unit of the workflow should be statusable: that is, the workflow might contain the same 3 steps from workflow A, but the operator has more insight:

WPS-GetStatus --> Workflow A--> Running

but should also include links to processing endpoints to retrieve (getstatus) status of workflowA:find data, workflowA:process data, and workflowA:store data

[mike-gangl]

if OGC API is the only way of returning this info, then we really need to consider moving in that direction- we're close between WPS/T and the restful spec we are using so i don't think it will be too difficult.

Example of OGC API PRocesses status results:

https://schemas.opengis.net/ogcapi/processes/part1/1.0/examples/json/StatusInfo.json

{
"jobID": "81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
"status": "accepted",
"message": "Process started",
"progress": 0,
"created": "2021-05-04T10:13:00+05:00",
"links": [
{
"href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
"rel": "self",
"type": "application/json",
"title": "this document"
}
]
}

which would allow:

{
"jobID": "81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
"status": "accepted",
"message": "Process started",
"progress": 0,
"created": "2021-05-04T10:13:00+05:00",
"links": [
  {
     "href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
     "rel": "self",
     "type": "application/json",
      "title": "this document"
   },
  {
     "href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f.3945e95c-bed8-11ed-afa1-0242ac120002",
     "rel": "self",
     "type": "application/json",
      "title": "task 1 status"
   },
{
     "href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f.3945ebfa-bed8-11ed-afa1-0242ac120002",
     "rel": "self",
     "type": "application/json",
      "title": "task 2 status"
   },
{
     "href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f.3945ebfa-bed8-11ed-afa1-0242ac120002",
     "rel": "child",
     "type": "application/json",
      "title": "task 3 status"
   },
  ]
}

[mike-gangl]

Acceptance Criteria

Operator can view workflow status and task status from a UI unity.py/ unity.js are updated to parse calls from EMS SPS needs to update the WPS-T endpoint being called to provide more information on sub-task status.

[rtapella]

From duplicate issue:

• UIUX needs to build/update the UI to support it
• uiux adds the call to unity.py/ unity.js
• SPS needs to update the WPS-T endpoint being called to provide more information on sub-task status