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.
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).
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.
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 am still working on an API Manager DR scenario for a client. After automating the backup and restore process, to make sure that the APIM instances are always in sync, I needed to setup Traffic Manager in priority mode to distribute the calls between the main and secondary instances.
Traffic Manager setup seemed quite straightforward. You just need to create a traffic manager endpoint for each API Manager Instance, using the external endpoint.
Creating that for each endpoint should do the trick… Or so I thought. After that setup was complete, testing the endpoint always returned 503, even though access each individual endpoint was returning the correct result.
Today I’ve received a very special email – the renewal of my MVP Award for the period 2018-2019. Those who had received the award before knows how cherished is the moment that you see the email on your inbox.
The best part of the award is the confirmation that what you are doing is been recognized as having an impact on the community – which is the reason why you do the work in the first place. The renewal shows that you didn’t lose steam, but keep going in the right direction.
But it wouldn’t be a post about the MVP Award, without recognizing the support network behind me that gives me the chance to do all the community contribution I do. Continue reading “And the Cycle Starts Again”
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.