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.
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”
Last June I was one of the presenters at Integrate 2017. And man, I had a blast! Can’t thank enough Theta for sponsoring me going to the event, and Biztalk360 for having me as presenter. It was an amazing experience…
Today the video of my presentation has been published. So go check it out and also check out the amazing presentations on this year’s edition.
A while ago I saw a question in the forums where someone was trying to use a POST operation using the API Management action in Logic Apps and the action card didn’t have any way to input the body object.
I got one step closer to my goal to export all logic apps from a resource group to a Visual Studio project, using linked templates to deploy all logic apps in one when required, but still being able to deploy individual logic apps for a patch template. In previous posts, I’ve managed to use the extend a open source component originally created by Jeff Hollan and maintained by Mattias Lögdberg, adding a couple of extra cmdlets. You can get the last post here.
Visual Studio ARM Deployment Project
For the last step in this process, I needed to create an Azure Resource Manager deployment project. I decided to go through the most pragmatic route – to use an existing project as template. So as a first step, I created an empty Azure Resource Group VS project and tried to find out how artefacts can be associated to it. Continue reading “Rethinking an old Logic App deployment package- part IV”
I’ve been discussing how I’ve leveraged Jeff Hollan’s Logic App Template Generator and some PowerShell goodness to export a ARM templates to all Logic Apps in a specific resource group. You can read about that here.
Linking ARM Templates together
Azure Resource Manager templates have the ability to link templates, creating a “parent-child” or “nested” relationship, allowing a single template to deploy resources that are defined in various individual templates. The advantages of this technique in my opinion are:
Each resource can be defined in isolation, which makes maintenance of that resource simpler.
Related components can be grouped in “parent” templates for a simpler deployment experience, but they can still be deployed individually if required.
This was exactly the type of solution I was looking for, after having to deal with the pain of replacing a logic app template in the middle of a monolithic ARM template containing another 15 templates. That would usually take a couple of hours to make sure that the template was replaced correctly and nothing was removed that would make the deploy to break. Continue reading “Rethinking an old Logic App deployment package – part III”