wsilveiranz

Event Grid Advanced Filtering on Logic Apps

“It was the week before Christmas, and…” and I was actually super busy! One of my main tasks on that week was to implement notifications when a legacy Dynamics AX, still running on-premises, had orders ready to delivery.

My solution was relatively simple (although needed to be generic enough to include other notifications later):

I had a very simple event data being provided by the notification repository:

{
  "NotificationId": "NOT-00001",
  "NotificationType": "SalesOrder.Delivery",
  "CustomerId": "CUST-001",
  "Status": "New",
  "LastModifiedDateTime": "2019-12-20T11:02:28.13"
}

I thought that it was quite an easy setup, but I got stuck for a while setting up the Event Grid Logic App trigger. Why? I was expecting that the trigger would support advanced filters out of the box, on the designer experience, but that’s not the case.

API Management – Arc Enabled

API Management what enabled? If you haven’t keeping up with the news from MS Ignite 2019, the title might be a bit confusing. Arc (not A.R.C as I read it initially) is a new Service in Azure that allow customer to deploy and manage Azure Services anywhere – and anywhere in this case means any cloud, on-premises infrastructure and at the edge. You can find more about that service here.

During MS Ignite, the API Management team launched the public preview of a new feature, that takes advantage of the Arc technology to deploy API Management gateways anywhere. So let’s take a look of what that looks like.

I know what you did on your holiday…

Today is officially the last day of my holiday in Brazil with the whole family. We spent four weeks between mine and my wife’s home city, visited family and friend, visited some places that I haven’t before even living in the state most of my life and showed the kids some of our favorite spots.

But I also wrote a blog post, submitted five talks to Ignite, participated in to MVP calls, had a couple of meetings with people at work, replied to my work email to prevent projects go the wrong way.

So, at the end of the trip, I started thinking… With so much focus on quality time and really unplugging during your holiday, this days, should I have done that? Did I really enjoyed this trip as much as I should have?

Managing personal office communication with MS Flow

It’s 10:00 am of a Wednesday and I am in my childhood home, having a chat with my dad and spending some time relaxing. As it is raining today, beach is not an option, and cinema is scheduled for later today.

So what better to pass the time until later than write a light post? So, instead of focusing on AIS or some “enterprise like” technology, I decided to talk about something I made to make my life simpler, using Microsoft Flow, Teams and Outlook – my ultimate out of office communication.

The requirements

For a bit of background, at Theta we had a long time tradition to indicate people whereabouts on email using a tag like OUT (out in a client), WFH (working from home), etc. That came from the time where the team was quite small and email was the main method of communication. With the team growing, earlier this year we made a request for people to move that kind of notification to Teams, on Theta’s General channel. But then I thought – why do I have to connect to teams to do that every time? There should be a better way…

In the end, the better way for me was a Flow button that allowed me to decide exactly what I wanted to do – I designed the flow to do the following:

Choose the type of notification I wanted to send:
- Out of Office (OUT)
- Working from Home (WFH)
- Sick Leave (SICK)
- Late to Work (LATE)
Have an optional text explaining the reason for the notification
Send an email to my manager indicating my whereabouts.
- Optionally, send a copy of the email I send to my manager to a list of people I chose.
Optionally, turn on automatic replies and adjust the text and the duration of the automatic replies.

API call with client certificate policy failing to execute due to message size on Azure API Management

Well, that is a mouthful of a title, but I wanted to capture the exact issue, because I couldn’t find any page to help with this specific error and managed to get it fixed thanks to Vladimir Vinogradsky pointing me out to a tip in one of the APIM docs.

So my scenario was this: my team was working on an API that is protected with a client certificate policy – quite simple, very straightforward. At the API level it had the following policy:

Integrate 2019 in Review

I was on my flight back from London, returning from Integrate 2019, when I started this blog post. It was a very long flight, around 24 hours each way, but even if the jetlag hit me really hard this time around, it wsa worth it. Integrate grew from an initiative from a group of BizTalk MVPs, into the premier conference for Microsoft Integration technologies. It was my honour to be a presenter for the third year in a row, presenting alongside a Microsoft team comprised of Product Managers, Architects and Engineers – the people that actually design and implement the technologies I use on a daily basis – and legends from the Microsoft Integration community like Sandro Pereira, Steefan Wiggers, Richard Seroter, Michael Stephenson and Kent Weare, just to name a few.

The conference is run by Kovai Co – the company formerly known as BizTalk 360 – as a very well oiled machine. A large team from Kovai dedicate months ahead preparing the conference. This edition of Integrate was the largest yet, with over 480 participants, with 26 speakers and 28 sessions, across 3 days.

If I had to choose one theme from the conference this year, would be governance. Seems like most of the integration related technologies got to a stage where the core set of features are available and companies are using them actively. All that activity highlighted the requirement for better tooling and guidance around various aspects of the governance of the platform. From DevOps guidance to security and bettern integration between on-premises and the cloud, pretty much every product group had recent or new announcements around that theme.

Automating API Management CI/CD with APIM DevOps Resource Kit

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.

Looking back on 2018

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…

Logic App Trigger Conditions

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.

Resetting the State of a Logic App Trigger

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?