Pragmatic Approach to Configuring Logic App Parameters

When you are developing logic app solutions, probably the biggest challenge is how to manage and configure the settings and parameters for the deployment of the Logic Apps to support each of the environments. The good thing is that Logic Apps and ARM templates are very configurable, and probably this highly configurable opportunity is also a problem in that it can make the configuration overly complex and difficult to workout what is the best approach to manage the configuration for all of your needs.

There are a few different ways that this problem can be addressed but I wanted to make some notes on what I think is a pragmatic approach which works well and isnt a big overhead but is also easy to maintain and troubleshoot when things arent working correctly.

First off lets consider the types of configuration settings you need to think about. There are.

• Solution Specific Settings
  Solution specific settings are as the name says, settings that only apply to your interface/logic app. It might be the name of a queue, the name of a blog or something similar. The key thing is only your interface cares about this.

• Common Settings
  Common settings are ones that multiple interfaces will care about. An example might be settings for your SAP environment, a URL for an API used my multiple interfaces.

• Secret Settings
  Secret settings are those which you want to keep secret and not have easily accessible or protect completely in some cases.

Now when it comes to handling these settings, its easy to get something working on my machine, but we also need to make sure it works on other developers machines when they get the code from a repo, we also need to make sure it works on build and release pipelines.

Common Pitfalls

Some of the common things I find that dont work well are:

• Not considering shared settings
  If you dont have a good approach and identification of shared settings then you can have the problem where one of your end systems changes and you have loads of places in different interfaces which need their settings changed. If you change System A host to a different server and there are 10 logic apps all servicing System A then you may need to change multiple settings in all of them. Having a shared approach for common config settings can make this much easier.

• Not protecting secrets
  Having hard coded secrets in files in the repo has obvious security problems.

Developer Machine

The below video will walk through how I like to do this on the development machine.

Build Pipeline with DevOps Library

The below video will show how I like to do this in a devops pipeline using the library feature for common settings.

Build Pipeline with App Config

The below video will show how I like to do this in a devops pipeline using the App Config feature for common settings.

Points to Note

Below are a few points to note:

Should I choose App Config or Library for Common Settings?

This is an interesting choice, I have mainly used the DevOps library for common settings in the pipelines and App Config only for the development machine. This is mainly a historical decision where we started before App Config was really a thing and the integration with App Config wasnt that easy to use to begin with.

Longer term I expect that App Config supports better features so I might be likely to move to that. This would bring up the question however about having 1 App Config instance per environment or 1 shared one. Also if developers should or shouldnt have access to settings for non development settings. There are a few things to consider here.

I think whichever way you do it, you can make it work ok and there is not a huge effort to move from one to the other. They really just end up as variables in your pipeline.

Why not use Key Vault Reference in the Build Pipeline

The key vault reference works great on the developer machine so the dev doesnt need to know these settings and it can certainly work on the devops pipeline too but I like having control in the pipeline about the keyvault bit and not having all of the code bases tied to a keyvault incase i need to change anything. The approach we use here lets you change your keyvault and only the pipeline is affected and no change to the repo is required.

Also one of the handy things is sometimes you might get a deployment pipeline that keeps getting errors that are hard to troubleshoot. You can use publish tasks to get the files with the ARM templates in them as artifacts that you can download locally to troubleshoot and they will look exactly as they would have been deployed.

DevOps ARM Task override parameters

I have found these to be occasionally troublesome and difficult to troubleshoot so i tend to not use these. Its really too much time spent trying to workout why a pipeline was getting errors and it ending up being something to do with parameters not being right here that was difficult to find to I think the way above has just been more reliable in my experience.

Things id like

One thing id like to see would be if the product team for App Config/ARM would support connecting to App Config like we do for Key Vault with a reference so that i dont need the powershell script at all. That would be awesome! It doesnt seem to be there yet but until then this will do.

Powershell Script

Below is the Powershell script I used in the videos if anyone wants it

#When running make sure to connect to Azure CLI and Powershell to Azure using below
#You can then run the script repeatedly

#az login
#az account set --subscription "[My Subscription]"


#Use Connect-AzAccount to connect to Azure in Powershell before running this
#Connect-AzAccount

$subscriptionId = '[Sub ID]'
$deploymentName = '[Deployment Name]' 
$location = 'northeurope'
$resourceGroupName = '[Resource Group Name]'
$myAppConfig = '[App Config Name]'

Set-AzContext -SubscriptionId $subscriptionId

$currentDirectory = $PSScriptRoot
$TemplateFile = $currentDirectory + '\LogicApp.json'
$TemplateParametersFile = $currentDirectory + '\LogicApp.parameters.json'
$TemplateParametersFileDevelopment = $currentDirectory + '\LogicApp.parameters.dev.json'

#Get the app config settings
Write-Host ' Getting Keys from App Config'
$json = az appconfig kv list -n $myAppConfig
$configJsonText = $json | ConvertFrom-Json 

#Get the parameters file ready to replace settings
$fileContent = Get-Content -Path $TemplateParametersFile

#Replace the App Config Settings in the parameters file
Write-Host 'Updating settings to produce developer parameters file'
foreach($configEntry in $configJsonText){

    Write-Host 'Config Key: ' $configEntry.key
    Write-Host 'Config Value:' $configEntry.value

    $configTag = '__' + $configEntry.key + '__'
    
    $fileContent = $fileContent.Replace($configTag, $configEntry.value)        
}

#Output New Parameters file for Dev Deployment
Set-Content -Path $TemplateParametersFileDevelopment -Value $fileContent

#Do Logic App Deployment
Write-Host 'Deploying Logic Apps'
$deploymentStartDate = Get-Date -Format "yyyyMMddHHmmss"
$deploymentFullName = $deploymentName + '_' + $deploymentStartDate
New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateFile $TemplateFile -TemplateParameterFile $TemplateParametersFileDevelopment -Name $deploymentFullName -SkipTemplateParameterPrompt