PortiBlog

Azure Automation - Part 2: Triggering runbooks

1 april 2021

In the second part of this Azure Automation series, we'll discuss triggering runbooks. Besides hitting the play button to manually trigger one, we're further looking into automation and see how we can trigger a runbook based on an event or how we can schedule a runbook. 

This blog is the second post in a series of posts about Azure Automation. Also check out: Azure Automation - Part 1: Create a SharePoint site and Azure Automation - Part 3: Dynamic scheduling.

Event-Driven architecture


The very nature of Cloud services, being it PaaS or SaaS, has steered us developers towards Event-Driven architecture. Because lots of services must talk to each other and we all want this to happen at real time, polling has become a legacy pattern. An elaborate piece on this can be read here.

When going severless and running workloads in the Cloud most of these workloads are triggered by events. For instance, a new project is added to system X and therefor something must happen in system Y. This workload, in our case scripted in an Azure Runbook, can be triggered when an event occurs. 

Trigger 1: Webhooks.

For every runbook you can generate a webhook trigger. This webhook can be used by any application that can POST a request to the specific webhook URL, unique for this runbook. This can be from a static Web Application or even a PowerShell script that runs on a local machine. From a developer's perspective this trigger is most versatile. 

Webhooks
Webhook created

Trigger 2: Azure Logic Apps (or Power Automate).

One of the most straightforward options when integrating runbooks with other services on Azure is Azure Logic Apps. The great advantage of Logic Apps is the numerous connectors that are available out of the box, that makes integration easy. On top of the connectors, it's also ideal to add abstract logic or business rules from your runbooks and put them inside the Logic App. In a traditional 3-tier architecture the Logic App would act as an Application Layer in this case. 

In this example we let our Azure Logic App check every hour for new requests in a SharePoint List. For every request present, a new Runbook job is created. By the way, connecting to Azure Automation to trigger a runbook using Power Automate looks similar to Logic Apps.  

Logic App 1
Recurrence trigger with SharePoint connector

Logic App 2
Create runbook job with Azure Automation connector

On a sidenote: If we would fully adopt the Event-Driven architecture, we can also use a webhook to trigger the Azure Logic App to trigger our runbook. That way we can skip the recurrence trigger and act real-time to changes while still being able to benefit from the business logic in our Logic App. 

Trigger 3: Schedule.

Every runbook can also be scheduled from the Azure Automation account to run only once or as a recurring event. Schedules are easily created manually (or automatically, I'll describe that in part 3 of this blog series). A schedule is created on the Azure Automation account level and a runbook can then be linked to that schedule. 

Schedule 1
Run Once

Schedule 2
Recurring

Schedule 3
Linked to a runbook


That's it.

These mentioned trigger options are in a place to start a runbook remotely or from code. All other triggers you may find online come down to one of these methods. As a matter of, I think even the Logic Apps / Power Automate connection also works based on the webhook approach. Not completely sure though. 

Next up: When diving deeper into automating my tasks I also tried to automate the creation of schedules in a dynamic way. Want to know more? Check out upcoming post: Azure Automation - Part 3: Dynamic Scheduling



Nieuws.

Portiva gaat verder met Rapid Circle. Binnenkort organiseren wij onze webinars dan ook onder de naam Rapid Circle. Lees meer over ons en Rapid Circle in het nieuwsbericht.

LogoMorphNew-transparent-light-background

Submit a comment