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.
A while ago, I was involved in a project that needed to push messages to a Kafka topic. I found that while the .NET code required for that implementation was relatively straight-forward – thanks to the Confluent’s .NET client for Kafka – configuring the server was a nightmare. The IT team at the client site was supposed to get the kafka cluster sorted and dragged the issue for a month or so. And I understood why when I tried to setup a cluster myself – configuring a kafka cluster is not a walk in the park. If only we had a managed, one click solution to implement a event streaming solution, based on kafka protocol… 😀
When Microsoft announced last month Event Hubs support for the Kafka protocol – I thought that a great way to prove that this was really interoperable, was to use part of the original code I wrote and see if I could connect to Event Hubs without any significant changes. And I was pleasantly surprised! The only changes required was some additions to the producer/consumer configuration. This post shows how I managed to get this working, and show one of the main gotchas I found along the way. Continue reading “Acessing Event Hubs with Confluent Kafka Library”
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?”