This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Parameterizing Managed Connections with Logic Apps Standard

Introduction

Logic Apps Standard introduces a resource structure that can host multiple workflows within the same application. With a one-to-many mapping, workflows in the same logic app and tenant share computing and processing resources, providing better performance due to their proximity. This model also simplifies deployment of logic apps, with a stronger separation of concerns between the infrastructure – the Logic App Standard app, associated App Service plans, storage repositories – and the groups of workflows that are executed under the app, simplifying the process of deployment automation for Logic Apps, as customer can follow practices that they already using for similar resources like Web Apps and Azure Functions.

One of the common activities when getting Logic Apps Standard ready for a DevOps pipeline is to parametrize values that can change between environments, like environment specific variables and connection references.

While environment specific variables could be easily achieved by the combination of workflow parameters and app settings, connection reference could be hard to achieve. Connection references usually have a combination of common values which are environment specific - subscription IDs, resource groups names, for example- that must be combined with fixed values that are the same in each environment – connector type, connector name – to create a specific path or identifier. This interpolation was not available until now.

With the latest update of the logic apps extension (starting on version 1.0.40) parametrization of the Logic Apps Standard apps becomes easier, as now both runtime and designer support the interpolation of app settings or parameter references. This simplifies the management of those files.

Anatomy of an Azure Managed connection reference in connections.json

A typical Azure Managed connection reference generated by the Logic Apps’ designer looks like this:

The snippet below is an example of a connection to azurequeues (with subscription id obfuscated):

Common application settings

For new managed connections to be available in VS Code, you must provide a resource group where the logic app will deploy those connections. This is done by selecting the “Use Connections from Azure” in the context menu of any workflow. This process only needs to be done once. By the time this is done, the following entries are added in the local.app.settings:

As an example, after selecting “Use Connections from Azure” and provide the value, you will find those items in your local.appsettings.json file:

    "WORKFLOWS_TENANT_ID": "********-****-****-****-************",
    "WORKFLOWS_SUBSCRIPTION_ID": "********-****-****-****-************",
    "WORKFLOWS_RESOURCE_GROUP_NAME": " myresourcegroup",
    "WORKFLOWS_LOCATION_NAME": "australiaeast",
    "WORKFLOWS_MANAGEMENT_BASE_URI": "https://management.azure.com/",

Why is this important? Because since those values are going to be available, anyway, we can use them to parameterize the connections, instead of trying to create new parameters for the same values.

Parameterizing existing connections

To configure an existing managed connection created in connections.json with the values that can be easily replaced between environments, replace the following values in the connection with values from app settings:

connectionRuntimeURL can’t be parameterized like the items below, but should be moved to parameters.json, so you can have a different value per environment without having to change connections.json

Make sure that you include the following new parameter:

For deployments in other environments, the connectionRuntimeUrl can be obtained as an output of the ARM template that deploys the connection. You can use this to automate the update of parameters.json. You can refer to this article to find more about how to capture connectionRuntimeUrl as an output from the ARM template execution.

Finally, the last value that you should parameterize is connection/authentication. Moving the whole object to parameters allow you to still store the authentication key in appsettings, but most importantly, allow you to replace the whole authentication type between local and cloud, as in the cloud, the value should be set to manage identity.

Make sure that you include the following new parameter:

When deploying to the cloud, the logic apps that will host this code should be given permission to access the connection via its managed identity, and this parameter should change to indicate managed identity as the authentication scheme:

This change in the authentication type is important for cloud deployments, as Raw authentication keys are only valid for 7 days. Locally, the designer in VS Code renews the raw authentication token every time that the logic app is saved. This behavior doesn't happen in the cloud, as connections created in the cloud take advantage of the managed identity. Also, notice that if a connection deployed to the cloud via ARM template, the template should also allow the logic app managed identity to access that connection.

After all the changes, your connection should look like this:

Your parameters file should include the following parameters:

Once those changes are made, both runtime and designer will be able to parse the connections, and the connection.json file doesn’t need to change between environments, even if you have a different connection across each environment.

Parameters.json might still need changes when deploying across environments, since you should change the authentication type and the connectionRuntimeUrl.