5 min read

Provisioning EventGrid Subscription and LogicApp Handler Using Azure CLI

Justin Yoo

You are about to build an event-driven architecture, primarily to integrate existing enterprise applications. In that case, an event broker like Azure EventGrid takes a vital role. The following diagram introduces how Azure EventGrid plays on the Azure Platform.

Azure Event Grid

But As you can see, if you are running hybrid or heterogeneous cloud, either "Custom Events" or "CloudEvents" is your choice.

Three Pillars of Event-Driven Architecture

There are three major players of the event-driven architecture. I've taken the screenshots below from my talk about CloudEvents at Open Infra Days Korea back in 2018.

Event Publisher

It's the source of the event. Any device can be the event publisher as long as it can raise events—the picture below depicted Raspberry Pi as the event publisher.

Event Publisher

Event Subscriber / Event Handler

Strictly speaking, the event subscriber should be distinguished from the event handler. But in general, the event subscriber takes care of the events including processing them, so both terms are often interchangeable. The screenshot below describes how the event subscriber handles the events and processes them for visualising.

Event Subscriber

Event Broker

Because of the events' nature, both event publisher and subscriber can't be directly integrated. Therefore, the event broker should be placed in between. Azure EventGrid is the very player as the event broker. Here's the screenshot showing how Azure EventGrid works between the publisher and subscriber.

Event Broker

If you're OK with Korean language, you can check my talk video and slides about CloudEvents. There are no English subtitles provided, unfortunately.

Provisioning Azure EventGrid Subscription in ARM Template

It's OK to provision the Azure EventGrid Custom Topic through ARM Template. However, provisioning the Azure EventGrid Subscription using ARM Template only corresponds with the System Topic, not the Custom Topic you just created without scoping it. Therefore, instead of the ARM template, you should consider Azure CLI to create the subscription.


Updates:

In fact, you can create the EventGrid Subscription resource and specify the topic using the ARM Template in two different ways.

To use the ARM Template mentioned above, the scope attribute is the key. (line #7). Here's the ARM Template written in Bicep:

resource evtgrdtopic 'Microsoft.EventGrid/topics@2020-06-01' = {
name: 'my-eventgrid-topic'
}
resource evtgrdsub 'Microsoft.EventGrid/eventSubscriptions@2020-06-01' = {
name: 'my-eventgrid-sub'
scope: evtgrdtopic
...
}

Alternatively, you can provide the nested resource type like below. In this case, you don't need the scope attribute, but as you can see the resource type and name looks more verbose (line #6-7).

resource evtgrdtopic 'Microsoft.EventGrid/topics@2020-06-01' = {
name: 'my-eventgrid-topic'
...
}
resource evtgrdsub 'Microsoft.EventGrid/topics/providers/eventSubscriptions@2020-06-01' = {
name: '${evtgrdtopic.name}/Microsoft.EventGrid/my-eventgrid-sub'
...
}

Therefore, you can provision Azure EventGrid Subscription resource like above, but let's focus on Azure CLI in this post.


Azure CLI Extensions

To provision Azure EventGrid Subscription using Azure CLI, a couple of extensions are required to install beforehand. The Logic extension is to handle Azure Logic Apps, which will be used as the event handler.

Both extensions are currently in preview and will be changed at any time without notice.

Azure CLI Commands

As I would use Azure Logic App as the event handler, I need to get its endpoint URL. To call the Logic App endpoint, we must know a SAS token for it. As the first step, we should get the resource ID of the Logic App by running the following command, az logic workflow show:

logicAppResourceId=$(az logic workflow show \
-g <resource_group_name> \
-n <logic_app_name> \
--query "id" -o tsv)

With this resource Id, use the az rest command to get the endpoint containing the SAS token.

logicAppEndpoint=$(az rest \
-m POST \
-u "https://management.azure.com$logicAppResourceId/triggers/manual/listCallbackUrl?api-version=2016-06-01" \
--query "value" -o tsv)
view raw 02-az-rest.sh hosted with ❤ by GitHub

Now, we got the Logic App endpoint to be added as the event handler. The next step would be to get the resource ID for the EventGrid Topic, by running the following command, az eventgrid topic show:

eventGridTopicId=$(az eventgrid topic show \
-g <resource_group_name> \
-n <eventgrid_topic_name> \
--query "id" -o tsv)

We got all information we need. Run the az eventgrid event-subscription create command to provision the EventGrid Subscription. Let's use the event schema type of CloudEvents, which is an incubating project of CNCF (line #4).

az eventgrid event-subscription create \
-n <eventgrid_subscription_name> \
--source-resource-id $eventGridTopicId \
--event-delivery-schema cloudeventschemav1_0 \
--endpoint-type webhook \
--endpoint $logicAppEndpoint

So, we finally got the EventGrid Subscription instance towards the EventGrid Custom Topic! And here's the one-liner of all commands above:

az eventgrid event-subscription create \
-n <eventgrid_subscription_name> \
--source-resource-id $(az eventgrid topic show \
-g <resource_group_name> \
-n <eventgrid_topic_name> \
--query "id" -o tsv) \
--event-delivery-schema cloudeventschemav1_0 \
--endpoint-type webhook \
--endpoint $(az rest \
-m POST \
-u "https://management.azure.com$(az logic workflow show \
-g <resource_group_name> \
-n <logic_app_name> \
--query "id" -o tsv)/triggers/manual/listCallbackUrl?api-version=2016-06-01" \
--query "value" -o tsv)
view raw 05-one-liner.sh hosted with ❤ by GitHub

So far, we have walked through how to provision the EventGrid Subscription to EventGrid Custom Topic, using Azure CLI. As this is command-line friendly, you can easily integrate it with any CI/CD pipeline like GitHub Actions.