When you run a Triggered Task, the request is synchronous by default. The Task responds with an HTTP response status code upon completion. However, if the Pipeline has a single, unterminated Snap providing output, then the output from that Snap is provided as the response to the request. This behavior lets the developer make the pipeline asynchronous, in that the response is written back to the user., unless it is called using the Snaplex/Alternate URL in the Task Details page (also known as a Groundplex trigger).
Calling the task through the Cloud URL on the Task Details page (also known as the cloud trigger), makes the call synchronous, irrespective of whether the associated pipeline has an output view open or not. However, since Groundplex triggers are asynchronous, they require a pipeline's output view open to wait for the output to be sent in the response
The Task responds with an HTTP response status code upon completion.
For example, take the following Pipeline:
...
When you trigger the Task created from this Pipeline, for example from a browser, you receive an HTTP response status code on completion.
For example:
{ , such as:
http_status_code:200
...
The request waits until the Pipeline execution has completed before displaying this message.
If you want to make the Pipeline asynchronous, you can However, if the Pipeline has a single, unterminated Snap providing output, then the output from that Snap is provided as the response to the request. This behavior lets the developer make the pipeline asynchronous, in that the response is written back to the user.
For example, if we take the same pipeline and add a Snap with an unterminated output, as shown in the following example:, then the call is asynchronous.
Now when you trigger the Task created from this Pipeline, the output from the response Generator Snap is provided almost as soon as the Pipeline executions starts.
In this case, a JSON Generator responds with the message shown:
{ msg: "Started Ok", http_status_code: 200 }The net effect of which is that the Pipeline execution behaves asynchronously.
...
In this Pipeline, the execution status is routed to the error view, which is redirected to reflect in the browser using the Binary Header Properties of the JSON Formatter Snap.
| Note |
|---|
The workaround of using Binary Header properties is mainly useful when you want to view the exact execution status of the Triggered Task, which might not be consistent with the status code otherwise reflected on the browser. |
The status code (405) as retrieved from the Pipeline is mapped to the response:
The JSON Formatter Snap passes the actual status code to the browser via the Binary Header Properties:
...