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.
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 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 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.
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.
Providing Scope (Recommended)
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 | |
| ... | |
| } |
Providing Nested Resource Type (Doable but NOT Recommended)
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) |
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) |
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.