logic apps – Note to self

And all of a sudden, its 2022!

And with that, another year goes by. Another year where communities had to revamp themselves and learn how to thrive in a online world. Here in NZ, after what started to look like we were pretty much bat to normal life, the reality of living during a pandemic stroked back, like the villain in the second movie of a trilogy. But if this pandemic is a trilogy, the good news is that we are going to the third instalment… There will be strife, there will be challenges, but hopefully the writers of this cosmic trilogy are aiming for an ending where all of us completes the hero’s journey successfully.

2021 was a year of changes for me.

Calling API Management from Azure Function using Managed Identities

One of the solutions I am consulting on today is securing a number of APIs with OAuth with client credential flow, using Azure Active Directory as the identity provider. Those APIs are exposed via Azure API Management, which makes the validation of the access tokens provided as simple as injecting a policy at a product, API or operation level.

While this all works nicely, there is one item in this process which is a painpoint from an operations point of view: as they use client certificates to request access tokens, the certificate management is becoming a bit of a chore with the number of APIs and clients that access those APIs increasing.

A lot of those clients are either Azure Functions or Azure Logic Apps, which today provide the ability to using a managed identity to easy the burden of maintaining credentials.

So it was only logical to think about how would we be able to use the managed identities configured in both Azure Functions and Logic Apps to generate a token that can be validated by API Management. Turns out that this is quite possible, but needs a bit of preparation…

Azure Functions with a Static Outbound IP Address

“So to complete our configuration we just need your outbound static IP…” This is something that pops up again and again, specially if you work integrating legacy systems, like banks, government agencies or other older systems that requires a static IP Address to add to firewall inbound rules.

In the past I had to use on of the subscription tiers from Azure API Management or in some cases deploy the code within a self hosted service in a Virtual Machine. And both of them are valid options if you already have one of those components in place. But in a couple of my last projects, Not only I needed to implement a new component (in this case API Management) just to fulfil this requirement. I also had to change my design a bit, because API Management didn’t support one of the streaming requirements I had (but that is a story for another post).

But I wouldn’t be writing a post just to complain about this (not that this has never happened before) – I actually found another solution – one that I’ve tried and discarded earlier this year, but thanks to some good work from the App Services Engineering team, is finally a viable solution: Azure Functions + VNET Integration + NAT Gateways!

Recapping Integrate 2020

Last week I’ve attended the Integrate conference once again. It was my 5th time attending the conference, and the 4th time I’ve participate as a speaker.

But Integrate 2020 was quite a different experience from the last years. Dubbed Integrate 2020 Remote, to reflect the fact that was yet another event that had to adapt to the pandemic reality that assaulted the planet since the end of last year. Kovai, the company formerly know as BizTalk 360, and the event organizer since its inception in 2012, took some time to decide that the event would go ahead, but when decided that it would be in a new format, didn’t pull any stops to get it running. With almost 1000 online attendees – which is impressive for a paid event, Integrate 2020 had 28 speakers, between Microsoft Program Managers and Microsoft MVPs and as many technical sessions distributed across three days.

MS Build Recap – The AIS Edition

This year’s MS Build was very different – we all know that. But for most of us, me included, was the first opportunity to join the event officially. And what event it was.

Ran across three time zone, with a mix of live sessions, Teams Live events and smaller Teams events, like focus groups, which allowed the attendees to really interact with the product groups and advocates from Microsoft.

This year there were some interesting announcements around the Azure Integration Services technologies. I’ve recently shared those announcements on a Auckland Azure User Group meetup, and thought that, since I already had everything collated, it would be a good idea to just share this with you on the blog as well. So, let’s talk about what is now available, or just \around the corner for AIS

Event Grid Advanced Filtering on Logic Apps

“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.

Integrate 2019 in Review

I was on my flight back from London, returning from Integrate 2019, when I started this blog post. It was a very long flight, around 24 hours each way, but even if the jetlag hit me really hard this time around, it wsa worth it. Integrate grew from an initiative from a group of BizTalk MVPs, into the premier conference for Microsoft Integration technologies. It was my honour to be a presenter for the third year in a row, presenting alongside a Microsoft team comprised of Product Managers, Architects and Engineers – the people that actually design and implement the technologies I use on a daily basis – and legends from the Microsoft Integration community like Sandro Pereira, Steefan Wiggers, Richard Seroter, Michael Stephenson and Kent Weare, just to name a few.

The conference is run by Kovai Co – the company formerly known as BizTalk 360 – as a very well oiled machine. A large team from Kovai dedicate months ahead preparing the conference. This edition of Integrate was the largest yet, with over 480 participants, with 26 speakers and 28 sessions, across 3 days.

If I had to choose one theme from the conference this year, would be governance. Seems like most of the integration related technologies got to a stage where the core set of features are available and companies are using them actively. All that activity highlighted the requirement for better tooling and guidance around various aspects of the governance of the platform. From DevOps guidance to security and bettern integration between on-premises and the cloud, pretty much every product group had recent or new announcements around that theme.

Logic App Trigger Conditions

During December’s episode of Integration Downunder, Alessandro Moura showed a recap of the main features that announced for Logic Apps throughout the year. If you didn’t watch it on the day, you should take a look at the webcast.

One of the features that caught my attention, which I haven’t seen before, was the trigger condition. The ability to only fire a logic app if the condition is met. This is great for scenarios where you don’t have control over the event which triggers the logic app (like for example Dynamics 365 triggers, which only allow you to execute a logic app when a record for a given entity has been created or updated), but don’t want to implement the checks within the logic apps itself.

Resetting the State of a Logic App Trigger

This week we’ve been preparing for a Go Live in a project that integrates Dynamics 365 Field Services with an on-premises system . Part of this process was to run a series of migration script to get data from the on-prem system into D365.

Since D365 pushes the information into logic apps, I thought that the safest way to run that migration would be to simply disable the logic apps that would triggered by the process and the event would be “lost”. But to my surprise logic apps triggers are more powerful than that and remember the last event being processed. So when I turned on my logic apps after the migration, I was “rewarded” with thousands of triggers being fired…

To be honest this is quite powerful, because in cases where you had to take the logic app offline because of downstream system issues or updates, upstream systems can continue to work as expected. But how to avoid that in cases like mine – where bulk uploads (initial load or bulk updates) are not expected to flow downstream?

Omitting Empty Elements on JSON Payloads

I am working on a Logic Apps project where the client API validates the elements before saving, and is not expecting null values to come through. For example, in the payload below:

{
	"Email": {
		"StartDate": "21/11/2018",
		"EmailAddress": "randel.menezes@nzhomeloans.co.nz",
		"EmailStatus": "Active"
	},
	"AlternateEmail": {
		"StartDate": "21/11/2018",
		"EmailAddress": null,
		"EmailStatus": "Inactive"
	}
}

It doesn’t expect the data like showed above (which is fair enough), but also don’t like “AlternateEmail”: null. Instead it expects the AlternateEmail element to be dropped from the payload. Trying to do this with logic apps components would make the workflow really hard to maintain later (and to be honest I don’t even sure if I would be able to pull that off with out of the box components like composite and variables).