IBM Cloud Pak for AIOps continues to evolve to meet the needs of our customers. Today, we’re introducing Asynchronous Runbooks in Runbook Automation (RBA) — an important addition to how remediation automation is executed.

Why Asynchronous Runbooks Matter

Many enterprise remediation actions cannot complete instantly. Remediation frequently involves automation that takes minutes, not seconds, and requires the monitoring of outcomes rather than waiting synchronously for completion.

Asynchronous Runbooks gives the flexibility to call an API, get a response, parse it, and call an additional API to confirm it was completed successfully based on flexible user defined criteria.

Asynchronous execution does not mean “fire and forget”.  In Cloud Pak for AIOps, runbooks become observable and controllable execution objects:

• Invocation is separated from completion
• Outcomes can be monitored and acted on

Let’s start with an example!

I have an Ansible Automation Playbook “Hello World” example that I can call.  To do so I define a HTTP Action like as I would have with a synchronous Action:

Next I can change the switch to specify that I want to get the result asynchronously.  This opens up a series of additional parameters.  The first is the “Job Id” where I specify the field in the response that I want to use.

I can use that field in the URL by specifying {{jobId}} as a placeholder for whatever field I specified above.  Note, if the value above was “id” or “status” I would still specify {{jobId}} in the URL.

The METHOD should be specified.  The default is GET, but we support all HTTP methods.

I can specify additional headers – in this case I need to pass along my Bearer token. If I had needed to specify more than one header, I could have separated the values with a semi-colon (;).

Then I specify the Poll Interval (in seconds), the Maximum Poll Attempts and a Timeout.

I then need to specify a Success Condition, and optionally a Fail Condition.  Within those conditions you can specify the statusCode (which is the variable that gets populated with the HTTP response code), and a field in the response to the Status Check URL by prefixing the field with response.  The conditions use JavaScript syntax so allow AND (&&) or OR (||) syntax.  Testing for equivalence use a double or triple equal sign (in JavaScript the subtle difference in that double will do a type conversion whereas triple will not).

In the case of neither the success nor the failure conditions being met, the polling stops when the max poll attempts is reached or it times out after the specified timeout value.

Finally, I can test my new Action, and ensure that it succeeds.  Below, the response Status field and Status Code match my success Condition so the overall Action is Successful.

For those not familiar, this conditional logic can be combined with Conditional Branching between Actions and is also discussed in this other blog.