Page 30 - MSDN Magazine, February 2018

var code = gridEvent.Data["validationCode"]; return req.CreateResponse(HttpStatusCode.OK,
new { validationResponse = code });
Validation requests can also be identified by their event type: Microsoft.EventGrid.SubscriptionValidationEvent. If the event type is Notification, then I proceed with the implementation of the business logic. This defensive programming approach is highly recommended when exposing endpoints to other services.
Functions that are hosted in Azure, and are referenced with the azurewebsites.net domain, do not require the subscription validation logic. Instead, they’re whitelisted by Event Grid along with several other services such as Logic Apps and callbacks from Azure Automation run books. Because I plan to test locally, I need to echo back the validation code for Event Grid to acknowledge the function as a valid endpoint.
Figure 8 A Logic App That Welcomes New Employees 26 msdn magazine
Eventually the Event Grid runtime SDK will handle much of this setup, from deserializing events and creating strongly typed Event Grid objects, to validating endpoints automatically. As of this writing, the updated runtime SDKs were not yet available.
Local Function Testing
Let’s start the function from Visual Studio so that it runs locally on port 7071. Once it’s running, open a command prompt and use ngrok to create a secure tunnel:
ngrok http -host-header=localhost 7071
I’ll get back an HTTPS address from ngrok to use as the subscriber endpoint. The address should look something like https://d69f6bed.ngrok.io, but with a different subdomain each time the ngrok command is executed. Append the route of our function to the URL so that it resembles something like https://<generated-value>.ngrok.io/api/newemployeehandler. This will be the endpoint address for the event subscription.
With the function running and the secure tunnel in place, I can now create the event subscription from the CLI or Azure Cloud Shell:
az eventgrid event-subscription create --name <event-subscription-name> \ --resource-group <resource group name> \
--topic-name <topic name> \
--subject-ends-with engineering \
--included-event-type employeeAdded \ --endpoint <function endpoint>
Optionally, I can add an event subscription from the portal by filling out the dialog, as shown in Figure 7.
I want to call out several important arguments in the creation of the event subscription.
subject-begins-with (Prefix Filter) is an optional argument that filters based on the prefix of the subject field in the events. It is a literal string match. Wildcard characters and regular expres- sions are not supported.
subject-ends-with (Suffix Filter) is an optional argument based on a suffix to filter events. Wildcard characters and regular expressions are not supported.
included-event-type (Event Types) is an optional list of event types to subscribe to. Each type is separated by a space.
Now I can return to the publishing event example earlier in the article to ensure that events are flowing through from Postman, to Event Grid, and ultimately to the local function. Feel free to change the values in the request to validate the filters are work- ing as expected.
Handling Events: Logic App and WebHook
The next event subscription is a Logic App. Like the Azure Func- tion example, it’s only interested in the added employee event type. It won’t leverage the prefix or suffix filters, because I want to send a message to employees from all departments. The completed version of the Logic App is shown in Figure 8.
The Logic App begins with an Event Grid trigger. Selecting Microsoft.EventGrid.topics as the resource type will allow me to pick from the custom topics in the subscription.
The Parse JSON action will be helpful in accessing the prop- erties within the Data object. I’ll use this sample payload to generate the schema:
Microsoft Azure