Rethinking an old Logic App deployment package – part III

Previously in Note to self…

I’ve been discussing how I’ve leveraged Jeff Hollan’s Logic App Template Generator and some PowerShell goodness to export a ARM templates to all Logic Apps in a specific resource group. You can read about that here.

Linking ARM Templates together

Azure Resource Manager templates have the ability to link templates, creating a “parent-child” or “nested” relationship, allowing a single template to deploy resources that are defined in various individual templates. The advantages of this technique in my opinion are:

  • Each resource can be defined in isolation, which makes maintenance of that resource simpler.
  • Related components can be grouped in “parent” templates for a simpler deployment experience, but they can still be deployed individually if required.

This was exactly the type of solution I was looking for, after having to deal with the pain of replacing a logic app template in the middle of a monolithic ARM template containing another 15 templates. That would usually take a couple of hours to make sure that the template was replaced correctly and nothing was removed that would make the deploy to break.Jeff’s project didn’t have this functionality so it was time for my first real contribution on the world of open source.

My plan was to create a new cmdlet, following the existing pattern laid out by the existing Get-LogicAppTemplate cmdlet.

Understanding Linked Templates syntax

In order to replicate programatically a linked template, I needed to understand how a linked template is created. That was where Visual Studio came in handy.

Visual Studio ARM project supports nested templates. To create a new nested template, you just need to right click on resources within the JSON outline and select Add Resource:

Then select Nested Deployment from the list of templates:

This nested deployment is defined like this in the ARM template:

So in the end, the nested template have two main properties:

  • templateLink – this property points to the location where the ARM template for the nested deployment will be found.
  • parametersLink – this property point to the location where the parameters file for the nested deployment will be found.

With that in mind, and a sample empty template, it is time to write the cmdlet.

Creating a new cmdlet

To create a new cmdlet, you need to inherit from the cmdlet class, which exists in the System.Management.Automation namespace.

This class have three virtual operations, that we can override to create the required execution:

  • BeginProcessing – executes once before the cmdlet process records.
  • ProcessRecord – executed for each record passed for the cmdlet.
  • EndProcessing – executes once after the processing is completed.

You can decorate your class to define the verb and name of your cmdlet, and define each parameter, including name, order and if it is mandatory.

For the nested template cmdlet, my assumption were:

  • a resource and its parameter file would be stored in a folder.
  • the two files and the folder would share the name

That assumption seems to follow the format that Visual Studio creates the file – and that is why the Get-RGLogicAppsTemplate script was implemented.

I would also need that once created the first time, the template could be passed as parameter for the next execution, so it could append a resource.

So in the end, the class definition looks like this:

When a new template is being initialized from scratch, the cmdlet would create without the Template parameter, which would make an empty template based on a sample file.

If the Template parameter is populated with an existing resource template, that template will be used for initialization instead, guaranteeing that the next resource would be appended to an existing template. The code for this process can be found in the snippet below. It leverages from the BeginProcessing virtual method:

Because of the assumption that resources and parameters shared the same base name, and were stored in a folder that also share that name, the code only requires the name of the resource to include as a nested deployment. The ProcessRecord method looks like this:

In a nutshell, the code creates a new NestedResourceTemplate object – which is the serialization of a ARM ResourceTemplate element – and include set two properties of this object:

  • an uri pointing to the resource template file,
  • an uri pointing to the resource parameters file

Using the new cmdlet

This cmdlet can be used in two ways. When creating a new linked template from scratch it can be called as:

Where MyResourceFolder is the name of a folder containing the template and paramater files – just like the folder created by Get-RGLogicAppsTemplate script created in the previous post.

If you already a linked template and want to add a nested resource to the list, you can use it as:

In this case $azuredeploytemplate contains a json string representing the current template.

Adding an Empty Parameters File

For completeness, I’ve also created a cmdlet that creates an empty parameter file, so the linked template have an associated parameters file, if any manual additions are required. The code is quite straightforward:

Extending RGLogicAppsTemplate

With two new cmdlets that creates a nested template, it was just a matter of extending RGLogicAppsTemplate script to use the same resource group information and create the top linked template, by adding the following steps:

  • First, we initialize an empty variable to hold the linked template.

  • Then we got a list directories in the $destination folder – which were created in the previous process. For each directory, we append a new entry to the linked template, stored in $azuredeploytemplate.

Finally we save the nested template, and create an empty parameters file.

Next Steps

The final step in this exercise is to try and create a Visual Studio ARM Deployment project. See you next time!


Sharing is caring...

Leave a Reply

Your email address will not be published. Required fields are marked *