Create Standard logic app workflows for hybrid deployment on your own infrastructure (Preview)
Applies to: Azure Logic Apps (Standard)
Note
This capability is in preview, incurs charges for usage, and is subject to the Supplemental Terms of Use for Microsoft Azure Previews.
For scenarios where you need to use, control, and manage your own infrastructure, you can create Standard logic app workflows using the hybrid deployment model in Azure Logic Apps. This model provides capabilities for you to build and host integration solutions for partially connected environments that require local processing, storage, and network access. Your infrastructure can include on-premises systems, private clouds, and public clouds. With the hybrid model, your Standard logic app workflow is powered by the Azure Logic Apps runtime that is hosted on premises as an Azure Container Apps extension.
For an architectural overview that shows where Standard logic app workflows are hosted and run in a partially connected environment, see Set up infrastructure requirements for hybrid deployment for Standard logic apps.
This how-to guide shows how to create and deploy a Standard logic app workflow using the hybrid deployment model after you set up the necessary on-premises resources for hosting your app.
Limitations
Hybrid deployment for Standard logic apps is available and supported only in the same regions as Azure Container Apps on Azure Arc-enabled AKS.
The following capabilities currently aren't available in this preview release:
- SAP access through the SAP built-in connector
- XSLT 1.0 for custom code
- Custom code support with .NET Framework
- Managed identity authentication
- File System connector
Azure Arc-enabled Kubernetes clusters currently don't support managed identity authentication for managed API connections. Instead, you must create your own app registration using Microsoft Entra ID. For more information, follow these steps later in this guide.
Some function-based triggers, such as Azure Blob, Cosmos DB, and Event Hubs require a connection to the Azure storage account associated with your Standard logic app. If you use any function-based triggers, in your Standard logic app's environment variables in the Azure portal or in your logic app project's local.settings.json file in Visual Studio Code, add the following app setting and provide your storage account connection string:
"Values": { "name": "AzureWebJobsStorage", "value": "{storage-account-connection-string}" }
Prerequisites
An Azure account and subscription. If you don't have a subscription, sign up for a free Azure account.
The following on-premises resources, which must all exist within the same network for the required connectivity:
- An Azure Kubernetes Service cluster that's connected to Azure Arc
- A SQL database to locally store workflow run history, inputs, and outputs for processing
- A Server Message Block (SMB) file share to locally store artifacts used by your workflows
To meet these requirements, set up these on-premises resources to support hybrid deployment for Standard logic apps.
To work in Visual Studio Code, you need the Azure Logic Apps (Standard) extension for Visual Studio Code with the related prerequisites.
Tip
If you have a new Visual Studio Code installation, confirm that you can locally run a basic Standard workflow before you try deploying to your own infrastructure. This test run helps isolate any errors that might exist in your Standard workflow project.
Create your Standard logic app in the Azure portal
After you meet the prerequisites, create your Standard logic app for hybrid deployment by following these steps:
In the Azure portal search box, enter logic apps, and select Logic apps.
On the Logic apps page toolbar, select Add.
On the Create Logic App page, under Standard, select Hybrid.
On the Create Logic App (Hybrid) page, provide the following information:
Property Required Value Description Subscription Yes <Azure-subscription-name> Your Azure subscription name.
This example uses Pay-As-You-Go.Resource Group Yes <Azure-resource-group-name> The Azure resource group where you create your hybrid app and related resources. This name must be unique across regions and can contain only letters, numbers, hyphens (-), underscores (_), parentheses (()), and periods (.).
This example creates a resource group named Hybrid-RG.Logic App name Yes <logic-app-name> Your logic app name, which must be unique across regions and can contain only lowercase letters, numbers, or hyphens (-).
This example uses my-logic-app-hybrid.Region Yes <Azure-region> An Azure region that is supported for Azure container apps on Azure Arc-enabled AKS.
This example uses East US.Container App Connected Environment Yes <connected-environment-name> The Arc-enabled Kubernetes cluster that you created as the deployment environment for your logic app. For more information, see Tutorial: Enable Azure Container Apps on Azure Arc-enabled Kubernetes. Configure storage settings Yes Enabled or disabled Continues to the Storage tab on the Create Logic App (Hybrid) page. The following example shows the logic app creation page in the Azure portal with sample values:
On the Storage page, provide the following information about the storage provider and SMB file share that you previously set up:
Property Required Value Description SQL connection string Yes <sql-server-connection-string> The SQL Server connection string that you previously saved. For more information, see Create SQL Server storage provider. Host name Yes <file-share-host-name> The host name for your SMB file share. File share path Yes <file-share-path> The file share path for your SMB file share. User name Yes <file-share-user-name> The user name for your SMB file share. Password Yes <file-share-password> The password for your SMB file share. When you finish, select Review + create. Confirm the provided information, and select Create.
After Azure completes deployment, select Go to resource.
From this view in the Azure portal, you can create, edit, and manage workflows as usual.
Note
Several known issues exist in the portal around how you find your Standard logic app, which is created as a container app in this release. Your Standard logic app is also labeled differently from Standard logic apps deployed to single-tenant Azure and App Service environment v3. For more information, see Known issues and troubleshooting - Azure portal.
To review the app settings, on the container app menu, under Settings, select Containers, and then select the Environment variables tab.
For more information about app settings and host settings, see Edit app settings and host settings.
Create your Standard logic app in Visual Studio Code
After you meet the prerequisites, but before you create your Standard logic app for hybrid deployment in Visual Studio Code, confirm that the following conditions are met:
- Your SMB file share server is accessible.
- Port 445 is open on the computer where you run Visual Studio Code.
Run Visual Studio Code as administrator.
In Visual Studio Code, on the Activity Bar, select the Azure icon.
In the Workspace section, from the toolbar, select the Azure Logic Apps icon, and then select Create new project.
Browse to the location where you want to create the folder for your Standard logic app project. Create your project folder, select the folder, and then choose Select.
From the workflow type list, select Stateful Workflow or Stateless Workflow. Provide a name for your workflow.
This example selects Stateful Workflow and uses my-stateful-workflow as the name.
From the list that appears, select Open in current window.
Visual Studio Code creates and opens your logic app project to show the workflow.json file.
From the list that appears, select Use connectors from Azure.
From the subscription list, select your Azure subscription.
From the resource group list, select Create new resource group. Provide a name for your resource group.
This example uses Hybrid-RG.
From the location list, select an Azure region that is supported for Azure container apps on Azure Arc-enabled AKS.
This example uses East US.
In the Explorer window, open the shortcut menu for the workflow.json file, and select Open Designer.
Build your workflow as usual by adding a trigger and actions. For more information, see Build a workflow with a trigger and actions.
Set up authentication for managed API connections
To authenticate managed API connections in Standard logic app workflows hosted on Azure Arc-enabled Kubernetes clusters, you must create your own app registration using Microsoft Entra ID. You can then add this app registration's values as environment variables in your Standard logic app resource to authenticate your API connections instead.
Create an app registration with Microsoft Entra ID
In the Azure portal, follow Quickstart: Register an application with the Microsoft identity platform to create an app registration.
After creation completes, find your new app registration in the portal.
On the resource menu, select Overview, and save the following values, which you need later for connection authentication:
- Client ID
- Tenant ID
- Client secret
For the object ID, follow these steps:
On the Overview page, select Managed application in local directory link for your app registration as shown:
On the page that opens, copy and save the Object ID value:
Now, add the saved values as environment variables to your Standard logic app resource.
Add environment variable values to your Standard logic app
In the Azure portal, go to your Standard logic app resource.
On the resource menu, under Settings, select Containers, and then select the Environment variables tab.
On the toolbar, select Edit and deploy.
On the Edit a container pane, select Environment variables, and then select Add.
From the following table, add each environment variable with the specified value:
Environment variable Value WORKFLOWAPP_AAD_CLIENTID <my-client-ID> WORKFLOWAPP_AAD_OBJECTID <my-object-ID> WORKFLOWAPP_AAD_TENANTID <my-tenant-ID> WORKFLOWAPP_AAD_CLIENTSECRET <my-client-secret> When you finish, select Save.
Store and reference client ID and client secret
You can store the client ID and client secret values in your logic app resource as secrets and then reference those values on the Environment variables tab instead.
On the resource menu, under Settings, select Secrets.
On the toolbar, select Add.
On the Add secret pane, provide the following information for each secret, and then select Add:
Key Value WORKFLOWAPP_AAD_CLIENTID <my-client-ID> WORKFLOWAPP_AAD_CLIENTSECRET <my-client-secret>
Deploy your logic app from Visual Studio Code
After you finish building your workflow, you can deploy your logic app to your Container Apps connected environment.
In the Explorer window, open the shortcut menu for the workflow node, which is my-stateful-workflow in this example, and select Deploy to logic app.
From the subscription list, select your Azure subscription.
From the available logic apps list, select Create new Logic App (Standard) in Azure. Provide a globally unique logic app name that uses only lowercase alphanumeric characters or hyphens.
This example uses my-logic-app-hybrid.
From the location list that appears, select the same Azure region where you have your connected environment.
This example uses East US.
From the hosting plan list, select Hybrid.
From the resource group list, select Create new resource group. Provide a name for your resource group.
This example uses Hybrid-RG.
From the connected environment list, select your environment.
Provide your previously saved values for the host name, SMB file share path, username, and password for your artifacts storage.
Provide the connection string for the SQL database that you set up for runtime storage.
Visual Studio Code starts the deployment process for your Standard logic app.
To monitor deployment status and Azure activity logs, from the View menu, select Output. In the window that opens, select Azure.
After deployment completes, you can go to the Azure portal to view your logic app workflow.
Note
Several known issues exist in the portal around how you find your Standard logic app, which is created as a container app in this release. Your Standard logic app is also labeled differently from Standard logic apps deployed to single-tenant Azure and App Service environment v3. For more information, see Known issues and troubleshooting - Azure portal.
Known issues and troubleshooting
Azure portal
Your Standard logic app is deployed as a Container App resource, but the type appears as Logic App (Hybrid).
Your Standard logic app is listed in Container Apps resource list, not the Logic apps resource list.
Your Container Apps connected environment lists your Standard logic app as having an App Type named Hybrid Logic App.
To reflect changes in the designer after you save your workflow, you might have to occasionally refresh the designer.
Arc-enabled Kubernetes clusters
In rare scenarios, you might notice a high memory footprint in your cluster. To prevent this issue, either scale out or add autoscale for node pools.
Function host isn't running
After you deploy your Standard logic app, confirm that your app is running correctly.
In the Azure portal, go to the container app resource for your logic app.
On the container app menu, select Overview.
On the Overview page, next to the Application Url field, select your container app's URL.
If your app is running correctly, a browser window opens and shows the following message:
Otherwise, if your app has any failures, check that your AKS pods are running correctly. From Windows PowerShell, run the following commands:
az aks get-credentials {resource-group-name} --name {aks-cluster-name} --admin kubectl get ns kubectl get pods -n logicapps-aca-ns kubectl describe pod {logic-app-pod-name} -n logicapps-aca-nsFor more information, see the following documentation:
Cluster doesn't have enough nodes
If you ran the previous command and get a warning similar to the following example, your cluster doesn't have enough nodes for processing:
Warning: FailedScheduling 4m52s (x29 over 46m) default-scheduler 0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod.
To increase the number of nodes, and set up autoscale, follow these steps:
In the Azure portal, go to your Kubernetes service instance.
On the instance menu, under Settings, select Node pools.
On the Node tools page toolbar, select + Add node pool.
For more information, see the following documentation:
- Create node pools for a cluster in Azure Kubernetes Service (AKS)
- Manage node pools for a cluster in Azure Kubernetes Service (AKS)
- Cluster autoscaling in Azure Kubernetes Service (AKS) overview
- Use the cluster autoscaler in Azure Kubernetes Service (AKS)
SMB Container Storage Interface (CSI) driver not installed
After you ran the earlier kubectl describe pod command, if the following warning appears, confirm whether the CSI driver for your SMB file share is installed correctly:
Warning FailedScheduling 5m16s (x2 over 5m27s) default-scheduler 0/14 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/14 nodes are available: 14 Preemption is not helpful for scheduling.
Normal NotTriggerScaleUp 9m49s (x31 over 14m) cluster-autoscaler pod didn't trigger scale-up: 3 pod has unbound immediate PersistentVolumeClaims
To confirm, from Windows PowerShell, run the following commands:
kubectl get csidrivers
If the results list that appears doesn't include smb.csi.k8s.io, from a Windows command prompt, and run the following command:
helm repo add csi-driver-smb
help repo update
helm install csi-driver-smb csi-driver-smb/csi-driver-smb --namespace kube-system --version v1.15.0
To check the CSI SMB Driver pods status, from the Windows command prompt, run the following command:
kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=csi-driver-smb" --watch
For more information, see Container Storage Interface (CSI) drivers on Azure Kubernetes Service (AKS).