How to: Getting started with Qlik application automation APIs in Qlik application automation.

[PradeepUrala]

This article overviews the Automations API blocks and Webhook capabilities in the Qlik Cloud Services connector in Qlik Application Automation. Please check this article for a basic introduction to the Qlik Cloud Services connector.

Using these blocks, you can explore the automation capabilities in the Qlik Cloud connector.

To select the Automation API blocks, click on the Qlik Cloud Services connector from the left side menu, then click on the Automation filter.

The connector consists of CRUD support for the Automation functionalities. A few of them are explained in brief below:

• Retry automation run: This block helps retry automation run with the specific inputs of that run in case the original call encountered an issue.
• Change the owner of automation: This block can be used to move specific automation to another user.
• Export automation run: This block helps to export the logs of the automation run. The response of this API is a public URL that is valid for 5 minutes.
• Copy automation: This block makes copies of the entire automation of a tenant.

On top of the blocks mentioned above, you also have access to a couple of webhooks meant to facilitate the monitoring of your automation. As you might have glanced in the article mentioned above, you can configure the start block of your automation to listen to certain events happening in your tenant.

The following paragraphs will cover more in-depth the webhooks pertaining to automation event listening.

Automation triggers

This includes listening to the trigger of the creation of an automation in your tenant, updating an automation or deleting one. Configuring your automation to react to one of the three events can be done easily by changing your start block like in the image shown below:

Now every time an automation gets created in your tenant, your newly configured automation will fire and run the flow you set up for it. One word of warning is there is a difference between normal users and admin users that are setting up one such webhook. While admin users will receive notifications from the entire tenant about automations, normal users will only be notified by changes in the space they will have read access to.

Automation run triggers

This includes listening to the run events of a certain list of automations. Run events covered are when an automation starts, when an automation fails, or when an automation finishes (regardless of its finished status - complete/failed). Again, configuring can be done easily like in the image below:

Reiterating the warning from above, admin users will have access to the whole tenant automations while normal users only to the ones they have access to. After configuring the start block, your automation will receive information whenever your selected automation gets triggered, fails or completes.

Warning about the usage of the run triggers

It is possible to create a so-called infinite loop when building an automation and using the Run webhook trigger. For this there are some cases we urge you strongly to avoid:

• When using the "Run started" webhook trigger, never select your own automation id since that would cause the automation to call itself with no stop in sight.
• When using the "Run started" webhook trigger, make sure you don't use any "Run automation" blocks in that same flow that might trigger a run of the automation your webhook is listening to
• Both of these warnings also apply to the usage of the "Run automation" block (never make the target of the block the same automation or the target automation contains another block that might call the initial one)