Creating subscriptions based on data in an event

I was working on a system where we had to handle updates to tickets. The tickets were managed in a separate domain, and we could receive updates of said tickets via events on Event Grid.

At first, we were subscribing to all changes, but new requirements came in to execute certain actions for specific changes. For example, whenever a ticket status changes from approved to canceled or from pending to approved.

While creating multiple events for this, we had designed our solution to only use an event called TicketStatusChanged with the old and new status inside the body. The event looked pretty much like the following piece of JSON:

// TicketStatusChanged
{
    "id": 1234,
    "NewTicket": {
        "Status": 3
        // Other properties
    },
    "OldTicket": {
        "Status": 1
        // Other properties
    }
}

Now, it is totally fine if you subscribe to the TicketStatusChanged event and decide in your code (Azure Functions) if the event needs to be handled or not. A downside of this approach would be that you are paying for computing while it is not necessary.

Using Event Grid, you can add a couple of filters that can be applied to your subscription.

The most obvious one is the ‘Included Event Types’, but the ‘subject’ is being filtered on quite often. Both are great ways to do the initial filtering, and a lot of times, this is more than enough.

If you find yourself need to filter events, my advice is you should check first if your events aren’t too broad and if you can’t make them more granular. If the answer is ‘No’, keep on reading.

One of the most incredible features of Event Grid
subscriptions is creating filters based on your event’s body! This is not supported on many other messaging platforms, for good reasons, might I add.

How does this work?

Well, your event is being added to the data property of an Event Grid event. To filter on a property from the example above, the following path must be used: data.NewTicket.Status. You can find an example of how to create these types of subscriptions via an ARM template in the following block of JSON:

{
    "name": "eventGridTopicNameOverHere/Microsoft.EventGrid/subscriptionNameOverHere",
    "type": "Microsoft.EventGrid/topics/providers/eventSubscriptions",
    "apiVersion": "2019-06-01",
    "properties": {
        "destination": {
            "endpointType": "ServiceBusQueue",
            "properties": {
                "resourceId": "" // Resource id of the queue
            }
        },
        "filter": {
            "includedEventTypes": [
                "TicketStatusChanged"
            ],
            "subjectBeginsWith": "TicketStatusChanged",
            "advancedFilters": [
                {
                    "operatorType": "NumberIn",
                    "key": "data.NewTicket.Status",
                    "values": [
                        3
                    ]
                },
                {
                    "operatorType": "NumberIn",
                    "key": "data.OldTicket.Status",
                    "values": [
                        1
                    ]
                }
            ]
        },
        "labels": [
        ],
        "eventDeliverySchema": "EventGridSchema"
    }
}

In the above example, I am using a Service Bus Queue for the subscription. Reasons for doing so are mentioned in a different article, but you can use a completely different service for the subscription.

Your code, probably an Azure Function, will only receive events with the appropriate status change. You do not need to do validation check anymore as the Function is not triggered for every possible event. This makes sure the solution will be as cheap as possible.