Before we start with the actual post, I’d like to introduce a new brand we will be developing. This is the first official post with the “It’s not Rocket Science!” brand.
With this concept, we intend to explain how some procedures are not as complicated as you may think and that they’re not Rocket science. I’m open to suggestions on posts to demystify Azure Logic Apps and other Azure services.
So, welcome to a new concept and I hope you find it useful.
Azure Functions: Moving from Azure Portal to VS
Creating Functions in Portal presents some challenges, like lack of Intellisense, which, as we know, helps a lot. Not having CI/CD is also a concern and of the worse case scenarios:
Someone deleting you function by mistake!
Panic!, all hell broke loose. I tried to apply the same method as I did with the Logic Apps accidental delete recovery, but the “Change history” tab isn’t available for Functions. You end up losing your code, your executions and maybe some sleep over this.
The obvious next step is to get your backup from your repository and re-create the function. IF you have it in a repo.
We can’t prevent someone deleting our resources, everyone makes mistakes. But you can prevent letting your code sit in Azure Portal without version control, CI/CD and repository control.
So, the best way to do this is to migrate it to a VS solution. In this post, I will use VS2019, but VSCode is also available as others IDEs. You can do this right from the start by choosing another development environment besides the Portal.
With an existing Function, you’ll need a few things before you can migrate it. Besides your VS with an active subscription, you will also need the Azure SDK feature. This can be installed using the Installer you’ve downloaded from MS or in VS itself, in the “Tools”-> “Get Tools and Features” menu.
After a fresh install of Windows, I didn’t installed the Azure SDK, so I had to download it and install. According to the setup, it should take about 6,5GB.
If you had to install the SDK, Updates are also important, keep that in mind.
Lets return to the code.
The good thing about VS is that you don’t need to reference the required DLLs, they will probably already be there.
So you need to create a new Solution, with an Azure Function project.
Small note: you can also create a project using VB instead of C#, but… VB…
You can either choose a template with a trigger already created or you can choose an empty project, but when you try to Add a function, it will ask you again what template you want to use.
You can also add an empty class, but you will be missing some references.
As you can see, there are quite a few differences between the Class and the Function template.
I recommend you use the same template as the one you used to build your function, you will get more references that will be necessary for your code to work.
And now comes the easiest part. You can just copy-paste your code into VS, but leave the usings out. Most likely, if you haven’t used anything outstanding, they will already be there.
Now you have you code in VS, ready to run. Is it working properly? Well, you can just debug it locally, when pressing F5, the Azure emulator will start and you will be able to test your function like it was on the cloud.
You can just use your Postman or another web request tool to test your project.
Once you’ve tested everything and are ready to deploy to your subscription, you’ll need configure the publishing profile.
You have two major ways of doing this. You can choose the blue pill and configure your connection by hand or you take the red pill and download the profile from the existing FA.
My advice, get the publish profile. Saves you time and it’s Plug’n’Play.
And that’s it. Your newly migrated function is now ready for your CI/CD and you can manage and version it with VS and DevOps.
Now, this does have a catch, or not depending on how you look at it. Because we deploy using a Zip file, the code is no longer available in the Portal, you must now always use VS to view it.
I like this, because it means that from a Security perspective, noone will be accessing the source code through the Portal and it forces new Devs, and old ones too, to join the best practices policy and have everything in a proper Repo and version controlled.
Last week, when preparing for a deployment, I bumped into this error again. As from my previous post, it could be easily fixed with a PowerShell module install.
But this time, the script was already fixed. Nothing had changed, as far as I knew. The last build and publish was in September, no errors there.
So what happened that killed my build?
It couldn’t be the Az module updates, because we were forcing the version. There had been several updates, so could this be it?
I tried to force a newer version, like 2.0.0, but still failed to execute the command. I even restricted the script to use only the command I needed, that was the CallbackUrl.
After a few other failures, my thinking was, “this can’t be the problem, the script was executing without issues, so it has to be something else.”
So I took another look at my pipeline. It was the same as before… Azure Powershell task to remove AzureRM, install Az module and Azure CLI task to execute the scri… wait!
Could this be the problem?
I switched the tasks and re-queued the pipeline.
And success! No more errors.
Azure CLI has received some updates in the past weeks, and the build I had before was 2.0.16 (Core 2.11.0) compared to 2.1.0 (Core 2.18.0) was running in these failed pipeline runs.
I looked into the Azure CLI release notes, but found nothing referring the LogicApp commands or Az.LogicApps.
This time, I can’t find a proper explanation for this error, but I’m suspecting some update broke the ability to run these Az module commands with Azure CLI or the Az.LogicApps commands specifically.
Sometimes I have the need to have a Logic App (LA) disabled when I deploy it. For instance, when deploying to Production, I like to have my LAs disabled, because I want to double check everything before starting the process.
This is helpful because usually, when using the “Recurrence” trigger, the LA will start immediately. If for some reason, a connector has the wrong configuration or is broken or the end system is offline, the execution will fail. Other scenarios can happen as well, but that’s another story.
An interesting fact is that you don’t have a proper way to control this in the Portal. You can add the control line to the code, but you won’t be able to control it with CI CD.
So, in comes Rocket science (or not).
The resource code contains a property that will allow you to control the state of a LA and it’s quite easy to set. If you do not specify this property, the LA will start enabled and will trigger if it can.
The property is called “state” and lies within the “properties” node. Setting this property as a global parameter, allows you to prepare your CI/CD pipeline also allowing to parameterize this in your release.
This is quite and easy and simple insert, that should take no more than 5 minutes for you to configure.
If you choose the “Disabled” state, the LA will not start unless you specifically activate it.
Most developers start working with Logic Apps through Azure Portal, because it’s fast and direct. You just open the Portal, create your resource and start working. This is fine but it comes with a cost. There are several limitations to what you can do, specially when it comes to CI/CD (Continuous Integration/Continuous Delivery).
To handle this, there is the need to move to Visual Studio and start working from there. For this to happen, you need tools to help you and there’s a few available. In this post, I will approach a very good one and how to use it.
This tool is a collection of powershell scripts that will download to file your Logic App code and it also can create a parameters file.
The creator of this collection is Jeff Hollan, PM Lead for Microsoft. You can check his work at his GitHub repo. https://github.com/jeffhollan
The project that we’re going to use is LogicAppTemplateCreator. It’s a C# project that creates a DLL and that we will import and use.
I dropped into a Shared folder, because I’ve referenced it in a Repo for other people to consume in our projects, but this is not necessary, although I recommend it so that it becomes easier for future developers in your company.
After executing this, you’ll be ready to download your ARM template. So, get your Resource Group ID, you Subscription ID and prepare an output folder. You will also need to enter your credentials to login by powershell.
The script should be changed according to your IDs. Do note that it should not be case sensitive. If you don’t set the Out-File, the output will be set in the powershell console, you’ll still be able to copy it and paste in a file, but it’s an unnecessary step.
You will now have both files you need to manage your Logic App, so just copy them to your VS Azure Resource Group project, with Logic Apps Template and you’re almost ready to go.
You will need to address the path links in the JSON code to make them CI/CD-able and fix the parameters in some connectors, but there’s not a lot of work to be done.
As you can see, the ARM template already provides all connection parameters and connections variables. I do recommend you changed them to a more appropriate naming convention like “arm_O365”, “arm_SQL” or “arm_ServiceBus”. This way you will know what it’s referring to with a very understandable pattern.
At the end of the day, your Logic App should be ready for deployment in your subscriptions and look something like this:
We’ve all been through it. A few days ago, I accidentally deleted a Logic App when working for a customer.
I was working on migrating from the Portal resources to a Visual Studio solution, because CI/CD is being implemented.
Luckily it was the Dev environment, but still, there was some developments that I hadn’t migrated yet! Hours of work were lost! Or then again, maybe not.
After some research I found out that there’s no way of recovering or rollback a deleted Logic App. There’s some documentation to recover an App Service but no actual mentions to LAs.
Suggestions have been made in Azure Feedback, but so far, no replies.
So, how exactly do you recover a deleted Logic App?
Well, you have to dig a little bit and do some magic, but you will end up with a working Logic App after this.
Let’s work!
First, you must navigate to the Activity Log of your Resource Group.
There, you will find the last operations executed. This may not be easy, in this example I only have a few operations, but in the client tenant, I had to scavenge through a few days of logs.
Once you find the correct deleted workflow AKA Logic App, you open it and check the Change History. This should in preview but it will be life boat.
The “deleted resource” contains the JSON code and it is what we’re looking for. Although it requires a bit of magic dust to clean the data that’s in it, it does contain the most recent code you had. Migrating this to a new Logic App, either in Portal using Code View or in a VS solution, this is the best way to recover your little mistake.
The end result, should look like this:
And your Logic App should be ready to run!
It may not be the best way to get this nor the fastest, but it works and there’s no proper documentation for this. Hopefully, Microsoft will release a more convenient way to get your deleted code.
Here’s two incredible facts: 318576 views were made to my blog last year, being that, the country that most visited was the United States, followed by India, United Kingdom and Sweden. (In 2016, there was 50 new posts, growing the total of this blog to 534 posts) And I had the opportunity, as a speaker, […]
Blog Post by: Sandro Pereira
And the most expected email arrived once again on 1st January, thanks Microsoft for another wonderful start of New Year. Once again, I’m delighted to share that I was renewed as a Microsoft Azure MVP (Microsoft Most Valuable Professional), This is my 7th straight year on the MVP Program, an amazing journey and experience that […] Blog Post by: Sandro Pereira
Oh, is that time of the year?… holiday season is back, and with it the, is time to enjoy and be with those we love most, time to forget the worst that happen and focus in the best and aim new challenges and goals for 2017… never forget your dreams, they can come true, never […] Blog Post by: Sandro Pereira
First of all, Happy birthday BizTalk Server for your 16th birthday! For does you don’ remember, the first version of BizTalk Server was release 12/12/2000, Congratulations!! Continuing with the topic of my last posts “Errors and Warnings, Causes and Solutions”, we will talk about an error that I face today using the BizTalk Server WCF […] Blog Post by: Sandro Pereira
In this blog post we will discuss an Azure
Service called Azure
Functions. This service has recently (15th of November) gone
GA (General Available) and provides a capability of running small pieces of
code in Azure. With functions, you do not have to deal that much with infrastructure,
it’s the responsibility of Azure or an application (see Azure
Functions Overview). The functionality you
