Page 28 - MSDN Magazine, February 2018

New Employee Equipment Order is an Azure Function that will subscribe to events for new employees in the Engineering department. It will then create a message in a queue for additional processing.
Employee Records is a custom Web site built on ASP.NET Core that will expose a Web API for receiving messages when employees leave the organization.
Creating a Custom Topic
To get started, I’ll need to create a few basic resources in Azure. You can either launch the Azure Cloud Shell from the portal or use the command-line interface (CLI) locally. Details on how to use the Cloud Shell can be found at bit.ly/2CsFtQB. If you haven’t used Cloud Shell before, I highly recommend it.
Make note of the endpoint value—it will be used later when publishing events.
The first thing I’m going to do is create a resource group to manage and encapsulate the Azure resources:
az group create --name <resource-group-name> --location <location>
After the group is created, an Event Grid Topic is provisioned. This will provide an endpoint to publish custom events from the HR application. The name of the topic must be unique to the region, as it will be a publicly accessible service on Azure. The location must also be in a region that has the Event Grid service available. I usually go with the westus2 location or refer to the list of services provided in each Azure region (see bit.ly/2DU15ln).
az eventgrid topic create --name <topic-name> \ --location <location> \
--resource-group <resource group name>
After executing the command to create the topic, details about the resource will be returned. The output will look similar to, but not exactly like, the code here:
{
"endpoint": "https://<topic name>.westus2-1.eventgrid.azure.net/api/events", "id": "/subscriptions/xxxx-xxx-xx-xxx-xx/resourceGroups/
eventgridsolution-rg/providers/Microsoft.EventGrid/topics/<topic name>", "location": "westus2",
"name": "<topic name>",
"provisioningState": "Succeeded",
"resourceGroup": "eventgridsolution-rg", "tags": null,
"type": "Microsoft.EventGrid/topics"
}
Figure 5 Employee Added Event
Make note of the endpoint value—it will be used later when publishing events. You’ll also need one of the two access keys that were generated for authorization. To retrieve the keys, you can list the ones associated with the topic. You can and should cycle and regenerate these keys as a security measure—just like you would
with other services on Azure.
az eventgrid topic key list --name <topic-name> --resource-group <resource-group-name>
If your preference is to work within the Azure Portal, you can create and view all these options and settings there, as well.
Publishing an Event
Before sending the first event, you need to understand the event schema that’s expected by the topic. Each event, regardless of if the publisher is an Azure resource or custom application, will adhere to the structure outlined in the following code (a helpful reference for the event schema, as well as some examples, can be
found at bit.ly/2CG8oxI): [
{
"topic": string, "subject": string, "id": string, "eventType": string, "eventTime": string, "data":{
object-unique-to-each-publisher }
]
The first thing to point out is that events are sent in an array. This is purposely done to provide the ability to send multiple events within a request. Events can be sent in batches, which reduces network chattiness while supporting scenarios where connectivity isn’t always available.
The first event I want to publish is for when a new employee joins an organization. The payload for this event may resemble the contents of Figure 5.
Later in the article I’ll use the same structure, with some differ- ences in the values, as when an employee leaves the organization. The key properties in this event are as follows:
eventType is a value used to uniquely identify the published event type. This property can be used by handlers wishing to sub- scribe only to specific event types, rather than all types.
subject is a value, like eventType, that’s available to provide additional context about the event, with the option of also provid- ing an additional filter to subscribers. I’ll leverage both eventType and subject soon when I create the subscriptions. Subject and eventType give context to the event.
data is a publisher-defined bucket that’s simply an object that can contain one or more properties. Publishers assign relevant information about the event itself inside this property. For exam- ple, the Azure Blob storage event includes details about the created or deleted blob such as URL and content type.
To publish the event, I use Postman (or a similar tool) to simu- late the message coming from the HR application to the endpoint address mentioned earlier. For authorization, I add an item in the header called aeg-sas-key—it’s value is one of the access keys generated when the topic is created. The body of the request will contain the payload mentioned in Figure 5.
}
[{
"id": "30934",
"eventType": "employeeAdded",
"subject": "department/engineering", "eventTime": "2017-12-14T10:10:20+00:00", "data":{
"employeeId": "14",
"employeeName": "Nigel Tufnel", "employeeEmail": "nigel@contoso.com", "manager": "itmanager@contoso.com", "managerId": "4"
} }]
24 msdn magazine
Microsoft Azure