Azure Event Grid is a highly scalable event-routing service that listens for specific system events, then reacts to them according to your precise specifications. In the past, event handling has relied largely on polling—a high latency, low-efficiency approach that can prove prohibitively expensive at scale. Azure Event Grid, on the other hand, provides a highly reliable, low latency, cost-efficient solution. Azure’s robust event-routing service leverages reactive programming, serverless logic, a pay-per-operation model and guaranteed event delivery to set itself apart. Here we provide a brief overview of how Event Grid works. Then we walk through a detailed demonstration from Event Grid Project Manager Bahram Banisadr that reveals how Azure users can easily leverage Event Grid’s straightforward, point-and-click functionality for maximum effect.

Azure’s event-driven ecosystem

As Scott Hanselman points out in a recent discussion, a great deal of computing in 2018 is event-driven and event-dependent. For example, Hanselman has a blood-sugar app that sends out notifications triggered by particular events, such as his own blood sugar readings. Although these notifications can take place without a service like Event Grid, Program Manager Bahram Banisadr points out that Event Grid provides an extremely high level of flexibility, scalability, and reliability that you won’t find in an app alone. For example, using Event Grid’s straightforward, point-and-click functionality, Hanselman could easily arrange to have a blood sugar-related event automatically routed to Azure Functions, which could quickly perform sophisticated calculations on it. Moreover, Hanselman could have Event Grid distribute the event to multiple places throughout the Azure service ecosystem at once. Further, if an endpoint fails to receive the notification, Event Grid can automatically perform multiple-deliveries, repeatedly trying the endpoint “for up to 24 hours” to greatly enhance reliability.

How Event Grid works

Azure event publishers and event handlers are at the core of the Event Grid routing-service. Event Grid listens to Azure event publishers, such as Blog Storage, then reacts by routing specific events to Azure event handlers, such as WebHooks. You can easily control this entire process at a granular level through event subscriptions and event filters.

Connecting event publishers and event handlers

Event Grid’s supported event publishers currently include Custom Topics, Event Hubs, IoT Hub, Blog Storage and management options within Resource Groups and Azure Subscriptions. These are the Azure services that Event Grid listens to for specific events.

Event Grid’s supported event handlers currently include Event Hubs, WebHooks, Logic Apps, Azure Functions, Azure Automation and Microsoft Flow. These are the services that Event Grid routes events to.

Event subscriptions

Connecting event publishers to event handlers works through event subscriptions. For example, you might have an event subscription for connecting events from Blog Storage (an event publisher) with Azure Automation (an event handler).

Filtering

Filters give you the power to leverage open-ended, sophisticated IF-THEN criteria. By funneling all your events through Event Grid, then applying filters, you can ensure that the occurrence of certain events (such as a new user registration on your Azure-hosted app) triggers a certain type of action (such as an email notification to your inbox).

Getting started

To help you get started, let’s review the key points in Bahram Banisadr’s Event Grid demonstration, where he uses Azure’s robust event-routing service to trigger an email notification each time someone adds or deletes a user within his Azure subscription. Note that to reproduce the demonstration for yourself, you will first need to sign up for Event Grid as well as Logic Apps. It also helps to have an Office 365 account.

Event listening

The first step in Banisadr’s Event Grid demonstration is to create an event subscription that will listen for the addition or deletion of any new users to his Azure account. To make that happen, navigate to the Logic Apps dashboard from within the Azure portal and click on Blank Logic App. A search box will appear with the prompt: “Search all connections and triggers.” Below the search box you will see an array of connection types (e.g. HTTP, Service Bus, SQL Server) followed by a list of several hundred possible triggers. Enter Azure Event Grid into the search box. Azure Event Grid will appear within the Trigger results. Click on it to continue.

Creating an event subscription

At this point, a simple form will appear with three required fields: Subscription, Resource type and Resource name. As Scott Hanselman points out, these three fields constitute the IF half of Event Grid’s robust IF, THEN functionality:

Subscription

