Parameterized use of the HTTP Action in Logic Apps

When developing with Logic Apps there is a question of how to manage parameterization of properties for the HTTP action when you need to change settings like the url when moving to different environments.

There are a few different things you can do but I thought id walk through the approach I like.

Starting Point

Lets start by considering the below HTTP action where we are calling the url to load some data. You can see the uri property is going to change as we deploy the logic app to different environments.

"HTTP_-_Get_Data_from_MyAPI": {
              "type": "Http",
              "inputs": {
                "method": "GET",
                "uri": "https://myapi.com/acme/myapplication/data",
                "headers": {
                }
              },
              "runAfter": {
              },
              "description": ""
            },

Step 1 - Define Parameter on the Logic App

The first step is I will define a parameter on the definition of my Logic App. In this case I am specifying a parameter of type object. This will let me have multiple properties on the object which I find useful if you need to supply more than just the host for it. You can see in the picture below but also be careful to set the definition of the parameter under the definition node. There is also a parameters node as a child under the resource node which is not for defining the parameter.

Step 2 - Pass the parameter to the Logic App

Next up I will supply the values for the parameter. I have put the parameter under the resources/parameters node as you can see in the picture below. Remember that we defined a parameter of type object so we can supply multiple properties if we want to. In this case I have a property called Host which I have specified to have the value of an ARM parameter. This is where you need to understand the difference between a logic app parameter and an ARM parameter. The logic app parameter will show up under the parameters menu on the edit logic app screen in the Azure Portal and allows you to reference a reusable parameter in your definition. The ARM parameter is something that is set at deployment time when deploying the logic app. In this case I will take the value from my ARM parameter (more on this later) and inject it into the host property on my logic app parameter when the logic app is deployed.

One point to note, to help me easily see if a parameter is an ARM or Logic App parameter I usually prefix their name with p_ for Logic apps parameters and arm_ for ARM parameters.

Step 3 - Define the ARM Parameter

Next up we have the ARM parameter. You can see below I have specified an ARM parameter in the normal way and given it a default value. I can override this value when deploying from Visual Studio or can override it from an Azure DevOps pipeline with a pipeline variable per environment or something like that.

Step 4 - Modify HTTP Action

Finally I need to modify the HTTP action. You can see below in the picture that I have referenced the logic app parameter and then also used a constant value for the rest of the full uri

This makes it really easy to have an easily repeatable way to specify values in the HTTP action that can be replaced per environment. I can use this approach for headers and other properties on the action. You could even use it for the auth settings too but you are probably better off reading these from KeyVault for sensitive settings.

Other Tips

Normally I will have a url where only the host changes which I can do with templating the uri property like below.

"uri": "@{parameters('p_MyAPI')['Host']}/acme/myapplication/data",

Sometimes more than the host changes so you could even replace the entire uri if you wanted and inject the whole thing in at runtime and just use different properties on the p_MyAPI parameter object we defined.

"uri": "@{parameters('p_MyAPI')['FullUrl']}",

Code Snippets

If you want code snippets for the above to help you copy and paste anything, below is the definition

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {    
    "arm_MyAPIHost": {
      "defaultValue": "https://myapi.com",
      "type": "string"
    }
  },
  "resources": [
    {
      "name": "MyLogicApp",
      "type": "Microsoft.Logic/workflows",
      "location": "westus2",
      "tags": {
        "displayName": "MyLogicApp"
      },
      "apiVersion": "2016-06-01",
      "properties": {

        "definition": {
          "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
          "actions": {
            "HTTP_-_Get_Data_from_MyAPI": {
              "type": "Http",
              "inputs": {
                "method": "GET",
                "uri": "@{parameters('p_MyAPI')['Host']}/acme/myapplication/data",
                "headers": {
                }
              },
              "runAfter": {
              },
              "description": ""
            }
          },
          "parameters": {
            "p_MyAPI": {
              "defaultValue": {},
              "type": "Object"
            }
          },
          "triggers": {
            "Recurrence": {
              "type": "Recurrence",
              "recurrence": {
                "frequency": "Minute",
                "interval": 60
              },
              "description": "The recurrence trigger will kick off the process.  We will use the single instance options to only run 1 of these at a time",
              "runtimeConfiguration": {
                "concurrency": {
                  "runs": 1
                }
              }
            }
          },
          "contentVersion": "1.0.0.0",
          "outputs": {}
        },
        "parameters": {
          "p_MyAPI": {
            "value": {
              "Host": "[parameters('arm_MyAPIHost')]"
            }
          }
        }        
      },
      "dependsOn": []
    }
  ],
  "outputs": {}
}