แก้ไข

แชร์ผ่าน

Create and deploy single-tenant based logic app workflows with Azure Arc-enabled Logic Apps (Preview)

  • บทความ

Note

This capability is in preview and is subject to the Supplemental Terms of Use for Microsoft Azure Previews.

With Azure Arc-enabled Logic Apps, you can create and deploy single-tenant based logic app workflows to a Kubernetes infrastructure that you operate and manage. Your logic apps run in a custom location that is mapped to an Azure Arc-enabled Kubernetes cluster where you installed and enabled the Azure App Service platform extensions bundle.

For example, this cluster can be Azure Kubernetes Service, bare-metal Kubernetes, or another setup. The extensions bundle enables you to run platform services such as Azure Logic Apps, Azure App Service, and Azure Functions on your Kubernetes cluster.

For more information, review the following documentation:

Prerequisites

This section describes the common prerequisites across all the approaches and tools that you can use to create and deploy your logic app workflows. Tool-specific prerequisites appear along with their corresponding steps.

  • An Azure account with an active subscription. If you don't have an Azure subscription, create a free account.

  • A Kubernetes environment with an Azure Arc-enabled Kubernetes cluster and custom location where you can host and run Azure Logic Apps, Azure App Service, and Azure Functions.

    Important

    Make sure that you use the same resource location for your Kubernetes environment, custom location, and logic app.

    When you create the App Service bundle extension on your Kubernetes cluster, you can change the default scaling behavior for running your logic app workflows. When you create the extension by using the Azure CLI command, az k8s-extension create, make sure to include the configuration setting, keda.enabled=true:

    az k8s-extension create {other-command-options} --configuration-settings "keda.enabled=true"

    For more information, review the following documentation:

  • Your own Microsoft Entra identity

    If your workflows need to use any Azure-hosted connections, such as Office 365 Outlook or Azure Storage, your logic app must use a Microsoft Entra identity for authentication. Azure Arc-enabled Logic Apps can run on any infrastructure but requires an identity that has permissions to use Azure-hosted connections. To set up this identity, create an app registration in Microsoft Entra ID that your logic app uses as the required identity.

    Note

    Managed identity support is currently unavailable for Azure Arc-enabled Logic Apps.

    To create a Microsoft Entra app registration using the Azure CLI, follow these steps:

    1. Create an app registration by using the az ad sp create command.

    2. To review all the details, run the az ad sp show command.

    3. From the output of both commands, find and save the client ID, object ID, tenant ID, and client secret values, which you need to keep for later use.

    To create a Microsoft Entra app registration using the Azure portal, follow these steps:

    1. Create a new Microsoft Entra app registration by using the Azure portal.

    2. After creation finishes, find the new app registration in the portal.

    3. On the registration menu, select Overview, and save the client ID, tenant ID, and client secret values.

    4. To find the object ID, next to the Managed application in local directory field, select the name for your app registration. From the properties view, copy the object ID.

Create and deploy logic apps

Based on whether you want to use Azure CLI or Visual Studio Code, select the matching tab to review the specific prerequisites and steps.

Before you start, you need to have the following items:

Check environment and CLI version

  1. Sign in to the Azure portal. Check that your subscription is active by running the following command:

    az login

  2. Check your version of the Azure CLI in a terminal or command window by running the following command:

    az --version

    For the latest version, see the latest release notes.

  3. If you don't have the latest version, update your installation by following the installation guide for your operating system or platform.

Install Azure Logic Apps (Standard) extension for Azure CLI

Install the preview single-tenant Azure Logic Apps (Standard) extension for Azure CLI by running the following command:

az extension add --yes --source "https://aka.ms/logicapp-latest-py2.py3-none-any.whl"

Create resource group

If you don't already have a resource group for your logic app, create the group by running the command, az group create. Unless you already set a default subscription for your Azure account, make sure to use the --subscription parameter with your subscription name or identifier. Otherwise, you don't have to use the --subscription parameter.

Tip

To set a default subscription, run the following command, and replace MySubscription with your subscription name or identifier.

az account set --subscription MySubscription

For example, the following command creates a resource group named MyResourceGroupName using the Azure subscription named MySubscription in the location eastus:

az group create --name MyResourceGroupName 
   --subscription MySubscription 
   --location eastus

