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.
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?
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).
Last week I was reviewing a logic app with one of the lead developers at Theta. It was a relatively simple logic app. It needed to call an oData endpoint on a regular basis, and process the value back. The developer original design was to:
Poll the oData endpoint on the agreed interval.
Test if the value array length was bigger then zero
If the array was larger than zero, process each value in the array within a for each.
Else, terminate the instance as cancelled, so he could distinguish between real executions and zero-length polls.
That would work, but if felt wrong for a couple of reason.
The logic app was wasting an action to test if the actual logic would be executed or not.
Another action was being wasted just to tag the logic apps that didn’t actually “fired”.
Then it dawn on me that we should be using splitOn instead. This would avoid the check, Setting up the splitOn is as simple as adding this on your trigger:
This is a cautionary tale…A month or so ago, someone from support asked me why the hell a test environment had spent over a thousand NZD in Logic Apps actions. My first reaction was “Are you kidding?”… my second reaction was that pit in your stomach feeling when you know something is really wrong, but you don’t know why.
Have you ever created a logic apps solution – maybe 10 or so logic apps – and noticed that you needed to enable basic notification alerts for all of them? I found a while ago that this was kind of a tedious process, so I end up creating a PowerShell script for that. I end up forgetting that I never blogged about that, so here it goes.
I’ve been working during the last week or so on setting up a DR strategy for a solution that is based on API Management, Azure Functions and Service Bus. Most of the deployment to the secondary site is dealt by VSTS, but one of the main issues on the proposed strategy was the fact that APIM instance utilized is Standard, which doesn’t allow multi-region deployments. This way, to guarantee that all APIM configuration, including users, API policies and subscriptions, I had to leverage from the backup/restore functionality available in APIM, based on the Management API.
Recently I’ve presented at Directions ASIA 2018 with my good friend and MVP Tharanga Chandrasekara, and I’ve been exposed to a “new world” – the Business Solutions world! Coming from and enterprise integration background, I usually tend to gravitate around the enterprise integration tools and lately iPaaS offering, so my initial reaction to integration will always be BizTalk Server / Logic Apps. But Microsoft Flow had evolved to be quite a reasonable option – and I would say probably the first option for integration within the Office 365 / Dynamics 365 consultants, since it gives you almost the same level of functionality that Logic Apps would give – no surprises here, since behind the scenes they are actually the same engine. Continue reading “Logic Apps x Microsoft Flow – which one should I choose?”
Have you ever wanted to stop all logic apps in a resource group in one go – either for production maintenance, or maybe because that set of logic apps in a resource group is eating all your resources? If so, welcome to the club… What you probably found is that there is no way to do this in the portal. Coming from a BizTalk background where you can stop all orchestration – or even the whole application) with a right click, in some cases you will ask “Why?”, while in others you might shout “Khaaaannn!” (I know I probably did both). Continue reading “Enable/disable all logic apps in a resource group”
When it comes to developing Logic Apps, everyone has a preference. Some people like to develop in the portal, while others like to start development directly from Visual Studio. I am in the first group mainly because a lot of my logic apps involves integration with the Dynamics 365 CRM connector, which doesn’t play well with the Logic Apps editor after I apply the required parameterization (which reminds me that I have to blog about that – will write something about it soon). I also like the simplicity of just opening the browser and be able to develop, debug all in one go.