Arin's Tech Musings

A lot of us would already be familiar with Azure API Management and might already be using it extensively as a gateway for our backend services. "API Management (APIM) is a way to create consistent and modern API gateways for existing back-end services. You can use Azure API Management to take any backend and launch a full-fledged API program based on it." -  Official Microsoft Documentation It is fairly easy to set-up and get started. But then over time, when the backend services or API goes through evolution, arises the need to have continuity while at the same time being able to make available updated APIs and/or backend services. If you are not familiar with Azure API Management, I recommend reading the Official Microsoft Documentation . Microsoft announced the public preview of "Versions and Revisions in Azure API Management" on September 14, 2017. 3 years later, I see that there are still quite some questions on the effective use of these features in a lot of

For those that have been working with conversational interfaces namely bots, both developers and business users, have at some point come across the term transcript. So what is a " bot transcript file "? According to docs.microsoft.com, "A bot transcript file is a specialized JSON file that preserves the interactions between a user and your bot. A transcript file preserves not only the contents of a message, but also interaction details such as the user id, channel id, channel type, channel capabilities, time of the interaction, etc. All of this information can then be used to help find and resolve issues when testing or debugging your bot." If we look closely at this definition, we can see that a transcript is much more than just contents of messages exchanged between user and bot. It contains a lot more information in it's raw form. Thereby, it is quite evident that a transcript has use for both business users and developers. How can a business user use

In Part 1  we had covered the topics of understanding Azure Service Principals and how to create them. In this part we will look at using the Service Principals in a secure manner when creating Azure Automation Runbooks and carrying out AzureRM tasks. We will not get into the details of how to create a automation account in Azure. It is very simple to follow the Microsoft Docs  to create an automation account and also learn how to create a runbook and schedule it. We will now focus on the how-to of using an Azure Service Principal in our PowerShell script. In this example we will use the Password-based Service Principal for simplicity. Maybe I'll create another post for the certificate based service principal in a later update. Note: The Service Principal can be used as any other account in Azure. So, you can use it with RBAC across Resource Groups/Resources as might be necessary. Go to your Automation Account resource and scroll down to find "Credentials" in t