If your resource group is successfully created, the output shows the provisioningState as Succeeded:

<...>
   "name": "testResourceGroup",
   "properties": {
      "provisioningState": "Succeeded"
    },
<...>

Create logic app

To create an Azure Arc-enabled logic app, run the command, az logicapp create, with the following required parameters. The resource locations for your logic app, custom location, and Kubernetes environment must all be the same.

Parameters Description
--name -n A unique name for your logic app
--resource-group -g The name of the resource group where you want to create your logic app. If you don't have one to use, create a resource group.
--storage-account -s The storage account to use with your logic app. For storage accounts in the same resource group, use a string value. For storage accounts in a different resource group, use a resource ID. 
az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation

To create an Azure Arc-enabled logic app using a private Azure Container Registry (ACR) image, run the command, az logicapp create, with the following required parameters:

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation 
   --deployment-container-image-name myacr.azurecr.io/myimage:tag
   --docker-registry-server-password MyPassword 
   --docker-registry-server-user MyUsername

Show logic app details

To show details about your Azure Arc-enabled logic app, run the command, az logicapp show, with the following required parameters:

az logicapp show --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Deploy logic app

To deploy your Azure Arc-enabled logic app using Azure App Service's Kudu zip deployment, run the command, az logicapp deployment source config-zip, with the following required parameters:

Important

Make sure that your zip file contains your project's artifacts at the root level. These artifacts include all workflow folders, configuration files such as host.json, connections.json, and any other related files. Don't add any extra folders nor put any artifacts into folders that don't already exist in your project structure. For example, this list shows an example MyBuildArtifacts.zip file structure:

MyStatefulWorkflow1-Folder
MyStatefulWorkflow2-Folder
connections.json
host.json

az logicapp deployment source config-zip --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --src MyBuildArtifact.zip

Start logic app

To start your Azure Arc-enabled logic app, run the command, az logicapp start, with the following required parameters:

az logicapp start --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Stop logic app

To stop your Azure Arc-enabled logic app, run the command, az logicapp stop, with the following required parameters:

az logicapp stop --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Restart logic app

To restart your Azure Arc-enabled logic app, run the command, az logicapp restart, with the following required parameters:

az logicapp restart --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Delete logic app

To delete your Azure Arc-enabled logic app, run the command, az logicapp delete, with the following required parameters:

az logicapp delete --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Set up connection authentication

Currently, Azure Arc-enabled Kubernetes clusters don't support using a logic app managed identity to authenticate managed API connections. You create these Azure-hosted and managed connections when you use managed connectors in your workflows.

Instead, you have to create your own app registration in Microsoft Entra ID. You can then use this app registration as an identity for logic apps deployed and running in Azure Arc-enabled Logic Apps. For more information, review the top-level prerequisites.

From your app registration, you need the client ID, object ID, tenant ID, and client secret. If you use Visual Studio Code to deploy, you have a built-in experience for setting up your logic app with a Microsoft Entra identity. For more information, review Create and deploy logic app workflows - Visual Studio Code.

However, if you use Visual Studio Code for development, but you use Azure CLI or automated pipelines to deploy, follow these steps.

Configure connection and app settings in your project

  1. In your logic app project's connections.json file, find the authentication object for the managed connection. Replace this object's contents with your app registration information, which you previously generated in the top-level prerequisites:

    "authentication": {
   "type": "ActiveDirectoryOAuth",
   "audience": "https://management.core.windows.net/",
   "credentialType": "Secret",
   "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
   "tenant": "@appsetting('WORKFLOWAPP_AAD_TENANTID')",
   "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')"
}

  2. In your logic app project's local.settings.json file, add your client ID, object ID, tenant ID, and client secret. After deployment, these settings become your logic app settings.

    {
   "IsEncrypted": false,
   "Values": {
      <...>
      "WORKFLOWAPP_AAD_CLIENTID":"<my-client-ID>",
      "WORKFLOWAPP_AAD_OBJECTID":"<my-object-ID",
      "WORKFLOWAPP_AAD_TENANTID":"<my-tenant-ID>",
      "WORKFLOWAPP_AAD_CLIENTSECRET":"<my-client-secret>"
   }
}

Important

For production scenarios or environments, make sure that you protect and secure such secrets and sensitive information, for example, by using a key vault.