The Subscription field’s drop-down list will include all of your Azure subscriptions. Select the unique identifier for the Azure subscription you would like to use for this event subscription.

Resource type

From the drop-down list, select the type of resource you will be using to “create the event subscription on.” Note that resource types can be namespaces, resource groups, Azure subscriptions, or other categories that resources can fall into. For this example, choose Microsoft.Resources.subscriptions.

Resource name

Here you will need to choose the resource that your event subscription will “listen to for events.” The drop-down list will include all the resources, such as instances, attached to your Azure subscription. In Banisadr’s demonstration, he chooses one of his Azure Event Grid instances for the demonstration. After making his choice, two additional fields appear—Prefix filter and Suffix filter, to narrow down the range of events that the system will listen to on his behalf. Banisadr uses a prefix filter to specify that he only wants the system to listen for user role-assignment changes within his specified Azure subscription.

Adding an action

To proceed to what Hanselman identifies as the THEN half of Event Grid’s IF-THEN functionality, click New step and choose Add an action. A search box will appear that is similar to the first one encountered above, but with a slightly different prompt: “Search all connections and actions.” Below the search box you will find the same connection types encountered above. Yet this time they will be followed by a list of thousands of possible actions (rather than triggers). Enter Office in the search box to see all Office 365-related actions. Then choose Send an email. A form will appear for adding an email address, subject line and body.

Far from a rigid email template, this set of fields has an Add dynamic content feature that allows you to add contextual information to the notification body that applies to the specific event that has taken place. In Banisadr’s demo, he chooses the Subject option (not to be confused with the Subject line) which will automatically enter the “full path to where the role assignment change has occurred” to the body of each email notification.

Running the event subscription

To run the event subscription, click Save, then Run in the toolbar at the top of page. Then perform a new user role-assignment within your Azure subscription to test it out. In Banisadr’s demo, he opens his corresponding Azure subscription and assigns Scott Hanselman the contributor user role. After a delay of just a few seconds, Banisadr receives an email in his corresponding inbox with the subject line “New User added to subscription.” In accordance with the dynamic-content feature, the body of the notification email includes the precise location of the change.

At this point in the demonstration, Scott Hanselman notices that there was a slight delay in the email delivery. Surprisingly, upon investigating they find that the delay is not due to a weakness, but a significant strength, in Event Grid’s routing system. When Banisadr checks his Event Grid logs, he sees that the service made an initial attempt to send the notification, encountered a blockage of some kind, and then automatically tried again, this time successfully. Event Grid’s built-in retry feature is what ensured eventual delivery. By contrast, using an in-app notification process outside of Event Grid might have resulted in a failed delivery in this case. Banisadr also points out that the Event Grid system could have easily sent copies of the same notification to any number of specified recipients or Azure Event Handlers for a more sophisticated treatment.

Azure Event Grid: a robust, efficient event-routing system

Overall, Azure Event Grid provides an elegant solution to a growing challenge in cloud computing: how to filter and route enormous numbers of system events from event publishers to event handlers in an efficient, scalable fashion. To rise to the challenge, Event Grid listens for specific events from event publishers, such as Blog Storage, then instantly responds by routing those events to event handlers, such as WebHooks. Event subscriptions, filters, triggers and actions provide Azure users with granular control of the entire event-routing process. To help you get started, we walked through Bahram Banisadr’s illuminating Event Grid demonstration, where he uses Azure’s robust event-routing service to send himself an email notification whenever someone adds or deletes a user within his Azure subscription. To complete the circuit, it was necessary to provide a precise trigger (the user addition/deletion) by selecting an Azure subscription, resource type and resource name with filters. As Scott Hanselman points out, these three fields (at least in this case) constitute the IF half of Event Grid’s robust IF, THEN functionality. Next, it was necessary to add an action (the email notification) in response to the trigger: the THEN part of the functionality. Finally, running and testing the event subscription was an entirely code-free process requiring nothing more than a few quick clicks.

To learn more about Azure Event Grid and other transformative Azure services, contact us.