Polling Http response until a condition is met using Harness HTTP step

Background

Harness platform provides an amazing capability to interact with Http APIs irrespective of architecture. It provides a step that gives the ability to define how the HTTP request should look like in a modularised way. More details on the HTTP step is provided here.

Problem

Whenever we work with a system of APIs with asynchronous behaviour, there is not direct way of knowning the outcome of a request. A classic example would be an execute API generates a UUID and we use that UUID to poll until something happens. We can solve this using a curl command but the it would be messy. We can solve and more personality to this in a pipeline by attaching the HTTP step with a Failure Strategy.

Solution

Using this amazing step coming with Retry Failure Strategy we can define the components of a polling strategy

Polling strategy components :

• Polling Retries — The total number of retries until a condition is met. We define this in the Retry failure strategy’s retry count.
• Polling Every — How often the each retry needs to occur. We define this in the Retry failure strategy’s retry interval
• Polling Until — what condition the polling needs to stop. We define this in the assertion section of a HTTP step
• Polling timeout — how long to wait for the evaluated condition to be true. The total time taken is equal to ( retry count * retry interval )

PIPELINE

In the following example, we assume that there are two APIs

• an API with POST method that generates a UUID
• an API with GET method that we can poll with the UUID as a path parameter for status “SUCCESS”

IMPLEMENTATION

Step 1 : the POST API

We call the post API that generates the UUID.

URL : the url to make the post request

https://your_post_api.com

Method : POST

Assertion : httpResponseCode == 200

<+json.object(httpResponseBody).status>=="Success"

Output Variables :

Using json functors we can fetch the uuid and store it in a variable

<+json.object(httpResponseBody).uuid>

Step 2: the polling API with Retry Failure Strategy

Add the next step that polls for status Success which takes uuid as the path parameter.

URL : Using expressions, we can fetch the output variable uuid and build the complete url

https://your_get_api.com/<+execution.steps.prev_post_http_step_identifier.output.outputVariables.uuid>

Method : GET

Assertion : Here we will define the condition for the polling condition to break. We will use json functors to assert if the status is Success.

<+json.object(httpResponseBody).status>=="Success"

Output variables :

Using json functors we store the status and store it in a variable for each retry

Failure Strategy

For the polling step, we attach Retry Failure Strategy, with post retry action, Ignore Failure. In the example provided below,

• Retry count = 24. The number of times the API needs to poll
• Retry intervals = 1m. The time gap between each retry count

The total polling time is equal to 24 * 1m = 24 minutes

Step 3: Verify if the status is Success

We check if the last polled retry status stored in the output variable from poll API is “Success” or not. If it is “Success” we exit success else we exit failure.

status=<+execution.steps.poll_api.output.outputVariables.status>
if [ "$status" = "Success" ]
then
  echo "status is success"
  exit 0
else
  echo "status is not success"
  exit 1
fi