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.
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.
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.
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.
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, unless properly scoping it. Therefore, instead of the ARM template, you should consider Azure CLI to create the subscription.
But, before deep diving into Azure CLI, let's have a look how we can provision Azure EventGrid Subscription resource specific to the Custom Topic.
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).
Therefore, you can provision Azure EventGrid Subscription resource like above. Let's move onto the Azure CLI part.
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.
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:
With this resource Id, use the
az rest command to get the endpoint containing the SAS token.
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:
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).
So, we finally got the EventGrid Subscription instance towards the EventGrid Custom Topic! And here's the one-liner of all commands above:
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.