“It was the week before Christmas, and…” and I was actually super busy! One of my main tasks on that week was to implement notifications when a legacy Dynamics AX, still running on-premises, had orders ready to delivery.
My solution was relatively simple (although needed to be generic enough to include other notifications later):
I had a very simple event data being provided by the notification repository:
{
"NotificationId": "NOT-00001",
"NotificationType": "SalesOrder.Delivery",
"CustomerId": "CUST-001",
"Status": "New",
"LastModifiedDateTime": "2019-12-20T11:02:28.13"
}
I thought that it was quite an easy setup, but I got stuck for a while setting up the Event Grid Logic App trigger. Why? I was expecting that the trigger would support advanced filters out of the box, on the designer experience, but that’s not the case.
Looking at the Event Grid trigger (When a resource event occurs), you will find the following options:
You can define one or more Event Types to deploy and you can filter by prefix or sufix of the subject. But there is no advanced filter…
Initially I thought it was just a case of adding advanced filters on the code view – like I saw so many times in the pas, but this time this didn’t work. Or at least I couldn’t find a way to include the advancedFilters element as an input parameter. The problem was that, although the logic app would save the workflow with no errors (and then include the whole filter as a property custom filter in the trigger, no subscription would be created in the event grid topic.
One thing I found exploring the extra parameters, was that there is a Subscription Name optional parameter. Defining the Subscription Name that will be created in the event grid topic will help you to identify it easier in the topic blade. That ended up being quite useful in the long run, when I was debugging the subscription problem.
So, to debug, I created a simpler subscription, including only the event type – which by the way needs to be included as a custom value, since this is a custom event topic.
That created the subscription in the Event Grid Topic. Since I had not luck adding the advanced filter on the logic app side, I thought that I could try to update the subscription on the event grid side.
First, I found the subscription on the event grid topic (and this is where the customized subscription name comes in handy – you can identify it straight away instead of trying to hunt it based on the webhook created):
Once I found the event grid subscription, I clicked on it which takes me to the overview page. In there I could click on Filters (1) and amend the subscription filter, by adding a new advanced filter (2). In my case:
- I choose the information in the Data section (which uses the format Data.<Property>).
- Since I wanted it to match to a string value I used String is in operator, which allows me to match the value to a list of values.
- Selected the value I wanted to match – Order.Delivery
Finally, when the subscription has been updated to my liking, I simply saved it (3).
There are a lot of other options for the Advanced Filtering both for the keys you can use and the operators. You can find more information about it here.
After that, the subscription started to be triggered correctly. So far this is where I got to. Next step is how to replicate so I can move the subscription configuration across other environments.
Unfortunately, there is not much guidance online on how the advancedFiltering property relates to the subscription filters neither in the ARM Template for event subscriptions or on the subscription documentation in Microsoft Docs. Ideally this would be integrated into the Event Grid trigger creation, but feels like there is an underlying gap in the ARM template itself for that.
Summary
Event grid advance filtering is not available out of the box from Logic Apps, but with some manual workaround you will be able to implement this feature in your workflows. Unfortunately seems like a purely manual step at this stage, at least from a ARM template automation point of view. I am pretty sure I will be able to automate this at a later stage using Azure CLI, but since most of my automation is ARM based, I would really like to have an ARM solution for this problem. I reckon I will be discussing this with the product group in the New Year…
Leave a Reply