In order to have a sample “data feed” for an application I wanted to use Azure Event Grid to create a topic that events could be published to and clients could subscribe to in order to process the events.

The generic scenario is that of alarms (of whatever sort you’d imagine; car, house, IoT device) for which the events represent status updates.

This is the first post about getting started but in my next posts I will cover consuming the events in an Azure Logic App and turning the custom event publishing app into a Docker image.

Creating an Event Grid Topic

The first step is to create the Event Grid Topic. As Event Grid is serverless, this is as easy as you might expect (no thinking about infrastructure, sizing or scaling). The step by step how to is here but you simply give it a name, a resource group and choose the region to run it in. Wait a few seconds and that’s it, the Topic is created:

Creating a publisher (custom app)

I wanted to create an app that would keep generating events, representing alarms and their status, and publishing these to the Event Grid Topic created above.

Publishing an event is simply performing an HTTP Post, and although I chose to implement this in .NET Core, you could choose almost any language.

The data object in an Azure Event Grid event is a JSON payload, and therefore I started by thinking about what that data would consist of:

For my purposes I wanted the alarm to include the device id, an image sent by the alarm (in fact a URL to an image in blob storage), the location of the alarm (longitude and latitude) and the status (green, amber, red).

The key point for me that I’d call out is that if you’re used to the .NET HttpClient then in .NET Core HttpClient doesn’t have a PostAsJsonAsync method. Instead what I’ve ended up doing is create a class as follows:

There are other ways of doing all of this of course but if you want it then all my code can be found in GitHub. A reasonable amount of the code is my attempt at setting configurable boundaries for the geographical location for the devices, but it’s not relevant here so I won’t go into it.

Before you commit to Git, make sure you have an appropriate .gitignore file to ensure you’re only staging the files you need. For .NET Core I used this one:

I didn’t want to hardcode some of the key Event Grid information both so that keys didn’t end up in GitHub and also to make it reusable for other Topics. Therefore I can now run my console app from the command line providing some key arguments:

dotnet run <EventTopicURL> <EventResourcePath> <EventKey>

where:

EventTopicURL: the endpoint for the Event Grid Topic and can be copied from the Overview blade in the Azure Portal.

EventResourcePath: the path to the resource and is of the form: /subscriptions/< Azure subscription id>/resourceGroups/<Event Grid Topic resource group name>/providers/Microsoft.EventGrid/topics/<Event Grid Topic name>.

EventKey: the key for the Event Grid Topic and can be copied from the Access Keys blade in the Azure Portal.

In the next post I’ll look at how to subscribe to the Topic with a Logic App to both test and consume the events.