Data sources ingest data in different sizes and shapes across on-premises and in the cloud, including product data, historical customer behaviour data, and user data. Enterprise could store these data in data storage services like Azure Blob store, an on-premises SQL Server, Azure SQL Database, and many more. This blog will highlight how users can define pipelines to migrate the unstructured data from different data stores to structured data using the Azure ETL tool, Azure Data Factory.

There is no doubt that organizations have a difficult task to address the current requirements for building and managing APIs, especially if they don’t use tools like API Management. APIs require up-to-date and strong documentation, increased security levels, comprehensive testing, routine versioning, and high-reliability to be appropriately utilized.

There is no doubt that organizations have a difficult task to address the current requirements for building and managing APIs, especially if they don’t use tools like API Management. APIs require up-to-date and strong documentation, increased security levels, comprehensive testing, routine versioning, and high-reliability to be appropriately utilized.

You may be thinking, hey Sandro, what the hell? That is basic information and a straightforward task. Why do you want to write about that? Indeed it is, and you are right that it is an effortless and straightforward operation, at least at first glance. But like most things, nothing is that simple if you look closer. But let me explain better. Let’s imagine that we have an API call MoniorBizTalkPorts.

Due to rapid cloud adoption and with never-ending user requirements, the Azure architecture might become complex and you might eventually lose sight of the overall cloud estate and how it relates to each other. Since the Azure portal was designed in a technology vertical silo and it has near zero application visibility, it is not possible to monitor them as a business application in the Azure portal.

It has been a while since I wrote about this topic. I didn’t finish this blog series for several reasons, and now, one year later, it is the right time to continue this story. In the first part of this blog series, I have explained how you can expose a Logic App in API Management. It is a straightforward and simple process. Microsoft did a great job on this user experience.

Last week, I worked on a POC – how can we dynamically set SQL Server Connector configurations within Logic Apps? – that became a real project and a real architect solution. And one of the critical pieces was Azure App Configuration. Azure App Configuration stores configuration data as key-values.

In the first part of this article, we mention that at the moment, you have three options for you to start developing your Logic Apps: And we already analyze the advantages, disadvantages, and how to start developing Logic Apps by using the Azure Portal and Visual Studio. Today we are going to do the same but this time using Visual Studio Code.

In the first part of this article, we mention that at the moment, you have three options for you to start developing your Logic Apps: And we analyze the advantages, disadvantages, and how to start developing Logic Apps by using the Azure Portal. Today we are going to address. Today we are going to do the same but this time using Visual Studio 2019.

A few weeks ago, my good friend Josh Cook wrote a blog post for Power Automate about getting the error message when implementing the try/catch pattern with a Flow. We discussed if this could be used with Logic Apps, and Josh confirmed that it could, even though the Logic App documentation doesn’t cover it very well. Josh’s original Flow post is- Grabbing an error message from a failed run.