Hey everyone! It’s been a while right? The only thing I have to say in my defense is that the last 5 months have been crazy with travel, presentations and lots of work, so I couldn’t get myself to create a good blog post. But enough of excuses already… Remember the “lots of work” part? That involved working with different clients, and a common theme among many of those clients was the implementation of a centralized API layer, tho expose the back services they were creating. That meant that I had to find a good way to automate the publishing of the APIs created in API Management across the different environments. Previously, I’ve relied on the fantastic work that Mattias Logdberg did with the API Management ARM Template Creator (which is also worth a look). But now that Microsoft had some official guidance for that extraction, I decided to have a go with it.Continue reading “Automating API Management CI/CD with APIM DevOps Resource Kit”
It is the night of the first day of 2019. After 10 days camping and a whole day yesterday organizing the house, I was keen on a quiet night instead of partying on New Year’s Eve.
So the kids went to bed and me and my wife were just waiting to see the new year starting, I’ve thought that was a good time to reflect back on my achievements of 2018 and say thanks to a big supporting network that made them possible. That’s how this post started, in the last day of the year…Continue reading “Looking back on 2018”
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.Continue reading “Logic App Trigger Conditions”
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?Continue reading “Resetting the State of a Logic App Trigger”
And we did it again! Me and Blanca Mansfield, which run a Python Code Club at the school, ran the Hour of Code 2018 at Arahoe Primary School, working with all classes from Year 3 to Year 6. It is the second time that we run the event at the school.
We’ve managed to do it in 2 days working with different groups of students ranging from 7 to 11 years old. The groups ranged from all year 6 students at once (60 or 70 of them) all the way to a single class of year 3 students. The lessons from last year made the organization much easier, so I didn’t need to prepare as much as I had last year.Continue reading “Hour of Code 2018”
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:
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).Continue reading “Omitting Empty Elements on JSON Payloads”
As you might remember, in June I was at the Integrate 2018, doing a presentation called Exposing BizTalk to the World. It was my second time presenting on what became the premier conference on Microsoft Integration and it was a fantastic experience. It wouldn’t be fair to talk about Integrate without thanking Theta for sponsoring my trip and time of work and BizTalk360 for organizing a great event.
But why am I talking about this almost four months later? Apart from the shameless plug, during that presentation suggested a couple of ways to expose BizTalk endpoints. One of the options was using API Management to expose BizTalk receive locations, and the other was using Azure Relay to bypass firewall and securely expose BizTalk endpoints.
A couple of weeks ago, I’ve actually combine both technologies to securely expose a BizTalk endpoint. On this scenario, the client needed to create an API that would be exposed to partners, but wanted to reuse a series of BizTalk processes that were already implemented. As this was a pilot that should highlight the agility and fast time to market that can be achieved with the cloud, we didn’t have time to go through the process of exposing their environment through the firewall and whitelist API Management. Continue reading “Combining API Management with Azure Relays”
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.Continue reading “Treat every Logic App environment as production”
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.