Add access policies

In single-tenant Azure Logic Apps, each logic app has an identity that is granted permissions by access policies to use Azure-hosted and managed connections. You can set up these access policies by using the Azure portal or infrastructure deployments.

ARM template

In your Azure Resource Manager template (ARM template), include the following resource definition for each managed API connection and provide the following information:

Parameter Description
<connection-name> The name for your managed API connection, for example office365
<object-ID> The object ID for your Microsoft Entra identity, previously saved from your app registration
<tenant-ID> The tenant ID for your Microsoft Entra identity, previously saved from your app registration 
{
   "type": "Microsoft.Web/connections/accessPolicies",
   "apiVersion": "2016-06-01",
   "name": "[concat('<connection-name>'),'/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

For more information, review the Microsoft.Web/connections/accesspolicies (ARM template) documentation.

Azure portal

For this task, use your previously saved client ID as the application ID.

  1. In the Azure portal, find and open your logic app. On your logic app menu, under Workflows, select Connections, which lists all the connections in the workflows for your logic app resource.

  2. Under API Connections, select a connection, which is office365 in this example.

  3. On the connection's menu, under Settings, select Access policies > Add.

  4. In the Add access policy pane, in the search box, find and select your previously saved client ID.

  5. When you finish, select Add.

  6. Repeat these steps for each Azure-hosted connection in your logic app.

Automate DevOps deployment

To build and deploy your Azure Arc-enabled logic apps, you can use the same pipelines and processes as for single-tenant based logic apps. To automate infrastructure deployments using pipelines for DevOps, make the following changes at the infrastructure level for both noncontainer and container deployments.

Standard deployment (noncontainer)

If you use zip deploy for logic app deployment, you don't need to set up a Docker registry for hosting container images. Although logic apps on Kubernetes technically run on containers, Azure Arc-enabled Logic Apps manages these containers for you. For this scenario, complete the following tasks when you set up your infrastructure:

In your Azure Resource Manager template (ARM template) include the following values:

Item JSON property Description
Location location Make sure to use the same resource location (Azure region) as your custom location and Kubernetes environment. The resource locations for your logic app, custom location, and Kubernetes environment must all be the same.

Note: This value isn't the same as the name for your custom location.
App kind kind The type of app that you're deploying so the Azure platform can identify your app. For Azure Logic Apps, this information looks like the following example: kubernetes,functionapp,workflowapp,linux
Extended Location extendedLocation This object requires the "name" of your custom location for your Kubernetes environment and must have the "type" set to "CustomLocation".
Hosting plan resource ID serverFarmId The resource ID of the associated App Service plan, formatted as follows:

"/subscriptions/{subscriptionID}/resourceGroups/{groupName}/providers/Microsoft.Web/serverfarms/{appServicePlanName}"
Storage connection string AzureWebJobsStorage The connection string for your storage account

Important: You need to provide the connection string for your storage account in your ARM template. For production scenarios or environments, make sure that you protect and secure such secrets and sensitive information, for example, by using a key vault.

ARM template

The following example describes a sample Azure Arc-enabled Logic Apps resource definition that you can use in your ARM template. For more information, review the Microsoft.Web/sites template format (JSON) documentation.

{
   "type": "Microsoft.Web/sites",
   "apiVersion": "2020-12-01",
   "name": "[parameters('name')]",
   "location": "[parameters('location')]",
   "kind": "kubernetes,functionapp,workflowapp,linux",
   "extendedLocation": {
      "name": "[parameters('customLocationId')]",
      "type": "CustomLocation"
    },
   "properties": {
      "clientAffinityEnabled": false,
      "name": "[parameters('name')]",
      "serverFarmId": "<hosting-plan-ID>",
      "siteConfig": {
         "appSettings": [
            {
               "name": "FUNCTIONS_EXTENSION_VERSION",
               "value": "~3"
            },
            {
               "name": "FUNCTIONS_WORKER_RUNTIME",
               "value": "dotnet"
            },
            {
               "name": "AzureWebJobsStorage",
               "value": "<storage-connection-string>"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__id",
               "value": "Microsoft.Azure.Functions.ExtensionBundle.Workflows"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__version",
               "value": "[1.*, 2.0.0)"
            },
            {
               "name": "APP_KIND",
               "value": "workflowapp"
            }
         ],
         "use32BitWorkerProcess": "[parameters('use32BitWorkerProcess')]",
         "linuxFxVersion": "Node|12"
      }
   }
}

Note

By default, FUNCTIONS_WORKER_RUNTIME app setting for your logic app is dotnet. Previously, node was the default value. However, dotnet is now the default value for all new and existing deployed Arc enabled logic apps, even for apps that had a different value. This change shouldn't affect your workflow's runtime, and everything should work the same way as before. For more information, see the FUNCTIONS_WORKER_RUNTIME app setting.

The APP_KIND app setting for your logic app is set to workflowapp, but in some scenarios, this app setting is missing, for example, due to Azure Resource Manager templates or other scenarios where the setting might not be included. If certain actions don't work, such as the Execute JavaScript Code action or the workflow stops working, check that the APP_KIND app setting exists and is set to to workflowapp. For more information, see the APP_KIND app setting.

Container deployment

If you prefer to use container tools and deployment processes, you can containerize your logic apps and deploy them to Azure Arc-enabled Logic Apps. For this scenario, complete the following high-level tasks when you set up your infrastructure:

  • Set up a Docker registry for hosting your container images.

  • To containerize your logic app, add the following Dockerfile to your logic app project's root folder, and follow the steps for building and publishing an image to your Docker registry, for example, review Tutorial: Build and deploy container images in the cloud with Azure Container Registry Tasks.

    Note

    If you use SQL as your storage provider, make sure that you use an Azure Functions image version 3.3.1 or later.

    FROM mcr.microsoft.com/azure-functions/node:3.3.1
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true \
FUNCTIONS_V2_COMPATIBILITY_MODE=true
COPY . /home/site/wwwroot
RUN cd /home/site/wwwroot

  • Notify the resource provider that you're creating a logic app on Kubernetes.

  • In your deployment template, point to the Docker registry and container image where you plan to deploy. Single-tenant Azure Logic Apps uses this information to get the container image from your Docker registry.

  • Include an App Service plan with your deployment. For more information, review Include App Service plan with deployment.

In your Azure Resource Manager template (ARM template), include the following values:

Item JSON property Description
Location location Make sure to use the same resource location (Azure region) as your custom location and Kubernetes environment. The resource locations for your logic app, custom location, and Kubernetes environment must all be the same.

Note: This value isn't the same as the name for your custom location.
App kind kind The type of app that you're deploying so the Azure platform can identify your app. For Azure Logic Apps, this information looks like the following example: kubernetes,functionapp,workflowapp,container
Extended Location extendedLocation This object requires the "name" of your custom location for your Kubernetes environment and must have "type" set to "CustomLocation".
Container name linuxFxVersion The name for your container, formatted as follows: DOCKER\|<container-name>
Hosting plan resource ID serverFarmId The resource ID of the associated App Service plan, formatted as follows:

"/subscriptions/{subscriptionID}/resourceGroups/{groupName}/providers/Microsoft.Web/serverfarms/{appServicePlanName}"
Storage connection string AzureWebJobsStorage The connection string for your storage account

Important: When you deploy to a Docker container, you need to provide the connection string for your storage account in your ARM template. For production scenarios or environments, make sure that you protect and secure such secrets and sensitive information, for example, by using a key vault.

To reference your Docker registry and container image, include these values in your template:

Item JSON property Description
Docker registry server URL DOCKER_REGISTRY_SERVER_URL The URL for the Docker registry server
Docker registry server DOCKER_REGISTRY_SERVER_USERNAME The username to access the Docker registry server
Docker registry server password DOCKER_REGISTRY_SERVER_PASSWORD The password to access the Docker registry server

ARM template

The following example describes a sample Azure Arc-enabled Logic Apps resource definition that you can use in your ARM template. For more information, review the Microsoft.Web/sites template format (ARM template) documentation.

{
   "type": "Microsoft.Web/sites",
   "apiVersion": "2020-12-01",
   "name": "[parameters('name')]",
   "location": "[parameters('location')]",
   "kind": " kubernetes,functionapp,workflowapp,container",
   "extendedLocation": {
      "name": "[parameters('customLocationId')]",
      "type": "CustomLocation"
    },
   "properties": {
      "name": "[parameters('name')]",
      "clientAffinityEnabled": false,
      "serverFarmId": "<hosting-plan-ID>",
      "siteConfig": {
         "appSettings": [
            {
               "name": "FUNCTIONS_EXTENSION_VERSION",
               "value": "~3"
            },
            {
               "name": "FUNCTIONS_WORKER_RUNTIME",
               "value": "dotnet"
            },
            {
               "name": "AzureWebJobsStorage",
               "value": "<storage-connection-string>"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__id",
               "value": "Microsoft.Azure.Functions.ExtensionBundle.Workflows"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__version",
               "value": "[1.*, 2.0.0)"
            },
            {
               "name": "APP_KIND",
               "value": "workflowapp"
            }, 
            {
               "name": "DOCKER_REGISTRY_SERVER_URL",
               "value": "<docker-registry-server-URL>"
            },
            { 
               "name": "DOCKER_REGISTRY_SERVER_USERNAME",
               "value": "<docker-registry-server-username>"
            },
            {
               "name": "DOCKER_REGISTRY_SERVER_PASSWORD",
               "value": "<docker-registry-server-password>"
            }
         ],
         "use32BitWorkerProcess": "[parameters('use32BitWorkerProcess')]",
         "linuxFxVersion": "DOCKER|<container-name>"
      }
   }
}

Note

Previously, the FUNCTIONS_WORKER_RUNTIME setting's default value was node. Now, dotnet is the default value for all new and existing deployed Standard logic apps, even for apps that had a different value. This change shouldn't affect your workflow's runtime, and everything should work the same way as before. For more information, see the FUNCTIONS_WORKER_RUNTIME app setting.

Include App Service plan with deployment

Whether you have a standard or container deployment, you have to include an App Service plan with your deployment. Although this plan becomes less relevant with a Kubernetes environment, both the standard and container deployments still require an App Service plan.

While other create options usually handle provisioning the Azure resource for this plan, if your deployments use "infrastructure-as-code" templates, you have to explicitly create the Azure resource for the plan. The hosting plan resource doesn't change, only the sku information.

In your Azure Resource Manager template (ARM template), include the following values:

Item JSON property Description
Location location Make sure to use the same resource location (Azure region) as your custom location and Kubernetes environment. The resource locations for your logic app, custom location, and Kubernetes environment must all be the same.

Note: This value isn't the same as the name for your custom location.
Kind kind The kind of app service plan being deployed which needs to be kubernetes,linux
Extended Location extendedLocation This object requires the "name" of your custom location for your Kubernetes environment and must have "type" set to "CustomLocation".
Hosting plan name name The name for the App Service plan
Plan tier sku: tier The App Service plan tier, which is K1
Plan name sku: name The App Service plan name, which is Kubernetes

ARM template

The following example describes a sample App Service plan resource definition that you can use with your app deployment. For more information, review the Microsoft.Web/serverfarms template format (ARM template) documentation.

{
   "type": "Microsoft.Web/serverfarms",
   "apiVersion": "2020-12-01",
   "location": "<location>",
   "name": "<hosting-plan-name>",
   "kind": "kubernetes,linux",
   "extendedLocation": {
      "name": "[parameters('customLocationId')]",
      "type": "CustomLocation"
   },
   "sku": {
      "tier": "Kubernetes",
      "name": "K1", 
      "capacity": 1
   },
   "properties": {
      "kubeEnvironmentProfile": {
         "id": "[parameters('kubeEnvironmentId')]"
      }
   }
}

Change default scaling behavior

Azure Arc-enabled Logic Apps automatically manages the scaling for your logic apps based on the number of jobs in the backend storage queue. However, you can change the default scaling behavior.

In a logic app, the workflow definition specifies the sequence of actions to run. Whenever a workflow run is triggered, the Azure Logic Apps runtime creates a job for each action type in the workflow definition. The runtime then organizes these jobs into a job sequencer. This sequencer orchestrates running the jobs for the workflow definition, but the underlying Azure Logic Apps job orchestration engine runs each job.

For stateful workflows, the job orchestration engine uses storage queue messages to schedule jobs in the job sequencers. Behind the scenes, job dispatchers (or dispatcher worker instances) monitor these job queues. The orchestration engine uses a default minimum and maximum number of worker instances to monitor the job queues. For stateless workflows, the orchestration engine completely keeps action states in memory.

To change the default scaling behavior, you specify different minimum and maximum numbers of worker instances that monitor the job queues.

Prerequisites to change scaling

On your Azure Arc-enabled Kubernetes cluster, your previously created App Service bundle extension must have the keda.enabled property set to true. For more information, review the top-level prerequisites.

Change scaling threshold

In Azure Arc-enabled Logic Apps, the length of the job queue triggers a scale event and sets a threshold for how often scaling happens for your logic app. You can change the queue length, which has the default value set to 20 jobs. To scale less often, increase the queue length. To scale more often, decrease the queue length. This process might require some trial and error.

To change the queue length, in your logic app project's root-level host.json file, set the Runtime.ScaleMonitor.KEDA.TargetQueueLength property, for example:

"extensions": {
   "workflow": {
      "settings": {
         "Runtime.ScaleMonitor.KEDA.TargetQueueLength": "10"
      }
   }
}

Change throughput maximum

On an existing logic app resource, you can change the maximum number of worker instances, which has the default value set to 2. This value controls the upper limit on how many worker instances can monitor the job queues.

To change this maximum, use the Azure CLI (logic app create only) and Azure portal.

Azure CLI

To create a new logic app, run the command, az logicapp create, with the following parameters:

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation 
   [--plan MyHostingPlan] [--min-worker-count 1] [--max-worker-count 4]

To configure your maximum instance count, use the --settings parameter:

az logicapp config appsettings set --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription
   --settings "K8SE_APP_MAX_INSTANCE_COUNT=10"

Azure portal

In your single-tenant based logic app settings, add or edit the K8SE_APP_MAX_INSTANCE_COUNT setting value by following these steps:

  1. In the Azure portal, find and open your single-tenant based logic app.

  2. On the logic app menu, under Settings, select Configuration.

  3. In the Configuration pane, under Application settings, either add a new application setting or edit the existing value, if already added.

    1. Select New application setting, and add the K8SE_APP_MAX_INSTANCE_COUNT setting with the maximum value you want.

    2. Edit the existing value for the K8SE_APP_MAX_INSTANCE_COUNT setting.

  4. When you finish, save your changes.

Change throughput minimum

On an existing logic app resource, you can change the minimum number of worker instances, which has the default value set to 1. This value controls the lower limit on how many worker instances can monitor the job queues. For high availability or performance, increase this value.

To change this minimum, use the Azure CLI or the Azure portal.

Azure CLI

For an existing logic app resource, run the command, az logicapp scale, with the following parameters:

az logicapp scale --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --instance-count 5

To create a new logic app, run the command, az logicapp create, with the following parameters:

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation 
   [--plan MyHostingPlan] [--min-worker-count 2] [--max-worker-count 4]

Azure portal

In your single-tenant based logic app settings, change the Scale out property value by following these steps:

  1. In the Azure portal, find and open your single-tenant based logic app.

  2. On the logic app menu, under Settings, select Scale out.

  3. On the Scale out pane, drag the minimum instances slider to the value that you want.

  4. When you finish, save your changes.

Troubleshoot problems

To get more information about your deployed logic apps, try the following options:

Access app settings and configuration

To access your app settings, run the command, az logicapp config appsettings, with the following parameters:

az logicapp config appsettings list --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

To configure an app setting, run the command, az logicapp config appsettings set, with the following parameters. Make sure to use the --settings parameter with your setting's name and value.

az logicapp config appsettings set --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --settings "MySetting=1"

To delete an app setting, run the command, az logicapp config appsettings delete, with the following parameters. Make sure to use the --setting-names parameter with the name of the setting you want to delete.

az logicapp config appsettings delete --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription
   --setting-names MySetting

View logic app properties

To view your app information and properties, run the command, az logicapp show, with the following parameters:

az logicapp show --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Monitor workflow activity

To view the activity for a workflow in your logic app, follow these steps:

  1. In the Azure portal, find and open your deployed logic app.

  2. On the logic app menu, select Workflows, and then select your workflow.

  3. On the workflow menu, select Monitor.

Collect logs

To get logged data about your logic app, enable Application Insights on your logic app if not already enabled.

Next steps