- | State | Select **Published** if you want to publish the product. Before the APIs in a product can be called, the product must be published. By default, new products are unpublished, and are visible only to the **Administrators** group. |

- | `--state` | Select **published** if you want to publish the product. Before the APIs in a product can be called, the product must be published. By default, new products are unpublished, and are visible only to the **Administrators** group. |

-In API Management, groups are used to manage the visibility of products to developers. Products are first made visible to groups, and then developers in those groups can view and subscribe to the products that are associated with the groups.

-API Management has the following immutable system groups:

-* **Administrators** - Azure subscription administrators are members of this group. Administrators manage API Management service instances, creating the APIs, operations, and products that are used by developers. You can't add users to this group.

- > You can change the administrator [email settings](api-management-howto-configure-notifications.md#configure-email-settings) that are used in notifications sent to developers from your API Management instance.

- * To delete the group, click the name of the group and press **Delete**.

-## <a name="next-steps"> </a>Next steps

-Groups are used to manage the visibility of products to developers. API Management has the following built-in groups:

-* **Administrators** - Manage API Management service instances and create the APIs, operations, and products that are used by developers.

- Azure subscription administrators are members of this group.

-Administrators can also create custom groups or use external groups in an [associated Microsoft Entra tenant](api-management-howto-aad.md) to give developers visibility and access to API products. For example, create a custom group for developers in a partner organization to access a specific subset of APIs in a product. A user can belong to more than one group.

-Workspaces allow decentralized API development teams to manage and productize their own APIs, while a central API platform team maintains the API Management infrastructure. Each workspace contains APIs, products, subscriptions, and related entities that are accessible only to the workspace collaborators. Access is controlled through Azure role-based access control (RBAC).

- | **Administrator email** | The email address to which all the notifications from **API Management** will be sent. |

- 1. Select **Code** > **Create codespace on main**.

- 1. Select **SQLAzure** as the database engine. Azure SQL Database is a fully managed platform as a service (PaaS) database engine that's always running on the latest stable version of the SQL Server.

- **Step 8:** To verify that you secured the secrets:

- 1. Select **Logs**. A new deployment run is already started from your committed changes. You might need to select **Refresh** to see it.

-For examples of using other Node.js clients, see the individual documentation for the Node.js clients listed at [Node.js Redis clients](https://redis.io/docs/connect/clients/nodejs/).

-## Create a cache

-## Connect to the cache

-The latest builds of [node_redis](https://github.com/mranney/node_redis) provide support several connection options. Don't create a new connection for each operation in your code. Instead, reuse connections as much as possible.

-## Create a new Node.js app

-1. Create a new script file named *redistest.js*.

-1. Use the command to install a redis package.

- ```bash

- `npm install redis`

- ```

- This code shows you how to connect to an Azure Cache for Redis instance using the cache host name and key environment variables. The code also stores and retrieves a string value in the cache. The `PING` and `CLIENT LIST` commands are also executed. For more examples of using Redis with the [node_redis](https://github.com/mranney/node_redis) client, see [https://redis.js.org/](https://redis.js.org/).

- ```console

-## Clean up resources

-If you continue to the next tutorial, can keep the resources created in this quickstart and reuse them. Otherwise, if you're finished with the quickstart sample application, you can delete the Azure resources created in this quickstart to avoid charges.

-> [!IMPORTANT]

-> Deleting a resource group is irreversible and that the resource group and all the resources in it are permanently deleted. Make sure that you do not accidentally delete the wrong resource group or resources. If you created the resources for hosting this sample inside an existing resource group that contains resources you want to keep, you can delete each resource individually instead of deleting the resource group.

->

-1. Sign in to the [Azure portal](https://portal.azure.com) and select **Resource groups**.

-1. In the **Filter by name** text box, enter the name of your resource group. The instructions for this article used a resource group named *TestResources*. On your resource group in the result list, select **...** then **Delete resource group**.

- 

-1. Confirm the deletion of the resource group. Enter the name of your resource group to confirm, and select **Delete**.

-1. After a few moments, the resource group and all of its contained resources are deleted.

-## Next steps

-> [!div class="nextstepaction"]

-> [Create an ASP.NET web app that uses an Azure Cache for Redis.](./cache-web-app-howto.md)

-| Azure Logic Apps - Integration service environment (ISE) | [Add ISE capacity](../../logic-apps/ise-manage-integration-service-environment.md#add-ise-capacity) |

-> | actionrules | **Yes** | **Yes** | No |

-Azure Communication Services allows you to apply for a short code for SMS programs. In this document, we'll review the guidelines on how to fill out a program brief for short code registration. A program brief application consists of 4 sections:

-All Short Code programs are required to disclose program names, product description, or both, in messages, on the call-to-action, and in the terms and conditions. The program name is generally the sponsor of the Short Code program, often the brand name or company name associated with the Short Code.

-A random short code is a 5ΓÇô6-digit phone number that is randomly selected and assigned by the U.S. Common Short Codes Association (CSCA).

-A vanity short code is a 5ΓÇô6-digit phone number that is chosen by you for your program. You can look up the list of available short codes in the [US Short Codes directory](https://usshortcodedirectory.com/).

-Additionally, you may pick a number that the customer can spell out on their phone dial pad as an alphanumeric equivalent ΓÇô for example, Contoso can use OFFERS (633377).

-When you select a vanity short code, you are required to input a prioritized list of vanity short codes that youΓÇÖd like to use for your program. The alternatives in the list will be used if the first short code in your list isn't available to lease.

-This field captures the directionality of the SMS program ΓÇô 1-way or 2-way SMS. In United States, 2-way SMS is mandated to honor opt-out requests from customers.

-Short Code programs that solicit political donations are subject to [additional best practices](https://www.ctia.org/the-wireless-industry/industry-commitments/guidelines-for-federal-political-campaign-contributions-via-wireless-carriers-bill).

-Message Senders are required to maintain a privacy policy and terms and conditions that are specific to all short code programs and make it accessible to customers from the initial call-to-action.

-In this field, you can provide a URL of the privacy policy and terms and conditions where customers can access it. If you donΓÇÖt have the short code program specific privacy policy or terms of service URL yet, you can provide the URL of screenshots of what the short code program policies will look like (a design mockup of the website that will go live once the campaign is launched).

-Your terms of service must include terms specific to the short code program brief and must contain ALL of the following:

-Your terms of service must contain ALL of the following:

-> If you donΓÇÖt have a URL of the website, mockups, or design, please send an email with the screenshots to phone@microsoft.com with "[CompanyName - ProgramName] Short Code Request".

-In these fields, you must provide a URL of the website where customers will discover the program, URL for screenshots of the website, URL of mockup of the website, or URL with the design. If the program sign-up type is SMS, then you must provide the keywords the customer will send to the short code for opting in.

- - Enrolling a user in multiple programs based on a single opt-in is prohibited, even when all programs operate on the same short code. Please refer to the [CTIA monitoring handbook](https://www.wmcglobal.com/hubfs/CTIA%20Short%20Code%20Monitoring%20Handbook%20-%20v1.8.pdf) for best practices.

- - Program Name ΓÇô as described above

-You need to provide information about your company and point of contact. Status updates for your short code application will be sent to the point of contact email address.

-Customer care contact information must be clear and readily available to help customers understand program details as well as their status with the program. Customer care information should result in customers receiving help.

-Azure communication service offers an opt-out management service for short codes that allows customers to configure responses to mandatory keywords STOP/START/HELP. Prior to provisioning your short code, you'll be asked for your preference to manage opt-outs. If you opt-in, the opt-out management service will automatically use your responses in the program brief for Opt-in/ Opt-out/ Help keywords in response to STOP/START/HELP keyword.

-CTIA requires that the customer must actively opt into short code programs by sending a keyword from their mobile device to the short code, providing consent on website, IVR, etc.

-Message senders are required to have mechanisms to opt customers out of the program and respond to messages containing the STOP keyword with the program name and confirmation that no additional messages will be sent.

-**Example:** Contoso Appointment reminders: YouΓÇÖre opted out and will receive no further messages.

-Please see our [guide on opt-outs](./sms-faq.md#opt-out-handling) to learn about how Azure Communication Services handles opt-outs.

-The following documents may be interesting to you:

-> [!NOTE]

-> For logic apps hosted in an [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md),

-> the connector's ISE version uses the [ISE message limits](../logic-apps/logic-apps-limits-and-config.md#message-size-limits) instead.

- You don't have to create a private endpoint. You can just permit traffic through the ISE outbound IPs on the storage account.

- You don't have to create a private endpoint. You can just permit traffic through the ISE outbound IPs on the storage account.

- * In multitenant Azure Logic Apps, you need the [on-premises data gateway](../logic-apps/logic-apps-gateway-install.md) installed on a local computer and a [data gateway resource that's already created in Azure](../logic-apps/logic-apps-gateway-connection.md).

- * In an ISE, you don't need the on-premises data gateway for SQL Server Authentication and non-Windows Authentication connections, and you can use the ISE-versioned SQL Server connector. For Windows Authentication, you need the [on-premises data gateway](../logic-apps/logic-apps-gateway-install.md) on a local computer and a [data gateway resource that's already created in Azure](../logic-apps/logic-apps-gateway-connection.md). The ISE-version connector doesn't support Windows Authentication, so you have to use the regular SQL Server managed connector.

- | **Logic Apps Managed Identity** | - Supported with the SQL Server managed connector and ISE-versioned connector. In Standard workflows, this authentication type is available for the SQL Server built-in connector, but the option is named **Managed identity** instead. <br><br>- Requires the following items: <br><br> A valid managed identity that's [enabled on your logic app resource](../logic-apps/create-managed-service-identity.md) and has access to your database. <br><br> **SQL DB Contributor** role access to the SQL Server resource <br><br> **Contributor** access to the resource group that includes the SQL Server resource. <br><br>For more information, see the following documentation: <br><br>- [Managed identity authentication for SQL Server connector](/connectors/sql/#managed-identity-authentication) <br>- [SQL - Server-Level Roles](/sql/relational-databases/security/authentication-access/server-level-roles) |

- | [**Microsoft Entra integrated**](/azure/azure-sql/database/authentication-aad-overview) | - Supported with the SQL Server managed connector and ISE-versioned connector. <br><br>- Requires a valid managed identity in Microsoft Entra that's [enabled on your logic app resource](../logic-apps/create-managed-service-identity.md) and has access to your database. For more information, see these topics: <br><br>- [Azure SQL Security Overview - Authentication](/azure/azure-sql/database/security-overview#authentication) <br>- [Authorize database access to Azure SQL - Authentication and authorization](/azure/azure-sql/database/logins-create-manage#authentication-and-authorization) <br>- [Azure SQL - Microsoft Entra integrated authentication](/azure/azure-sql/database/authentication-aad-overview) |

- | [**SQL Server Authentication**](/sql/relational-databases/security/choose-an-authentication-mode#connecting-through-sql-server-authentication) | - Supported with the SQL Server managed connector and ISE-versioned connector. <br><br>- Requires the following items: <br><br> A data gateway resource that's previously created in Azure for your connection, regardless whether your logic app is in multitenant Azure Logic Apps or an ISE. <br><br> A valid user name and strong password that are created and stored in your SQL Server database. For more information, see the following topics: <br><br>- [Azure SQL Security Overview - Authentication](/azure/azure-sql/database/security-overview#authentication) <br>- [Authorize database access to Azure SQL - Authentication and authorization](/azure/azure-sql/database/logins-create-manage#authentication-and-authorization) |

- | [**SQL Server Authentication**](/sql/relational-databases/security/choose-an-authentication-mode#connecting-through-sql-server-authentication) | - Supported with the SQL Server managed connector, SQL Server built-in connector, and ISE-versioned connector. <br><br>- Requires the following items: <br><br> A data gateway resource that's previously created in Azure for your connection, regardless whether your logic app is in multitenant Azure Logic Apps or an ISE. <br><br> A valid user name and strong password that are created and stored in your SQL Server. <br><br>For more information, see [SQL Server Authentication](/sql/relational-databases/security/choose-an-authentication-mode#connecting-through-sql-server-authentication). |

- | [**Windows Authentication**](/sql/relational-databases/security/choose-an-authentication-mode#connecting-through-windows-authentication) | - Supported with the SQL Server managed connector. <br><br>- Requires the following items: <br><br> A data gateway resource that's previously created in Azure for your connection, regardless whether your logic app is in multitenant Azure Logic Apps or an ISE. <br><br> A valid Windows user name and password to confirm your identity through your Windows account. <br><br>For more information, see [Windows Authentication](/sql/relational-databases/security/choose-an-authentication-mode#connecting-through-windows-authentication). |

- - In an ISE, you don't need the on-premises data gateway. Instead, you can use the ISE-versioned File System connector.

- | **Username** | Yes | <*domain-and-username*> | The domain and username for the computer where you have your file system. <br><br>For the managed File System connector, use one of the following values with the backslash (**`\`**): <br><br>- **<*domain*>\\<*username*>** <br>- **<*local-computer*>\\<*username*>** <br><br>For example, if your file system folder is on the same computer as the on-premises data gateway installation, you can use **<*local-computer*>\\<*username*>**. <br><br>- For the ISE-based File System connector, use the forward slash instead (**`/`**): <br><br>- **<*domain*>/<*username*>** <br>- **<*local-computer*>/<*username*>** |

- The following example shows the connection information for the File System ISE-based trigger:

- 

- | **Username** | Yes | <*domain-and-username*> | The domain and username for the computer where you have your file system. <br><br>For the managed File System connector, use one of the following values with the backslash (**`\`**): <br><br>- **<*domain*>\\<*username*>** <br>- **<*local-computer*>\\<*username*>** <br><br>For example, if your file system folder is on the same computer as the on-premises data gateway installation, you can use **<*local-computer*>\\<*username*>**. <br><br>- For the ISE-based File System connector, use the forward slash instead (**`/`**): <br><br>- **<*domain*>/<*username*>** <br>- **<*local-computer*>/<*username*>** |

- | **Username** | Yes | <*domain-and-username*> | The domain and username for the computer where you have your file system. <br><br>For the managed File System connector, use one of the following values with the backslash (**`\`**): <br><br>- **<*domain*>\\<*username*>** <br>- **<*local-computer*>\\<*username*>** <br><br>For example, if your file system folder is on the same computer as the on-premises data gateway installation, you can use **<*local-computer*>\\<*username*>**. <br><br>- For the ISE-based File System connector, use the forward slash instead (**`/`**): <br><br>- **<*domain*>/<*username*>** <br>- **<*local-computer*>/<*username*>** |

- The following example shows the connection information for the File System ISE-based connector action:

- 

- | **Username** | Yes | <*domain-and-username*> | The domain and username for the computer where you have your file system. <br><br>For the managed File System connector, use one of the following values with the backslash (**`\`**): <br><br>- **<*domain*>\\<*username*>** <br>- **<*local-computer*>\\<*username*>** <br><br>For example, if your file system folder is on the same computer as the on-premises data gateway installation, you can use **<*local-computer*>\\<*username*>**. <br><br>- For the ISE-based File System connector, use the forward slash instead (**`/`**): <br><br>- **<*domain*>/<*username*>** <br>- **<*local-computer*>/<*username*>** |

-## ISE and connectors

-> [!IMPORTANT]

->

-> On August 31, 2024, the ISE resource retires, due to its dependency on Azure Cloud Services (classic),

-> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard

-> logic apps to avoid service disruption. Standard logic app workflows run in single-tenant Azure Logic Apps

-> and provide the same capabilities plus more. For example, Standard workflows support using private endpoints

-> for inbound traffic so that your workflows can communicate privately and securely with virtual networks.

-> Standard workflows also support virtual network integration for outbound traffic. For more information,

-> review [Secure traffic between virtual networks and single-tenant Azure Logic Apps using private endpoints](/azure/logic-apps/secure-single-tenant-workflow-virtual-network-private-endpoint).

-If you use a dedicated [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) where workflows can directly access to resources in an Azure virtual network, you can build, deploy, and run your workflows on dedicated resources.

-Custom connectors created within an ISE don't work with the on-premises data gateway. However, these connectors can directly access on-premises data sources that are connected to an Azure virtual network hosting the ISE. So, logic app workflows in an ISE most likely don't need the data gateway when communicating with those resources. If you have custom connectors that you created outside an ISE that require the on-premises data gateway, workflows in an ISE can use those connectors.

-In the workflow designer, when you browse the built-in connectors or managed connectors that you want to use for workflows in an ISE, the **CORE** label appears on built-in connectors, while the **ISE** label appears on managed connectors that are designed to work with an ISE.

- :::column:::

- 

- <br><br>**CORE**

- <br><br>Built-in connectors with this label run in the same ISE as your workflows.

- :::column-end:::

- :::column:::

- 

- <br><br>**ISE**

- <br><br>Managed connectors with this label run in the same ISE as your workflows.

- <br><br>If you have an on-premises system that's connected to an Azure virtual network, an ISE lets your workflows directly access that system without using the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md). Instead, you can either use that system's **ISE** connector if available, an HTTP action, or a [custom connector](#custom-connectors-and-apis).

- <br><br>For on-premises systems that don't have **ISE** connectors, use the on-premises data gateway. To find available ISE connectors, review [ISE connectors](#ise-and-connectors).

- :::column-end:::

- :::column:::

- 

- <br><br>No label

- <br><br>All other connectors without a label, which you can continue to use, run in the global, multitenant Logic Apps service.

- :::column-end:::

- :::column:::

- :::column-end:::

-## ISE connectors

-In an integration service environment (ISE), these managed connectors also have [ISE versions](introduction.md#ise-and-connectors), which have different capabilities than their multitenant versions:

-> [!NOTE]

->

-> Workflows that run in an ISE and their connectors, regardless where those connectors run, follow a fixed pricing plan versus the Consumption pricing plan. For more information, review [Azure Logic Apps pricing model](../logic-apps/logic-apps-pricing.md) and [Azure Logic Apps pricing details](https://azure.microsoft.com/pricing/details/logic-apps/).

- :::column:::

- [![AS2 ISE icon][as2-icon]][as2-doc]

- <br><br>[**AS2** ISE][as2-doc]

- :::column-end:::

- :::column:::

- [![Azure Automation ISE icon][azure-automation-icon]][azure-automation-doc]

- <br><br>[**Azure Automation** ISE][azure-automation-doc]

- :::column-end:::

- :::column:::

- [![Azure Blob Storage ISE icon][azure-blob-storage-icon]][azure-blob-storage-doc]

- <br><br>[**Azure Blob Storage** ISE][azure-blob-storage-doc]

- :::column-end:::

- :::column:::

- [![Azure Cosmos DB ISE icon][azure-cosmos-db-icon]][azure-cosmos-db-doc]

- <br><br>[**Azure Cosmos DB** ISE][azure-cosmos-db-doc]

- :::column-end:::

- :::column:::

- [![Azure Event Hubs ISE icon][azure-event-hubs-icon]][azure-event-hubs-doc]

- <br><br>[**Azure Event Hubs** ISE][azure-event-hubs-doc]

- :::column-end:::

- :::column:::

- [![Azure Event Grid ISE icon][azure-event-grid-icon]][azure-event-grid-doc]

- <br><br>[**Azure Event Grid** ISE][azure-event-grid-doc]

- :::column-end:::

- :::column:::

- [![Azure Files ISE icon][azure-file-storage-icon]][azure-file-storage-doc]

- <br><br>[**Azure Files** ISE][azure-file-storage-doc]

- :::column-end:::

- :::column:::

- [![Azure Key Vault ISE icon][azure-key-vault-icon]][azure-key-vault-doc]

- <br><br>[**Azure Key Vault** ISE][azure-key-vault-doc]

- :::column-end:::

- :::column:::

- [![Azure Monitor Logs ISE icon][azure-monitor-logs-icon]][azure-monitor-logs-doc]

- <br><br>[**Azure Monitor Logs** ISE][azure-monitor-logs-doc]

- :::column-end:::

- :::column:::

- [![Azure Service Bus ISE icon][azure-service-bus-icon]][azure-service-bus-doc]

- <br><br>[**Azure Service Bus** ISE][azure-service-bus-doc]

- :::column-end:::

- :::column:::

- [![Azure Synapse Analytics ISE icon][azure-sql-data-warehouse-icon]][azure-sql-data-warehouse-doc]

- <br><br>[**Azure Synapse Analytics** ISE][azure-sql-data-warehouse-doc]

- :::column-end:::

- :::column:::

- [![Azure Table Storage ISE icon][azure-table-storage-icon]][azure-table-storage-doc]

- <br><br>[**Azure Table Storage** ISE][azure-table-storage-doc]

- :::column-end:::

- :::column:::

- [![Azure Queues ISE icon][azure-queues-icon]][azure-queues-doc]

- <br><br>[**Azure Queues** ISE][azure-queues-doc]

- :::column-end:::

- :::column:::

- [![EDIFACT ISE icon][edifact-icon]][edifact-doc]

- <br><br>[**EDIFACT** ISE][edifact-doc]

- :::column-end:::

- :::column:::

- [![File System ISE icon][file-system-icon]][file-system-doc]

- <br><br>[**File System** ISE][file-system-doc]

- :::column-end:::

- :::column:::

- [![FTP ISE icon][ftp-icon]][ftp-doc]

- <br><br>[**FTP** ISE][ftp-doc]

- :::column-end:::

- :::column:::

- [![IBM 3270 ISE icon][ibm-3270-icon]][ibm-3270-doc]

- <br><br>[**IBM 3270** ISE][ibm-3270-doc]

- :::column-end:::

- :::column:::

- [![IBM DB2 ISE icon][ibm-db2-icon]][ibm-db2-doc]

- <br><br>[**IBM DB2** ISE][ibm-db2-doc]

- :::column-end:::

- :::column:::

- [![IBM MQ ISE icon][ibm-mq-icon]][ibm-mq-doc]

- <br><br>[**IBM MQ** ISE][ibm-mq-doc]

- :::column-end:::

- :::column:::

- [![SAP ISE icon][sap-icon]][sap-connector-doc]

- <br><br>[**SAP** ISE][sap-connector-doc]

- :::column-end:::

- :::column:::

- [![SFTP-SSH ISE icon][sftp-ssh-icon]][sftp-ssh-doc]

- <br><br>[**SFTP-SSH** ISE][sftp-ssh-doc]

- :::column-end:::

- :::column:::

- [![SMTP ISE icon][smtp-icon]][smtp-doc]

- <br><br>[**SMTP** ISE][smtp-doc]

- :::column-end:::

- :::column:::

- [![SQL Server ISE icon][sql-server-icon]][sql-server-doc]

- <br><br>[**SQL Server** ISE][sql-server-doc]

- :::column-end:::

- :::column:::

- [![X12 ISE icon][x12-icon]][x12-doc]

- <br><br>[**X12** ISE][x12-doc]

- :::column-end:::

-For more information, see these topics:

-* [Access to Azure virtual network resources from Azure Logic Apps](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md)

-* [Azure Logic Apps pricing model](../logic-apps/logic-apps-pricing.md)

-The release notes are continuously updated, and as critical issues requiring a workaround are discovered, they are added. Before you deploy your Data Box Edge/Data Box Gateway, carefully review the information contained in the release notes.

-No new issues are release noted for this release. All the release noted issues have carried over from the previous releases. To see a list of known issues, go to [Known issues in the GA release](data-box-gateway-release-notes.md#known-issues-in-ga-release).

-The following release notes identify the critical open issues and the resolved issues for the 1906 release for Azure Data Box Edge and Azure Data Box Gateway.

-The release notes are continuously updated, and as critical issues requiring a workaround are discovered, they are added. Before you deploy your Data Box Edge/Data Box Gateway, carefully review the information contained in the release notes.

-No new issues are release noted for this release. All the release noted issues have carried over from the previous releases. To see a list of known issues, go to [Known issues in the GA release](data-box-gateway-release-notes.md#known-issues-in-ga-release).

-The release notes are continuously updated. As critical issues that require a workaround are discovered, they are added. Before you deploy your Azure Data Box Gateway, carefully review the information in the release notes.

-No new issues are release noted for this release. All the release noted issues have carried over from the previous releases. To see a list of known issues, go to [Known issues in the GA release](data-box-gateway-release-notes.md#known-issues-in-ga-release).

-The release notes are continuously updated. As critical issues that require a workaround are discovered, they are added. Before you deploy your Azure Data Box Gateway, carefully review the information in the release notes.

-No new issues are release noted for this release. All the release noted issues have carried over from the previous releases. To see a list of known issues, go to [Known issues in the GA release](data-box-gateway-release-notes.md#known-issues-in-ga-release).

-The release notes are continuously updated, and as critical issues requiring a workaround are discovered, they are added. Before you deploy your Data Box Edge/Data Box Gateway, carefully review the information contained in the release notes.

-| **1.** |File types | The following file types are not supported: character files, block files, sockets, pipes, symbolic links. |Copying these files results in 0-length files getting created on the NFS share. These files remain in an error state and are also reported in *error.xml*. <br> Symbolic links to directories result in directories never getting marked offline. As a result, you may not see the gray cross on the directories that indicates that the directories are offline and all the associated content was completely uploaded to Azure. |

-| **2.** |Deletion | Due to a bug in this release, if an NFS share is deleted, then the share may not be deleted. The share status will display *Deleting*. |This occurs only when the share is using an unsupported file name. |

-| **3.** |Copy | Data copy fails with Error: The requested operation could not be completed due to a file system limitation. |The Alternate Data Stream (ADS) associated with file size greater than 128 KB is not supported. |

-The Data Box Device may not be offered in all regions or jurisdictions, and even where it is offered, it may be subject to availability. Microsoft is not responsible for delays related to the Service outside of its direct control. Microsoft reserves the right to refuse to offer the Service and corresponding Data Box Device to anyone in its sole discretion and judgment.

-As part of the Service, Microsoft allows Customer to retain the Data Box Device for limited periods of time which may vary based on the Data Box Device type. If Customer retains the Data Box Device beyond the specified time period, Microsoft may charge Customer additional daily fees as described at https://go.microsoft.com/fwlink/?linkid=2052173.

-All right, title and interest in each Data Box Device is and shall remain the property of Microsoft, and except as described in the Additional Terms, no rights are granted to any Data Box Device (including under any patent, copyright, trade secret, trademark or other proprietary rights). Customer will compensate Microsoft for any loss, material damage or destruction to or of any Data Box Device while it is at any of CustomerΓÇÖs locations as described in Shipment and Title; Fees, Table 1. Customer is responsible for inspecting the Data Box Device upon receipt from the carrier and for promptly reporting any damage to Microsoft Support at databoxsupport@microsoft.com. Customer is responsible for the entire risk of loss of, or any damage to, the Data Box Device once it has been delivered by the carrier to CustomerΓÇÖs designated address until the Microsoft-designated carrier accepts the Data Box Device for delivery back to the Designated Azure Data Center.

-Microsoft may charge Customer specified fees in connection with its use of the Data Box Device as part of the Service, as described at https://go.microsoft.com/fwlink/?linkid=2052173. For clarity, Azure Storage and Azure IoT Hub are separate Azure Services, and if used (even in connection with its use of the Service), separate Azure metered fees will apply. Additional Azure services Customer uses after completing a transfer of data using the Azure Data Box Service are also subject to separate usage fees. For Data Box Devices, Microsoft may charge Customer a lost device fee, as provided in Table 1 below, if the Data Box Device is lost or materially damaged while it is in CustomerΓÇÖs care. Microsoft reserves the right to change the fees charged for Data Box Device types, including charging different amounts for different device form factors.

-Microsoft will designate a carrier for shipping and delivery of Data Box Devices that are transported or delivered between Customer and a Designated Azure Data Center or a Microsoft entity. Customer will be responsible for costs of shipping a Data Box Device from Microsoft or a Designated Azure Data Center to Customer and return shipping of the Data Box Device, including any metered amounts for carrier charges, any taxes, or applicable customs fees. When returning a Data Box Device to Microsoft, Customer will package and ship the Data Box Device in accordance with MicrosoftΓÇÖs instructions, including using a carrier designated by Microsoft and the packaging materials provided by Microsoft.

-Although data on a Data Box Device is encrypted, Customer acknowledges that there are inherent risks in shipping data on and in connection with the Data Box Device, and that Microsoft will have no liability to Customer for any damage, theft, or loss occurring to a Data Box Device or any data stored on one, including during transit.

-Alternatively, Customer may elect to use CustomerΓÇÖs designated carrier or Customer itself to ship and return the Data Box Device by selecting this option in the Service portal. Once selected, (i) Microsoft will inform Customer about Data Box Device availability; (ii) Microsoft will prepare the Data Box Device for pick-up by CustomerΓÇÖs designated carrier or Customer itself; and (iii) Customer will coordinate with Microsoft and Designated Azure Data Center personnel for pick-up and return of the Data Box Device by CustomerΓÇÖs designated carrier or Customer directly. CustomerΓÇÖs election for self-managed shipment is subject to the following: (i) Customer abides by all other applicable terms and conditions related to the Service and Data Box Device, including the Product Terms and the Azure Data Box Hardware Terms; (ii) Customer is responsible for the entire risk of loss of, or any damage to, the Data Box Device (as described in the ΓÇ£Shipment and Title; FeesΓÇ¥ section, under subsection (a) ΓÇ£Title and Risk of LossΓÇ¥) from the time that Microsoft makes the Data Box Device available for pick-up by CustomerΓÇÖs designated carrier or Customer, to the time Microsoft has accepted the Data Box Device from CustomerΓÇÖs designated carrier or Customer at the Designated Azure Data Center; (iii) Customer is fully responsible for the costs of shipping a Data Box Device from Microsoft or a Designated Azure Data Center to Customer and return shipping of the same, including carrier charges, any taxes, or applicable customs fees; (iv) When returning a Data Box Device to Microsoft or a Designated Azure Data Center, Customer will package and ship the Data Box Device in accordance with MicrosoftΓÇÖs instructions and any packaging materials provided by Microsoft; (v) Customer will be charged applicable fees (as described in the ΓÇ£Shipment and Title; FeesΓÇ¥ section, under subsection (b) ΓÇ£FeesΓÇ¥) which commence from the time the Data Box Device is ready for pick-up at the agreed upon time and location, and will cease once the Data Box Device has been delivered to Microsoft or the Designated Azure Data Center; and (vi) Customer acknowledges that there are inherent risks in shipping data on and in connection with the Data Box Device, and that Microsoft will have no liability to Customer for any damage, theft, or loss occurring to a Data Box Device or any data stored on one, including during transit when shipped by CustomerΓÇÖs designated carrier.

-If Customer wishes to move a Data Box Device to another country/region, then Customer must be the exporter of record from the country/region of export and importer of record into the country/region where the Data Box Device is being imported. Customer is responsible for obtaining, at its own risk and expense, any export license, import license and other official authorization for the exportation and importation of the Data Box Device and CustomerΓÇÖs data to any such different Customer location. Customer shall also be responsible for customs clearance at any such different Customer location, and will bear all duties, taxes, fines, penalties (if applicable) and all charges payable for exporting and importing the Data Box Device, as well as any and all costs and risks of carrying out customs formalities in a timely manner. Customer agrees to comply with and be responsible for all applicable import, export and general trade laws and regulations should Customer decide to transport the Data Box Device beyond the country/region border in which Customer receives the Data Box Device. Additionally, if Customer transports the Data Box Device to a different country/region, prior to shipping the Data Box Device back to the original point of origin, whether a specified Microsoft entity or a Designated Azure Data Center, Customer agrees to return the Data Box Device to the country/region location where Customer initially received the Data Box Device. If requested, Microsoft may provide MicrosoftΓÇÖs estimated value of the Data Box Device as supplied by Microsoft to Customer and share available product certifications for the Data Box Device.

-Here are the icons that you will find when you review the safety precautions to be observed when setting up and running your Data Box.

-|  **DANGER!** |Indicates a hazardous situation that, if not avoided, will result in death or serious injury. This signal word is to be limited to the most extreme situations. |

-|  **WARNING!** |Indicates a hazardous situation that, if not avoided, could result in death or serious injury. |

-|  **CAUTION!** |Indicates a hazardous situation that, if not avoided, could result in minor or moderate injury. |

-|  **No user serviceable parts** |Do not access unless properly trained. |

-* Place the equipment on a flat, hard and stable surface to avoid a potential tip or crushing hazard.

-* Inspect the *as-received* device for damages. If the device enclosure is damaged, contact [Microsoft Support](data-box-disk-contact-microsoft-support.md) to obtain a replacement. Do not attempt to operate the device.

-* The device is equipped with tamper-proof screws. If you suspect the device is malfunctioning, [Microsoft Support](data-box-disk-contact-microsoft-support.md) to obtain a replacement. Do not attempt to service the device.

-* The device contains no user-serviceable parts. Hazardous voltage, current, and energy levels are present inside. Do not open. Return the device to Microsoft for servicing.

-* A fully configured enclosure can weigh up to 326 kg (719 lbs); do not try to lift it by yourself.

-* Do not attempt to lift the equipment without proper mechanical aid. Be aware that any attempts to lift this weight can cause severe injuries.

-* Data Box Heavy is not to be used as a table or workspace. Adding any type of load can create a potential hazard which could lead to injury or property damage.

-* Rack-mounted equipment is not to be used as shelves or work spaces. Do not place the Data Box Heavy on top of rack-mounted equipment. Adding any type of load to an extended rack-mounted unit can create a potential tip hazard that could lead to injury, death, or product damage.

- - Provided with sufficient space to access the power supply cord(s), because they serve as the product's main power disconnect.

-* Provide a safe electrical earth connection to the power supply cord. The AC cord has a three-wire grounding plug (a plug that has a grounding pin). This plug fits only a grounded AC outlet. Do not defeat the purpose of the grounding pin.

-* Permanently unplug the unit before you move it or if you think it has become damaged in any way.

-* Do not attempt to modify or use AC power cord(s) other than the ones provided with the equipment. The power cord(s) must meet the following criteria:

-* Unplug all AC power cord(s) to completely remove the AC power from the equipment.

-* This device contains coin cell batteries. Do not attempt to service the device. Batteries in this device are not user serviceable.

-* Laser peripherals or devices are present. To avoid risk or radiation exposure and/or personal injury, do not open the enclosure of any laser peripheral or device. Laser peripherals or devices are not serviceable. Only use certified and rated Laser Class I for optical transceiver product.

- - Operating altitude: Tested up to 6,560 feet (up to 2000 meters)

-This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to correct the interference at their own expense.

-Microsoft Ireland Sandyford Ind Est Dublin D18 KX32 IRL

-Here are the icons that you will find when you review the safety precautions to be observed when setting up and running your Data Box.

-|  **DANGER!** |Indicates a hazardous situation that, if not avoided, will result in death or serious injury. This signal word is to be limited to the most extreme situations. |

-|  **No User Serviceable Parts** |Do not access unless properly trained. |

-* Inspect the *as-received* device for damages. If the device enclosure is damaged, [contact Microsoft Support](data-box-disk-contact-microsoft-support.md) to obtain a replacement. Do not attempt to operate the device.

-* The device is equipped with tamper-proof screws. If you suspect the device is malfunctioning, [contact Microsoft Support](data-box-disk-contact-microsoft-support.md) to obtain a replacement. Do not attempt to service the device.

-* The device contains no user-serviceable parts. Hazardous voltage, current, and energy levels are present inside. Do not open. Return the device to Microsoft for servicing.

-* A fully configured enclosure can weigh up to 22.7 kg (50 lbs); do not try to lift it by yourself.

-* Rack-mounted equipment is not to be used as shelves or work spaces. Do not place the Data Box on top of rack-mounted equipment. Adding any type of load to an extended rack-mounted unit can create a potential tip hazard that could lead to injury, death, or product damage.

-* Provide a safe electrical earth connection to the power supply cord. The AC cord has a three-wire grounding plug (a plug that has a grounding pin). This plug fits only a grounded AC outlet. Do not defeat the purpose of the grounding pin.

-* Permanently unplug the unit before you move it or if you think it has become damaged in any way.

-* This device contains coin cell batteries. Do not attempt to service the device. Batteries in this device are not user serviceable.

- - Operating altitude: Tested up to 6500 feet (0 meters to 2000 meters)

-This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to correct the interference at their own expense.

-This device complies with part 15 of the FCC Rules and Industry Canada license-exempt RSS standard(s). Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation of the device.

-This is a class A product. In a domestic environment, this product may cause radio interference in which case the user may be required to take adequate measures.

-This symbol on the product or its batteries or its packaging means that this product and any batteries it contains must not be disposed of with your household waste. Instead, it is your responsibility to hand this over to an applicable collection point for the recycling of batteries and electrical and electronic equipment. This separate collection and recycling will help to conserve natural resources and prevent potential negative consequences for human health and the environment due to the possible presence of hazardous substances in batteries and electrical and electronic equipment, which could be caused by inappropriate disposal. For more information about where to drop off your batteries and electrical and electronic waste, please contact your local city/municipality office, your household waste disposal service, or the shop where you purchased this product. Contact *erecycle\@microsoft.com* for additional information on WEEE.

-Microsoft Ireland Sandyford Ind Est Dublin D18 KX32 IRL

-After you have reviewed these safety notices, you can set up and cable your device.

-description: Add logic apps, integration accounts, custom connectors, and managed connectors to your integration service environment (ISE).

-# Add resources to your integration service environment (ISE) in Azure Logic Apps

-> [!IMPORTANT]

->

-> On August 31, 2024, the ISE resource will retire, due to its dependency on Azure Cloud Services (classic),

-> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard

-> logic apps so that you can avoid service disruption. Standard logic app workflows run in single-tenant Azure

-> Logic Apps and provide the same capabilities plus more.

->

-> Starting November 1, 2022, you can no longer create new ISE resources. However, ISE resources existing

-> before this date are supported through August 31, 2024. For more information, see the following resources:

->

-> - [ISE Retirement - what you need to know](https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/ise-retirement-what-you-need-to-know/ba-p/3645220)

-> - [Single-tenant versus multi-tenant and integration service environment for Azure Logic Apps](single-tenant-overview-compare.md)

-> - [Azure Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/)

-> - [Export ISE workflows to a Standard logic app](export-from-ise-to-standard-logic-app.md)

-> - [Integration Services Environment will be retired on 31 August 2024 - transition to Logic Apps Standard](https://azure.microsoft.com/updates/integration-services-environment-will-be-retired-on-31-august-2024-transition-to-logic-apps-standard/)

-> - [Cloud Services (classic) deployment model is retiring on 31 August 2024](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/)

-After you create an [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md), you can add resources such as **Consumption** logic apps, integration accounts, and connectors so that they can access the resources in your Azure virtual network. For example, managed ISE connectors that become available after you create your ISE don't automatically appear in the Logic App Designer. Before you can use these ISE connectors, you have to manually [add and deploy those connectors to your ISE](#add-ise-connectors-environment) so that they appear in the Logic App Designer.

-> [!IMPORTANT]

-> For logic apps and integration accounts to work together in an ISE, both must use the *same ISE* as their location.

-## Prerequisites

-* An Azure account and subscription. If you don't have an Azure subscription, [sign up for a free Azure account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* The ISE that you created to run your Consumption logic app workflows

-* To create, add, or update resources that are deployed to an ISE, you need to be assigned the Owner or Contributor role on that ISE, or you have permissions inherited through the Azure subscription or Azure resource group associated with the ISE. For people who don't have owner, contributor, or inherited permissions, they can be assigned the Integration Service Environment Contributor role or Integration Service Environment Developer role. For more information, see [What is Azure role-based access control (Azure RBAC)](../role-based-access-control/overview.md)?

-<a name="create-logic-apps-environment"></a>

-## Create logic apps

-To develop logic apps that run in your integration service environment (ISE), follow these steps:

-1. Find and open your ISE, if not already open. From the ISE menu, under **Settings**, select **Logic apps** > **Add**.

- 

-1. Provide information about the logic app that you want to create, for example:

- 

- | Property | Required | Description |

- |-|-|-|

- | **Logic app name** | Yes | The name for the logic app to create |

- | **Subscription** | Yes | The name for the Azure subscription to use |

- | **Resource group** | Yes | The name for the new or existing Azure resource group to use |

- | **Region** | Yes | The Azure region for your logic app, which matches the location for the ISE that you later select |

- | **Associate with integration service environment*** | Yes | Select this option so you can choose an ISE to use. |

- | **Integration service environment** | Yes | From the list, select the ISE that you want to use, if not already selected. <p><p>**Important**: To use an integration account with your logic app, both must use the same ISE. |

- ||||

-1. When you're done, select **Create**.

-1. Continue [creating your logic app in the usual way](../logic-apps/quickstart-create-example-consumption-workflow.md).

- For differences in how triggers and actions work and how they're labeled when you use an ISE compared to the multi-tenant Logic Apps service, see [Isolated versus multi-tenant in the ISE overview](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#difference).

-1. To manage logic apps and API connections in your ISE, see [Manage your integration service environment](../logic-apps/ise-manage-integration-service-environment.md).

-<a name="create-integration-account-environment"></a>

-## Create integration accounts

-Based on the [ISE SKU](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level) selected at creation, your ISE includes specific integration account usage at no additional cost. Logic apps that exist in an integration service environment (ISE) can reference only integration accounts that exist in the same ISE. So, for an integration account to work with logic apps in an ISE, both the integration account and logic apps must use the *same environment* as their location. For more information about integration accounts and ISEs, see [Integration accounts with ISE](connect-virtual-network-vnet-isolated-environment-overview.md#create-integration-account-environment).

-To create an integration account that uses an ISE, follow these steps:

-1. Find and open your ISE, if not already open. From the ISE menu, under **Settings**, select **Integration accounts** > **Add**.

- 

-1. Provide information about the logic app that you want to create, for example:

- 

- | Property | Required | Description |

- |-|-|-|

- | **Name** | Yes | The name for the integration account that you want to create |

- | **Subscription** | Yes | The name for the Azure subscription that you want to use |

- | **Resource group** | Yes | The name for the Azure resource group (new or existing) to use |

- | **Pricing Tier** | Yes | The pricing tier to use for the integration account |

- | **Location** | Yes | From the list, under **Integration service environments**, select the same ISE that your logic apps use, if not already selected. <p><p>**Important**: To use an integration account with your logic app, both must use the same ISE. |

- ||||

-1. When you're done, select **Create**.

-1. [Link your logic app to your integration account in the usual way](../logic-apps/logic-apps-enterprise-integration-create-integration-account.md#link-account).

-1. Continue by adding resources to your integration account, such as [trading partners](../logic-apps/logic-apps-enterprise-integration-partners.md) and [agreements](../logic-apps/logic-apps-enterprise-integration-agreements.md).

-1. To manage integration accounts in your ISE, see [Manage your integration service environment](../logic-apps/ise-manage-integration-service-environment.md).

-<a name="add-ise-connectors-environment"></a>

-## Add ISE connectors

-After you create your ISE, managed ISE connectors don't automatically appear in the connector picker on the Logic App Designer. Before you can use these ISE connectors, you have to manually add and deploy these connectors to your ISE so that they appear in the Logic App Designer.

-> [!IMPORTANT]

-> Managed ISE connectors currently don't support [tags](../azure-resource-manager/management/tag-support.md).

-> If you set up a policy that enforces tagging, trying to add ISE connectors might fail with an error similar to this example:

->

-> ```json

-> {

-> "error": {

-> "code": "IntergrationServiceEnvironmentManagedApiDefinitionTagsNotSupported",

-> "message": "The tags are not supported in the managed API 'azureblob'."

-> }

-> }

-> ```

->

-> So, to add ISE connectors, you have to either disable or remove your policy.

-1. On your ISE menu, under **Settings**, select **Managed connectors**. On the toolbar, select **Add**.

- 

-1. On the **Add a new managed connector** pane, open the **Find connector** list. Find and select the ISE connector that you want to use but isn't yet deployed in your ISE. When you're done, select **Create**.

- 

- Only ISE connectors that are eligible but not yet deployed to your ISE appear available for you to select. Connectors that are already deployed in your ISE appear unavailable for selection.

-<a name="create-custom-connectors-environment"></a>

-## Create custom connectors

-To use custom connectors in your ISE, create those custom connectors from directly inside your ISE.

-1. Find and open your ISE, if not already open. From the ISE menu, under **Settings**, select **Custom connectors** > **Add**.

- 

-1. Provide the name, Azure subscription, and Azure resource group (new or existing) to use for your custom connector.

-1. From the **Location** list, under the **Integration service environments** section, select the same ISE that your logic apps use, and select **Create**, for example:

- 

-1. Select your new custom connector, and then select **Edit**, for example:

- 

-1. Continue by creating the connector in the usual way from an [OpenAPI definition](/connectors/custom-connectors/define-openapi-definition#import-the-openapi-definition) or [SOAP](/connectors/custom-connectors/create-register-logic-apps-soap-connector#2-define-your-connector).

-1. To manage custom connectors in your ISE, see [Manage your integration service environment](../logic-apps/ise-manage-integration-service-environment.md).

-## Next steps

-* [Manage integration service environments](../logic-apps/ise-manage-integration-service-environment.md)

-| Consumption | - Multitenant Azure Logic Apps <br><br>- Integration service environment (ISE) | - You can enable *either* the system-assigned identity or the user-assigned identity, but not both on your logic app. <br><br>- You can use the managed identity at the logic app resource level and at the connection level. <br><br>- If you create and enable the user-assigned identity, your logic app can have *only one* user-assigned identity at a time. |

-If you follow good DevOps practices, you already use [Azure Resource Manager templates](../azure-resource-manager/management/overview.md) to define and deploy your logic apps and their dependent resources. Resource Manager templates give you the capability to use a single deployment definition and then use parameter files to provide the configuration values to use for each deployment destination. This capability means that you can deploy the same logic app to different environments, for example, development, test, and production. You can also deploy the same logic app to different Azure regions or ISEs, which support disaster recovery strategies that use [paired-regions](../availability-zones/cross-region-replication-azure.md).

-* Both logic app instances have the same host type. So, either both instances are deployed to regions in global multitenant Azure, or both instances are deployed to ISEs, which let your logic apps directly access resources in an Azure virtual network. For best practices and more information about paired regions for BCDR, see [Cross-region replication in Azure: Business continuity and disaster recovery](../availability-zones/cross-region-replication-azure.md).

- For example, both the primary and secondary locations must be ISEs when the primary logic app runs in an ISE and uses [ISE-versioned connectors](../connectors/managed.md#ise-connectors), HTTP actions to call resources in the Azure virtual network, or both. In this scenario, your secondary logic app must also have a similar setup in the secondary location as the primary logic app.

- > [!NOTE]

- > For more advanced scenarios, you can mix both multitenant Azure and an

- > ISE as locations. However, make sure that you consider and understand the

- > [differences between how logic apps run in an ISE versus multitenant Azure](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#difference).

-* If you use ISEs, [make sure that they are scaled out or have enough capacity](../logic-apps/ise-manage-integration-service-environment.md#add-capacity) to handle the load.

-#### Example: Integration service environment

-This example shows the previous primary and secondary logic app instances but deployed to separate ISEs. A single Resource Manager template defines both logic app instances, the dependent resources required by those logic apps, and the ISEs as the deployment locations. Separate parameter files define the configuration values to use for deployment in each location:

-

-> [!NOTE]

-> If your logic app runs in an integration service environment (ISE) and uses only

-> ISE-versioned connectors for on-premises data sources, you don't need the data

-> gateway because ISE connectors provide direct access to the the on-premises resource.

->

-> If no ISE-versioned connector is available for the on-premises resource that you want,

-> your logic app can still create the connection by using a non-ISE connector,

-> which runs in the global multitenant Azure, not your ISE. However, this connection

-> requires the on-premises data gateway.

-description: Learn about accessing Azure virtual networks (VNETs) from Azure Logic Apps using an integration service environment (ISE).

-# Access to Azure virtual networks from Azure Logic Apps using an integration service environment (ISE)

-> [!IMPORTANT]

->

-> On August 31, 2024, the ISE resource will retire, due to its dependency on Azure Cloud Services (classic),

-> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard

-> logic apps so that you can avoid service disruption. Standard logic app workflows run in single-tenant Azure

-> Logic Apps and provide the same capabilities plus more. For example Standard workflows support using private

-> endpoints for inbound traffic so that your workflows can communicate privately and securely with virtual

-> networks. Standard workflows also support virtual network integration for outbound traffic. For more information,

-> review [Secure traffic between virtual networks and single-tenant Azure Logic Apps using private endpoints](secure-single-tenant-workflow-virtual-network-private-endpoint.md).

-Since November 1, 2022, the capability to create new ISE resources is no longer available, which also means that capability to set up your own encryption keys, known as "Bring Your Own Key" (BYOK), during ISE creation using the Logic Apps REST API is also no longer available. However, ISE resources existing before this date are supported through August 31, 2024.

-For more information, see the following resources:

-This overview provides more information about [how an ISE works with a virtual network](#how-ise-works), the [benefits to using an ISE](#benefits), the [differences between the dedicated and multi-tenant Logic Apps service](#difference), and how you can directly access resources that are inside or connected your Azure virtual network.

-<a name="how-ise-works"></a>

-## How an ISE works with a virtual network

-At ISE creation, you select the Azure virtual network where you want Azure to *inject* or deploy your ISE. When you create logic apps and integration accounts that need access to this virtual network, you can select your ISE as the host location for those logic apps and integration accounts. Inside the ISE, logic apps run on dedicated resources separately from others in the multi-tenant Azure Logic Apps environment. Data in an ISE stays in the [same region where you create and deploy that ISE](https://azure.microsoft.com/global-infrastructure/data-residency/).

-

-<a name="benefits"></a>

-## Why use an ISE

-Running logic app workflows in your own separate dedicated instance helps reduce the impact that other Azure tenants might have on your apps' performance, also known as the ["noisy neighbors" effect](https://en.wikipedia.org/wiki/Cloud_computing_issues#Performance_interference_and_noisy_neighbors). An ISE also provides these benefits:

-* Direct access to resources that are inside or connected to your virtual network

- Logic apps that you create and run in an ISE can use [specifically designed connectors that run in your ISE](../connectors/managed.md#ise-connectors). If an ISE connector exists for an on-premises system or data source, you can connect directly without having to use the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md). For more information, see [Dedicated versus multi-tenant](#difference) and [Access to on-premises systems](#on-premises) later in this topic.

-* Continued access to resources that are outside or not connected to your virtual network

- Logic apps that you create and run in an ISE can still use connectors that run in the multi-tenant Logic Apps service when an ISE-specific connector isn't available. For more information, see [Dedicated versus multi-tenant](#difference).

-* Your own static IP addresses, which are separate from the static IP addresses that are shared by the logic apps in the multi-tenant service. You can also set up a single public, static, and predictable outbound IP address to communicate with destination systems. That way, you don't have to set up additional firewall openings at those destination systems for each ISE.

-* Increased limits on run duration, storage retention, throughput, HTTP request and response timeouts, message sizes, and custom connector requests. For more information, see [Limits and configuration for Azure Logic Apps](logic-apps-limits-and-config.md).

-<a name="difference"></a>

-## Dedicated versus multi-tenant

-When you create and run logic apps in an ISE, you get the same user experiences and similar capabilities as the multi-tenant Logic Apps service. You can use all the same built-in triggers, actions, and managed connectors that are available in the multi-tenant Logic Apps service. Some managed connectors offer additional ISE versions. The difference between ISE connectors and non-ISE connectors exists in where they run and the labels that they have in the Logic App Designer when you work within an ISE.

-

-* Built-in triggers and actions, such as HTTP, display the **CORE** label and run in the same ISE as your logic app.

-* Managed connectors that display the **ISE** label are specially designed for ISEs and *always run in the same ISE as your logic app*. For example, here are some [connectors that offer ISE versions](../connectors/managed.md#ise-connectors):<p>

- * Azure Blob Storage, File Storage, and Table Storage

- * Azure Service Bus, Azure Queues, Azure Event Hubs

- * Azure Automation, Azure Key Vault, Azure Event Grid, and Azure Monitor Logs

- * FTP, SFTP-SSH, File System, and SMTP

- * SAP, IBM MQ, IBM DB2, and IBM 3270

- * SQL Server, Azure Synapse Analytics, Azure Cosmos DB

- * AS2, X12, and EDIFACT

- With rare exceptions, if an ISE connector is available for an on-premises system or data source, you can connect directly without using the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md). For more information, see [Access to on-premises systems](#on-premises) later in this topic.

-* Managed connectors that don't display the **ISE** label continue to work for logic apps inside an ISE. These connectors *always run in the multi-tenant Logic Apps service*, not in the ISE.

-* Custom connectors that you create *outside an ISE*, whether or not they require the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md), continue to work for logic apps inside an ISE. However, custom connectors that you create *inside an ISE* won't work with the on-premises data gateway. For more information, see [Access to on-premises systems](#on-premises).

-<a name="on-premises"></a>

-## Access to on-premises systems

-Logic app workflows that run inside an ISE can directly access on-premises systems and data sources that are inside or connected to an Azure virtual network by using these items:<p>

-* The HTTP trigger or action, which displays the **CORE** label

-* The **ISE** connector, if available, for an on-premises system or data source

- If an ISE connector is available, you can directly access the system or data source without the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md). However, if you need to access SQL Server from an ISE and use Windows authentication, you must use the connector's non-ISE version and the on-premises data gateway. The connector's ISE version doesn't support Windows authentication. For more information, see [ISE connectors](../connectors/managed.md#ise-connectors) and [Connect from an integration service environment](../connectors/managed.md#integration-account-connectors).

-* A custom connector

- * Custom connectors that you create *outside an ISE*, whether or not they require the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md), continue to work for logic apps inside an ISE.

- * Custom connectors that you create *inside an ISE* don't work with the on-premises data gateway. However, these connectors can directly access on-premises systems and data sources that are inside or connected to the virtual network that hosts your ISE. So, logic apps that are inside an ISE usually don't need the data gateway when accessing those resources.

-To access on-premises systems and data sources that don't have ISE connectors, are outside your virtual network, or aren't connected to your virtual network, you still have to use the on-premises data gateway. Logic apps within an ISE can continue using connectors that don't have the **CORE** or **ISE** label. Those connectors run in the multi-tenant Logic Apps service, rather than in your ISE.

-<a name="data-at-rest"></a>

-## Encrypted data at rest

-By default, Azure Storage uses Microsoft-managed keys to encrypt your data. Azure Logic Apps relies on Azure Storage to store and automatically [encrypt data at rest](../storage/common/storage-service-encryption.md). This encryption protects your data and helps you meet your organizational security and compliance commitments. For more information about how Azure Storage encryption works, see [Azure Storage encryption for data at rest](../storage/common/storage-service-encryption.md) and [Azure Data Encryption-at-Rest](../security/fundamentals/encryption-atrest.md).

-For more control over the encryption keys used by Azure Storage, ISE supports using and managing your own key using [Azure Key Vault](/azure/key-vault/general/overview). This capability is also known as "Bring Your Own Key" (BYOK), and your key is called a "customer-managed key". However, this capability is available *only when you create your ISE*, not afterwards. You can't disable this key after your ISE is created. Currently, no support exists for rotating a customer-managed key for an ISE.

-* Customer-managed key support for an ISE is available only in the following regions:

- * Azure: West US 2, East US, and South Central US.

- * Azure Government: Arizona, Virginia, and Texas.

-* The key vault that stores your customer-managed key must exist in the same Azure region as your ISE.

-* To support customer-managed keys, your ISE requires that you enable either the [system-assigned or user-assigned managed identity](../active-directory/managed-identities-azure-resources/overview.md#managed-identity-types). This identity lets your ISE authenticate access to secured resources, such as virtual machines and other systems or services, that are in or connected to an Azure virtual network. That way, you don't have to sign in with your credentials.

-* You must give your key vault access to your ISE's managed identity, but the timing depends on which managed identity that you use.

- * **System-assigned managed identity**: Within *30 minutes after* you send the HTTPS PUT request that creates your ISE. Otherwise, ISE creation fails, and you get a permissions error.

- * **User-assigned managed identity**: Before you send the HTTPS PUT request that creates your ISE

-<a name="ise-level"></a>

-## ISE SKUs

-When you create your ISE, you can select the Developer SKU or Premium SKU. This SKU option is available only at ISE creation and can't be changed later. Here are the differences between these SKUs:

-* **Developer**

- Provides a lower-cost ISE that you can use for exploration, experiments, development, and testing, but not for production or performance testing. The Developer SKU includes built-in triggers and actions, Standard connectors, Enterprise connectors, and a single [Free tier](../logic-apps/logic-apps-limits-and-config.md#artifact-number-limits) integration account for a [fixed monthly price](https://azure.microsoft.com/pricing/details/logic-apps).

- > [!IMPORTANT]

- > This SKU has no service-level agreement (SLA), scale up capability,

- > or redundancy during recycling, which means that you might experience

- > delays or downtime. Backend updates might intermittently interrupt service.

- For capacity and limits information, see [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise). To learn how billing works for ISEs, see the [Logic Apps pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing).

-* **Premium**

- Provides an ISE that you can use for production and performance testing. The Premium SKU includes SLA support, built-in triggers and actions, Standard connectors, Enterprise connectors, a single [Standard tier](../logic-apps/logic-apps-limits-and-config.md#artifact-number-limits) integration account, scale up capability, and redundancy during recycling for a [fixed monthly price](https://azure.microsoft.com/pricing/details/logic-apps).

- For capacity and limits information, see [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise). To learn how billing works for ISEs, see the [Logic Apps pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing).

-<a name="endpoint-access"></a>

-## ISE endpoint access

-During ISE creation, you can choose to use either internal or external access endpoints. Your selection determines whether request or webhook triggers on logic apps in your ISE can receive calls from outside your virtual network. These endpoints also affect the way that you can access the inputs and outputs from your logic apps' runs history.

-> [!IMPORTANT]

-> You can select the access endpoint only during ISE creation and can't change this option later.

-* **Internal**: Private endpoints permit calls to logic apps in your ISE where you can view and access inputs and outputs from logic app workflow run history *only from inside your virtual network*.

- > [!IMPORTANT]

- > If you need to use these webhook-based triggers, and the service is outside your virtual network and

- > peered virtual networks, use external endpoints, *not* internal endpoints, when you create your ISE:

- >

- > * Azure DevOps

- > * Azure Event Grid

- > * Common Data Service

- > * Office 365

- > * SAP (multi-tenant version)

- >

- > Also, make sure that you have network connectivity between the private endpoints and the computer from

- > where you want to access the run history. Otherwise, when you try to view your workflow's run history,

- > you get an error that says "Unexpected error. Failed to fetch".

- >

- > 

- >

- > For example, your client computer can exist inside the ISE's virtual network or inside a virtual network that's connected to the ISE's virtual network through peering or a virtual private network.

-* **External**: Public endpoints permit calls to logic app workflows in your ISE where you can view and access inputs and outputs from logic apps' runs history *from outside your virtual network*. If you use network security groups (NSGs), make sure they're set up with inbound rules to allow access to the run history's inputs and outputs.

-To determine whether your ISE uses an internal or external access endpoint, on your ISE's menu, under **Settings**, select **Properties**, and find the **Access endpoint** property:

-

-<a name="pricing-model"></a>

-## Pricing model

-Logic apps, built-in triggers, built-in actions, and connectors that run in your ISE use a fixed pricing plan that differs from the Consumption pricing plan. For more information, see [Azure Logic Apps pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing). For pricing rates, see [Azure Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/).

-<a name="create-integration-account-environment"></a>

-## Integration accounts with ISE

-You can use integration accounts with logic apps inside an integration service environment (ISE). However, those integration accounts must use the *same ISE* as the linked logic apps. Logic apps in an ISE can reference only those integration accounts that are in the same ISE. When you create an integration account, you can select your ISE as the location for your integration account. To learn how pricing and billing work for integration accounts with an ISE, see the [Azure Logic Apps pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing). For pricing rates, see [Azure Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/). For limits information, see [Integration account limits](../logic-apps/logic-apps-limits-and-config.md#integration-account-limits).

-## Next steps

-* [Export ISE workflows to a Standard logic app](export-from-ise-to-standard-logic-app.md)

-description: Learn how to set up a single public outbound IP address for integration service environments (ISEs) in Azure Logic Apps.

-# Set up a single IP address for one or more integration service environments in Azure Logic Apps

-> [!IMPORTANT]

->

-> On August 31, 2024, the ISE resource will retire, due to its dependency on Azure Cloud Services (classic),

-> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard

-> logic apps so that you can avoid service disruption. Standard logic app workflows run in single-tenant Azure

-> Logic Apps and provide the same capabilities plus more.

->

-> Starting November 1, 2022, you can no longer create new ISE resources. However, ISE resources existing

-> before this date are supported through August 31, 2024. For more information, see the following resources:

->

-> - [ISE Retirement - what you need to know](https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/ise-retirement-what-you-need-to-know/ba-p/3645220)

-> - [Single-tenant versus multi-tenant and integration service environment for Azure Logic Apps](single-tenant-overview-compare.md)

-> - [Azure Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/)

-> - [Export ISE workflows to a Standard logic app](export-from-ise-to-standard-logic-app.md)

-> - [Integration Services Environment will be retired on 31 August 2024 - transition to Logic Apps Standard](https://azure.microsoft.com/updates/integration-services-environment-will-be-retired-on-31-august-2024-transition-to-logic-apps-standard/)

-> - [Cloud Services (classic) deployment model is retiring on 31 August 2024](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/)

-When you work with Azure Logic Apps, you can use an integration service environment (ISE) for hosting logic apps that need access to resources in an [Azure virtual network](../virtual-network/virtual-networks-overview.md). When you have multiple ISE instances that need access to other endpoints that have IP restrictions, deploy an [Azure Firewall](../firewall/overview.md) or a [network virtual appliance](../virtual-network/virtual-networks-overview.md#filter-network-traffic) into your virtual network and route outbound traffic through that firewall or network virtual appliance. You can then have all the ISE instances in your virtual network use a single, public, static, and predictable IP address to communicate with the destination systems that you want. That way, you don't have to set up additional firewall openings at your destination systems for each ISE.

-This topic shows how to route outbound traffic through an Azure Firewall, but you can apply similar concepts to a network virtual appliance such as a third-party firewall from the Azure Marketplace. While this topic focuses on setup for multiple ISE instances, you can also use this approach for a single ISE when your scenario requires limiting the number of IP addresses that need access. Consider whether the additional costs for the firewall or virtual network appliance make sense for your scenario. Learn more about [Azure Firewall pricing](https://azure.microsoft.com/pricing/details/azure-firewall/).

-## Prerequisites

-* An Azure firewall that runs in the same virtual network as your ISE. If you don't have a firewall, first [add a subnet](../virtual-network/virtual-network-manage-subnet.md#add-a-subnet) that's named `AzureFirewallSubnet` to your virtual network. You can then [create and deploy a firewall](../firewall/tutorial-firewall-deploy-portal.md#create-a-virtual-network) in your virtual network.

-* An Azure [route table](../virtual-network/manage-route-table.yml). If you don't have one, first [create a route table](../virtual-network/manage-route-table.yml#create-a-route-table). For more information about routing, see [Virtual network traffic routing](../virtual-network/virtual-networks-udr-overview.md).

-## Set up route table

-1. In the [Azure portal](https://portal.azure.com), select the route table, for example:

- 

-1. To [add a new route](../virtual-network/manage-route-table.yml#create-a-route), on the route table menu, select **Routes** > **Add**.

- 

-1. On the **Add route** pane, [set up the new route](../virtual-network/manage-route-table.yml#create-a-route) with a rule that specifies that all the outbound traffic to the destination system follows this behavior:

- * Uses the [**Virtual appliance**](../virtual-network/virtual-networks-udr-overview.md#user-defined) as the next hop type.

- * Goes to the private IP address for the firewall instance as the next hop address.

- To find this IP address, on your firewall menu, select **Overview**, find the address under **Private IP address**, for example:

- 

- Here's an example that shows how such a rule might look:

- 

- | Property | Value | Description |

- |-|-|-|

- | **Route name** | <*unique-route-name*> | A unique name for the route in the route table |

- | **Address prefix** | <*destination-address*> | The address prefix for your destination system where you want outbound traffic to go. Make sure that you use [Classless Inter-Domain Routing (CIDR) notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) for this address. In this example, this address prefix is for an SFTP server, which is described in the section, [Set up network rule](#set-up-network-rule). |

- | **Next hop type** | **Virtual appliance** | The [hop type](../virtual-network/virtual-networks-udr-overview.md#next-hop-types-across-azure-tools) that's used by outbound traffic |

- | **Next hop address** | <*firewall-private-IP-address*> | The private IP address for your firewall |

- |||

-<a name="set-up-network-rule"></a>

-## Set up network rule

-1. In the Azure portal, find and select your firewall. On the firewall menu, under **Settings**, select **Rules**. On the rules pane, select **Network rule collection** > **Add network rule collection**.

- 

-1. In the collection, add a rule that permits traffic to the destination system.

- For example, suppose that you have a logic app that runs in an ISE and needs to communicate with an SFTP server. You create a network rule collection that's named `LogicApp_ISE_SFTP_Outbound`, which contains a network rule named `ISE_SFTP_Outbound`. This rule permits traffic from the IP address of any subnet where your ISE runs in your virtual network to the destination SFTP server by using your firewall's private IP address.

- 

- **Network rule collection properties**

- | Property | Value | Description |

- |-|-|-|

- | **Name** | <*network-rule-collection-name*> | The name for your network rule collection |

- | **Priority** | <*priority-level*> | The order of priority to use for running the rule collection. For more information, see [What are some Azure Firewall concepts](../firewall/firewall-faq.yml#what-are-some-azure-firewall-concepts)? |

- | **Action** | **Allow** | The action type to perform for this rule |

- |||

- **Network rule properties**

- | Property | Value | Description |

- |-|-|-|

- | **Name** | <*network-rule-name*> | The name for your network rule |

- | **Protocol** | <*connection-protocols*> | The connection protocols to use. For example, if you're using NSG rules, select both **TCP** and **UDP**, not only **TCP**. |

- | **Source addresses** | <*ISE-subnet-addresses*> | The subnet IP addresses where your ISE runs and where traffic from your logic app originates |

- | **Destination addresses** | <*destination-IP-address*> | The IP address for your destination system where you want outbound traffic to go. In this example, this IP address is for the SFTP server. |

- | **Destination ports** | <*destination-ports*> | Any ports that your destination system uses for inbound communication |

-

- For more information about network rules, see these articles:

- * [Configure a network rule](../firewall/tutorial-firewall-deploy-portal.md#configure-a-network-rule)

- * [Azure Firewall rule processing logic](../firewall/rule-processing.md#network-rules-and-applications-rules)

- * [Azure PowerShell: New-AzFirewallNetworkRule](/powershell/module/az.network/new-azfirewallnetworkrule)

- * [Azure CLI: az network firewall network-rule](/cli/azure/network/firewall/network-rule#az-network-firewall-network-rule-create)

-## Related content

-* [Azure Firewall FAQ](../firewall/firewall-faq.yml)

-If you use the SAP managed connector or ISE-versioned SAP connector, under the trigger in your workflow, set up a way to explicitly filter out any unwanted actions from your SAP server, based on the root node namespace in the received XML payload. You can provide a list (array) with a single or multiple SAP actions. By default, this array is empty, which means that your workflow receives all the messages from your SAP server without filtering. When you set up the array filter, the trigger receives messages only from the specified SAP action types and rejects all other messages from your SAP server. However, this filter doesn't affect whether the typing of the received payload is weak or strong. Any SAP action filtering happens at the level of the SAP Adapter for your on-premises data gateway. For more information, review [how to test sending IDocs to Azure Logic Apps from SAP](sap.md#test-sending-idocs-from-sap).

-For the Consumption workflows that use the SAP managed connector and ISE-versioned SAP connector, if you have to receive replies by using a remote function call (RFC) to Azure Logic Apps from SAP ABAP, you must implement a request and response pattern. To receive IDocs in your workflow when you use the [**Request** trigger](../../connectors/connectors-native-reqres.md), make sure that the workflow's first action is a [Response action](../../connectors/connectors-native-reqres.md#add-response) that uses the **200 OK** status code without any content. This recommended step immediately completes the SAP Logical Unit of Work (LUW) asynchronous transfer over tRFC, which leaves the SAP CPIC conversation available again. You can then add more actions to your workflow for processing the received IDoc without blocking later transfers.

-* **Option 1:** In your API connection and trigger configuration, replace your gateway service name with its port number. In the example error, `sapgw00` needs to be replaced with a real port number, for example, `3300`. This is the only available option for ISE.

-You might get a similar error when SAP Application server or Message server name resolves to the IP address. For ISE, you must specify the IP address for your SAP Application server or Message server. For the on-premises data gateway, you can instead add the name to the IP address mapping in `%windir%\System32\drivers\etc\hosts`, for example:

-For SAP managed connector and ISE-versioned SAP connector, this error message means unexpected failures happen when the catch-all handler for the channel terminates the channel due to an error, and rebuilds the channel to process other messages.

-> The SAP managed trigger and ISE-versioned SAP triggers are webhooks that use the SOAP-based SAP adapter. However, the SAP built-in trigger is an Azure Functions-based trigger that doesn't use a SOAP SAP adapter and doesn't get this error message.

-You can use SNC for SAP NetWeaver single sign-on (SSO) or for security capabilities from external products. If you choose to use SNC, review the [SNC prerequisites](#snc-prerequisites) and the [SNC prerequisites for the ISE connector](#snc-prerequisites-ise).

-| **Consumption** | Multitenant Azure Logic Apps | Managed connector, which appears in the designer under the **Enterprise** label. For more information, review the following documentation: <br><br>- [SAP managed connector reference](/connectors/sap/) <br>- [Managed connectors in Azure Logic Apps](../../connectors/managed.md) |

-| **Consumption** | Integration service environment (ISE) | Managed connector, which appears in the designer under the **Enterprise** label, and the ISE-native version, which appears in the designer with the **ISE** label and has different message limits than the managed connector. <br><br>**Note**: Make sure to use the ISE-native version, not the managed version. <br><br>For more information, review the following documentation: <br><br>- [SAP managed connector reference](/connectors/sap/) <br>- [ISE message limits](../logic-apps-limits-and-config.md#message-size-limits) <br>- [Managed connectors in Azure Logic Apps](../../connectors/managed.md) |

-The SAP built-in connector significantly differs from the SAP managed connector and SAP ISE-versioned connector in the following ways:

-* Longer timeout at 5 minutes compared to managed connector and ISE-versioned connector.

- The SAP built-in connector doesn't use the shared or global connector infrastructure, which means timeouts are longer at 5 minutes compared to the SAP managed connector (two minutes) and the SAP ISE-versioned connector (four minutes). Long-running requests work without you having to implement the long-running webhook-based request action pattern.

- * For a Consumption workflow in a Premium-level [integration service environment (ISE)](../connect-virtual-network-vnet-isolated-environment-overview.md), see [ISE prerequisites](#ise-prerequisites).

- > [!NOTE]

- >

- > When you use a Premium-level ISE, use the ISE-native SAP connector, not the SAP managed connector,

- > which doesn't natively run in an ISE. For more information, review the [ISE prerequisites](#ise-prerequisites).

- > [!NOTE]

- >

- > In Consumption and Standard workflows, the SAP managed trigger named **When a message is received**

- > uses the same URI location to both renew and unsubscribe from a webhook subscription. The renewal operation

- > uses the HTTP `PATCH` method, while the unsubscribe operation uses the HTTP `DELETE` method. This behavior

- > might make a renewal operation appear as an unsubscribe operation in your trigger's history, but the operation

- > is still a renewal because the trigger uses `PATCH` as the HTTP method, not `DELETE`.

- >

- > In Standard workflows, the SAP built-in trigger named **When a message is received** uses the Azure

- > Functions trigger instead, and shows only the actual callbacks from SAP.

-* For Consumption logic app workflows in an ISE, the ISE virtual network hosts the SAP .NET Connector (NCo) library.

-* From the client library's default installation folder, copy the assembly (.dll) files to another location, based on your scenario as follows. Or, optionally, if you're using only the SAP managed connector, when you install the SAP NCo client library, select **Global Assembly Cache registration**. The ISE zip archive and SAP built-in connector currently doesn't support GAC registration.

- * For a Consumption workflow in an ISE, follow the [ISE prerequisites](#ise-prerequisites) instead.

-### [ISE](#tab/ise)

-<a name="snc-prerequisites-ise"></a>

-The ISE-versioned SAP connector supports SNC X.509, not single sign-on (SSO) authentication. If you previously used the SAP connector without SNC, you can enable SNC for ISE-native SAP connections.

-Before you redeploy an SAP connector to use SNC, or if you deployed the SAP connector without the SNC or SAPGENPSE libraries, you must delete all previously existing SAP connections and then the SAP connector. Multiple logic app workflows can use the same SAP connection. So, make sure that you delete any previously existing SAP connections from all logic app workflows in your ISE.

-After you delete the SAP connections, you must delete the SAP connector from your ISE. You can still keep the logic app workflows that use this connector. After you redeploy the connector, you can then authenticate the new connection in your workflows' SAP operations.

-1. To delete existing SAP connections, follow either path:

- * In the [Azure portal](https://portal.azure.com), open each logic app resource and workflow to delete the SAP connections.

- 1. Open your logic app workflow in the designer.

- 1. On your logic app menu, under **Development Tools**, select **API connections**.

- 1. On the **API connections** page, select your SAP connection.

- 1. On the connection's page menu, select **Delete**.

- 1. Accept the confirmation prompt to delete the connection.

- 1. Wait for the portal notification that the connection has been deleted.

- * In the [Azure portal](https://portal.azure.com), open your ISE resource to delete the SAP connections.

- 1. On your ISE menu, under **Settings**, select **API connections**.

- 1. On the **API connections** page, select your SAP connection.

- 1. On the connection's page menu, select **Delete**.

- 1. Accept the confirmation prompt to delete the connection.

- 1. Wait for the portal notification that the connection has been deleted.

-1. Delete the SAP connector from your ISE. You must delete all connections to this connector in all your logic app workflows before you can delete the connector. If you haven't already deleted all connections, review the previous steps.

- 1. In the [Azure portal](https://portal.azure.com), open your ISE resource.

- 1. On your ISE menu, under **Settings**, select **Managed connectors**.

- 1. On the **Managed connectors** page, select the checkbox for the SAP connector.

- 1. On the toolbar, select **Delete**.

- 1. Accept the confirmation prompt to delete the connector.

- 1. Wait for the portal notification that the connector has been deleted.

-1. Deploy or redeploy the SAP connector in your ISE.

- 1. Prepare a new zip archive file to use in your SAP connector deployment. You must include the SNC library and the SAPGENPSE utility.

- * You must use the 64-bit SNC library. There's no 32-bit support.

- * Your SNC library and dependencies must be compatible with your SAP environment. For how to check compatibility, the [ISE prerequisites](#ise-prerequisites).

- 1. Copy all SNC, SAPGENPSE, and NCo libraries to the root folder of your zip archive. Don't put these binaries in a subfolder.

- 1. For your new zip archive, follow the deployment steps in [ISE prerequisites](#ise-prerequisites).

-1. For each workflow that uses the ISE-native SAP connector, [create a new SAP connection that enables SNC](#enable-secure-network-communications).

-#### Certificate rotation

-1. For all connections that use SAP ISE X.509 in your ISE, update the base64-encoded binary PSE.

-1. In your copy of the PSE, import the new certificates.

-1. Encode the PSE file as a base64-encoded binary.

-1. Edit your SAP connection information, and save the new PSE file there.

- The connector detects the PSE change and updates its own copy during the next connection request.

-### [ISE](#tab/ise)

-<a name="ise-prerequisites"></a>

-For a Consumption workflow in an ISE, the ISE provides access to resources that are protected by an Azure virtual network and offers other ISE-native connectors that let workflows directly access on-premises resources without having to use the on-premises data gateway.

-> [!IMPORTANT]

->

-> On August 31, 2024, the ISE resource will retire, due to its dependency on Azure Cloud Services (classic),

-> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard

-> logic apps so that you can avoid service disruption. Standard logic app workflows run in single-tenant Azure

-> Logic Apps and provide the same capabilities plus more.

->

-> Starting November 1, 2022, you can no longer create new ISE resources. However, ISE resources existing

-> before this date are supported through August 31, 2024. For more information, see the following resources:

->

-> - [ISE Retirement - what you need to know](https://techcommunity.microsoft.com/t5/azure-integration-services-blog/ise-retirement-what-you-need-to-know/ba-p/3645220)

-> - [Single-tenant versus multitenant and integration service environment for Azure Logic Apps](../single-tenant-overview-compare.md)

-> - [Azure Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/)

-> - [Export ISE workflows to a Standard logic app](../export-from-ise-to-standard-logic-app.md)

-> - [Integration Services Environment will be retired on 31 August 2024 - transition to Logic Apps Standard](https://azure.microsoft.com/updates/integration-services-environment-will-be-retired-on-31-august-2024-transition-to-logic-apps-standard/)

-> - [Cloud Services (classic) deployment model is retiring on 31 August 2024](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/)

-1. If you don't already have an Azure Storage account with a blob container, create a container using either the [Azure portal](../../storage/blobs/storage-quickstart-blobs-portal.md) or [Azure Storage Explorer](../../storage/blobs/quickstart-storage-explorer.md).

-1. On your local computer, [download and install the latest SAP NCo client library](#sap-client-library-prerequisites). You should have the following assembly (.dll) files:

- * **libicudecnumber.dll**

- * **rscp4n.dll**

- * **sapnco.dll**

- * **sapnco_utils.dll**

-1. From the root folder, create a .zip file that includes these assembly files. Upload the package to your blob container in Azure Storage.

- > [!NOTE]

- >

- > Don't use a subfolder inside the .zip file. Only assemblies in the archive's root folder

- > are deployed with the SAP connector in your ISE.

- >

- > If you use SNC, also include the SNC assemblies and binaries in the same .zip file at the root.

- > For more information, review the [SNC prerequisites for ISE](#snc-prerequisites-ise).

-1. In either the Azure portal or Azure Storage Explorer, browse to the container location where you uploaded the .zip file.

-1. Copy the URL for the container location. Make sure to include the Shared Access Signature (SAS) token, so the SAS token is authorized. Otherwise, deployment for the SAP ISE connector fails.

-1. In your ISE, install and deploy the SAP connector. For more information, review [Add ISE connectors](../add-artifacts-integration-service-environment-ise.md#add-ise-connectors-environment).

- 1. In the [Azure portal](https://portal.azure.com), find and open your ISE.

- 1. On the ISE menu, select **Managed connectors** &gt; **Add**. From the connectors list, find and select **SAP**.

- 1. On the **Add a new managed connector** pane, in the **SAP package** box, paste the URL for the .zip file that has the SAP assemblies. Again, make sure to include the SAS token.

- 1. Select **Create** to finish creating your ISE connector.

-1. If your SAP instance and ISE are in different virtual networks, you also need to [peer those networks](../../virtual-network/tutorial-connect-virtual-networks-portal.md) so they're connected. Review the [SNC prerequisites for ISE](#snc-prerequisites-ise).

-1. Get the IP addresses for the SAP Application, Message, and Gateway servers that you plan to use for connecting from your workflow. Network name resolution isn't available for SAP connections in an ISE.

-1. Get the port numbers for the SAP Application, Message, and Gateway services that you plan to use for connecting from your workflow. Service name resolution isn't available for SAP connections in an ISE.

- | **SAP_PSE** | <*PSE-value*> | Enter your SNC Personal Security Environment (PSE) as a base64-encoded binary. <br><br>- Your PSE must contain the private key for the client certificate where the thumbprint matches the public key for the client certificate in the **SNC Certificate** parameter. <br><br>- Although your PSE might contain multiple client certificates, to use different client certificates, create separate workflows instead. <br><br>- The PSE must have no PIN. If necessary, set the PIN to empty using the SAPGENPSE utility. <br><br>- If you're using more than one SNC client certificate for your ISE, you must provide the same PSE for all connections. Your PSE must contain the matching private key for the client certificate for each and all the connections. You must set the **SNC Certificate** to match the specific private certificate for each connection. |

-### [ISE](#tab/ise)

-For a Consumption workflow that runs in an ISE, you can enable SNC for authentication. Before you start, make sure that you met all the necessary [prerequisites](#prerequisites) and [SNC prerequisites for ISE](#snc-prerequisites-ise).

-1. In the [Azure portal](https://portal.azure.com), open your ISE resource and logic app workflow in the designer.

-1. Add or edit an *ISE-versioned* SAP connector operation. Make sure that the SAP connector operation displays the **ISE** label.

-1. In the SAP connection information box, provide the following [required information](/connectors/sap/#default-connection). The **Authentication Type** that you select changes the available options.

- 

- > [!NOTE]

- >

- > The **SAP Username** and **SAP Password** fields are optional. If you don't provide a username

- > and password, the connector uses the client certificate provided in a later step for authentication.

-1. To enable SNC, in the SAP connection information box, provide the following required information instead:

- 

- | Parameter | Description |

- |--|-|

- | **Use SNC** | Select the checkbox. |

- | **SNC Library** | Enter the name for your SNC library, for example, **sapcrypto.dll**. |

- | **SNC Partner Name** | Enter the name for the backend SNC, for example, **p:CN=DV3, OU=LA, O=MS, C=US**. |

- | **SNC My Name** and **SNC Quality of Protection** | Optional: Enter these values, as necessary. |

- | **SNC Certificate** | Enter your SNC client's public certificate in base64-encoded format with the following guidance: <br><br>- Don't include the PEM header or footer. <br><br>- Don't enter the private certificate here because the Personal Security Environment (PSE) might contain multiple private certificates. However, this **SNC Certificate** parameter identifies the certificates that this connection must use. For more information, review the next parameter. |

- | **PSE** (Personal Security Environment) | Enter your SNC PSE as a base64-encoded binary with the following guidance: <br><br>- The PSE must contain the private client certificate where the thumbprint matches the public client certificate that you provided in the previous step. <br><br>- Although the PSE might contain multiple client certificates. to use different client certificates, create separate workflow apps instead. <br><br>- The PSE must have no PIN. If necessary, set the PIN to empty using the SAPGENPSE utility. <br><br>- If you're using more than one SNC client certificate for your ISE, you must provide the same PSE for all connections. The PSE must contain the client private certificate for each and all the connections. You must set the client public certificate parameter to match the specific private certificate for each connection used in your ISE. |

-1. To finish creating your connection, select **Create**.

- If the parameters are correct, the connection is created. If there's a problem with the parameters, the connection creation dialog displays an error message. To troubleshoot connection parameter issues, you can use an on-premises data gateway and the gateway's local logs.

-### [ISE](#tab/ise)

-See the steps for [SAP logging for Consumption logic apps in multitenant workflows](?tabs=consumption#test-workflow-logging).

- | **Pricing Tier** | Yes | <*pricing-level*> | The pricing tier for the integration account, which you can change later. For this example, select **Free**. For more information, review the following documentation: <br><br>- [Logic Apps pricing model](../logic-apps-pricing.md#integration-accounts) <br>- [Logic Apps limits and configuration](../logic-apps-limits-and-config.md#integration-account-limits) <br>- [Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/) |

- | **Region** | Yes | <*Azure-region*> | The Azure region where to store your integration account metadata. Either select the same location as your logic app resource, or create your logic apps in the same location as your integration account. For this example, use **West US**. <br><br>To use your integration account with an [integration service environment (ISE)](../connect-virtual-network-vnet-isolated-environment-overview.md), select **Associate with integration service environment**, and then select your ISE as the location. To create an integration account from inside an ISE, see [Create integration accounts from inside an ISE](../add-artifacts-integration-service-environment-ise.md#create-integration-account-environment). <br><br>**Note**: The ISE resource will retire on August 31, 2024, due to its dependency on Azure Cloud Services (classic), which retires at the same time. Currently in preview, the capability is available for you to [export a Standard integration account for an ISE to a Premium integration account](../ise-manage-integration-service-environment.md#export-integration-account). |

-This article provides information about the export process and shows how to export your logic app workflows from an ISE to a local Standard logic app project in Visual Studio Code.

-description: Check network health and manage logic apps, connections, custom connectors, and integration accounts in your integration service environment (ISE) for Azure Logic Apps.

-# Manage your integration service environment (ISE) in Azure Logic Apps

-> [!IMPORTANT]

->

-> On August 31, 2024, the ISE resource will retire, due to its dependency on Azure Cloud Services (classic),

-> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard

-> logic apps so that you can avoid service disruption. Standard logic app workflows run in single-tenant Azure

-> Logic Apps and provide the same capabilities plus more.

->

-> Starting November 1, 2022, you can no longer create new ISE resources. However, ISE resources existing

-> before this date are supported through August 31, 2024. For more information, see the following resources:

->

-> - [ISE Retirement - what you need to know](https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/ise-retirement-what-you-need-to-know/ba-p/3645220)

-> - [Single-tenant versus multitenant and integration service environment for Azure Logic Apps](single-tenant-overview-compare.md)

-> - [Azure Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/)

-> - [Export ISE workflows to a Standard logic app](export-from-ise-to-standard-logic-app.md)

-> - [Integration Services Environment will be retired on 31 August 2024 - transition to Logic Apps Standard](https://azure.microsoft.com/updates/integration-services-environment-will-be-retired-on-31-august-2024-transition-to-logic-apps-standard/)

-> - [Cloud Services (classic) deployment model is retiring on 31 August 2024](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/)

-This article shows how to perform management tasks for your [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md), for example:

-* Find and view your ISE.

-* Enable access for your ISE.

-* Check your ISE's network health.

-* Manage the resources such as multitenant based logic apps, connections, integration accounts, and connectors in your ISE.

-* Add capacity, restart your ISE, or delete your ISE, follow the steps in this topic. To add these artifacts to your ISE, see [Add artifacts to your integration service environment](../logic-apps/add-artifacts-integration-service-environment-ise.md).

-## View your ISE

-1. In the [Azure portal](https://portal.azure.com) search box, enter **integration service environments**, and select **Integration Service Environments**.

- 

-1. From the results list, select your integration service environment.

- 

-1. Continue to the next sections to find logic apps, connections, connectors, or integration accounts in your ISE.

-## Enable access for your ISE

-When you use an ISE with an Azure virtual network, a common setup problem is having one or more blocked ports. The connectors that you use for creating connections between your ISE and destination systems might also have their own port requirements. For example, if you communicate with an FTP system by using the FTP connector, the port that you use on your FTP system needs to be available, for example, port 21 for sending commands.

-To make sure that your ISE is accessible and that the logic apps in that ISE can communicate across each subnet in your virtual network, [open the ports described in this table for each subnet](#network-ports-for-ise). If any required ports are unavailable, your ISE won't work correctly.

-* If you have multiple ISE instances that need access to other endpoints that have IP restrictions, deploy an [Azure Firewall](../firewall/overview.md) or a [network virtual appliance](../virtual-network/virtual-networks-overview.md#filter-network-traffic) into your virtual network and route outbound traffic through that firewall or network virtual appliance. You can then [set up a single, outbound, public, static, and predictable IP address](connect-virtual-network-vnet-set-up-single-ip-address.md) that all the ISE instances in your virtual network can use to communicate with destination systems. That way, you don't have to set up extra firewall openings at those destination systems for each ISE.

- > [!NOTE]

- > You can use this approach for a single ISE when your scenario requires limiting the

- > number of IP addresses that need access. Consider whether the extra costs for

- > the firewall or virtual network appliance make sense for your scenario. Learn more about

- > [Azure Firewall pricing](https://azure.microsoft.com/pricing/details/azure-firewall/).

-* If you created a new Azure virtual network and subnets without any constraints, you don't need to set up [network security groups (NSGs)](../virtual-network/network-security-groups-overview.md#network-security-groups) in your virtual network to control traffic across subnets.

-* For an existing virtual network, you can *optionally* set up [network security groups (NSGs)](../virtual-network/network-security-groups-overview.md#network-security-groups) to [filter network traffic across subnets](../virtual-network/tutorial-filter-network-traffic.md). If you want to go this route, or if you're already using NSGs, make sure that you [open the ports described in this table](#network-ports-for-ise) for those NSGs.

- When you set up [NSG security rules](../virtual-network/network-security-groups-overview.md#security-rules), you need to use *both* the **TCP** and **UDP** protocols, or you can select **Any** instead so you don't have to create separate rules for each protocol. NSG security rules describe the ports that you must open for the IP addresses that need access to those ports. Make sure that any firewalls, routers, or other items that exist between these endpoints also keep those ports accessible to those IP addresses.

-* For an ISE that has *external* endpoint access, you must create a network security group (NSG), if you don't have one already. You need to add an inbound security rule to the NSG to allow traffic from managed connector outbound IP addresses. To set up this rule, follow these steps:

- 1. On your ISE menu, under **Settings**, select **Properties**.

- 1. Under **Connector outgoing IP addresses**, copy the public IP address ranges, which also appear in this article, [Limits and configuration - Outbound IP addresses](logic-apps-limits-and-config.md#outbound).

- 1. Create a network security group, if you don't have one already.

-

- 1. Based on the following information, add an inbound security rule for the public outbound IP addresses that you copied. For more information, review [Tutorial: Filter network traffic with a network security group using the Azure portal](../virtual-network/tutorial-filter-network-traffic.md#create-a-network-security-group).

- | Purpose | Source service tag or IP addresses | Source ports | Destination service tag or IP addresses | Destination ports | Notes |

- |||--|--|-|-|

- | Permit traffic from connector outbound IP addresses | <*connector-public-outbound-IP-addresses*> | * | Address space for the virtual network with ISE subnets | * | |

-* If you set up forced tunneling through your firewall to redirect Internet-bound traffic, review the [forced tunneling requirements](#forced-tunneling).

-<a name="network-ports-for-ise"></a>

-### Network ports used by your ISE

-This table describes the ports that your ISE requires to be accessible and the purpose for those ports. To help reduce complexity when you set up security rules, the table uses [service tags](../virtual-network/service-tags-overview.md) that represent groups of IP address prefixes for a specific Azure service. Where noted, *internal ISE* and *external ISE* refer to the access endpoint that's selected during ISE creation. For more information, see [Endpoint access](connect-virtual-network-vnet-isolated-environment-overview.md#endpoint-access).

-> [!IMPORTANT]

->

-> For all rules, make sure that you set source ports to `*` because source ports are ephemeral.

-#### Inbound security rules

-| Source ports | Destination ports | Source service tag or IP addresses | Destination service tag or IP addresses | Purpose | Notes |

-|--|-||--||-|

-| * | * | Address space for the virtual network with ISE subnets | Address space for the virtual network with ISE subnets | Intersubnet communication within virtual network. | Required for traffic to flow *between* the subnets in your virtual network. <br><br>**Important**: For traffic to flow between the *components* in each subnet, make sure that you open all the ports within each subnet. |

-| * | 443 | Internal ISE: <br>**VirtualNetwork** <br><br>External ISE: **Internet** or see **Notes** | **VirtualNetwork** | - Communication to your logic app <br><br>- Runs history for your logic app | Rather than use the **Internet** service tag, you can specify the source IP address for these items: <br><br>- The computer or service that calls any request triggers or webhooks in your logic app <br><br>- The computer or service from where you want to access logic app runs history <br><br>**Important**: Closing or blocking this port prevents calls to logic apps that have request triggers or webhooks. You're also prevented from accessing inputs and outputs for each step in runs history. However, you're not prevented from accessing logic app runs history. |

-| * | 454 | **LogicAppsManagement** |**VirtualNetwork** | Azure Logic Apps designer - dynamic properties| Requests come from the Azure Logic Apps access endpoint's [inbound IP addresses](logic-apps-limits-and-config.md#inbound) for that region. <br><br>**Important**: If you're working with Azure Government cloud, the **LogicAppsManagement** service tag won't work. Instead, you have to provide the Azure Logic Apps [inbound IP addresses](logic-apps-limits-and-config.md#azure-government-inbound) for Azure Government. |

-| * | 454 | **LogicApps** | **VirtualNetwork** | Network health check | Requests come from the Azure Logic Apps access endpoint's [inbound IP addresses](logic-apps-limits-and-config.md#inbound) and [outbound IP addresses](logic-apps-limits-and-config.md#outbound) for that region. <br><br>**Important**: If you're working with Azure Government cloud, the **LogicApps** service tag won't work. Instead, you have to provide both the Azure Logic Apps [inbound IP addresses](logic-apps-limits-and-config.md#azure-government-inbound) and [outbound IP addresses](logic-apps-limits-and-config.md#azure-government-outbound) for Azure Government. |

-| * | 454 | **AzureConnectors** | **VirtualNetwork** | Connector deployment | Required to deploy and update connectors. Closing or blocking this port causes ISE deployments to fail and prevents connector updates and fixes. <br><br>**Important**: If you're working with Azure Government cloud, the **AzureConnectors** service tag won't work. Instead, you have to provide the [managed connector outbound IP addresses](logic-apps-limits-and-config.md#azure-government-outbound) for Azure Government. |

-| * | 454, 455 | **AppServiceManagement** | **VirtualNetwork** | App Service Management dependency ||

-| * | Internal ISE: 454 <br><br>External ISE: 443 | **AzureTrafficManager** | **VirtualNetwork** | Communication from Azure Traffic Manager ||

-| * | 3443 | **APIManagement** | **VirtualNetwork** | Connector policy deployment <br><br>API Management - management endpoint | For connector policy deployment, port access is required to deploy and update connectors. Closing or blocking this port causes ISE deployments to fail and prevents connector updates and fixes. |

-| * | 6379 - 6383, plus see **Notes** | **VirtualNetwork** | **VirtualNetwork** | Access Azure Cache for Redis Instances between Role Instances | For ISE to work with Azure Cache for Redis, you must open these [outbound and inbound ports described by the Azure Cache for Redis FAQ](../azure-cache-for-redis/cache-how-to-premium-vnet.md#outbound-port-requirements). |

-#### Outbound security rules

-| Source ports | Destination ports | Source service tag or IP addresses | Destination service tag or IP addresses | Purpose | Notes |

-|--|-||--||-|

-| * | * | Address space for the virtual network with ISE subnets | Address space for the virtual network with ISE subnets | Intersubnet communication within virtual network | Required for traffic to flow *between* the subnets in your virtual network. <br><br>**Important**: For traffic to flow between the *components* in each subnet, make sure that you open all the ports within each subnet. |

-| * | 443, 80 | **VirtualNetwork** | Internet | Communication from your logic app | This rule is required for Secure Socket Layer (SSL) certificate verification. This check is for various internal and external sites, which is the reason that the Internet is required as the destination. |

-| * | Varies based on destination | **VirtualNetwork** | Varies based on destination | Communication from your logic app | Destination ports vary based on the endpoints for the external services with which your logic app needs to communicate. <br><br>For example, the destination port is port 25 for an SMTP service, port 22 for an SFTP service, and so on. |

-| * | 80, 443 | **VirtualNetwork** | **AzureActiveDirectory** | Microsoft Entra ID ||

-| * | 80, 443, 445 | **VirtualNetwork** | **Storage** | Azure Storage dependency ||

-| * | 443 | **VirtualNetwork** | **AppService** | Connection management ||

-| * | 443 | **VirtualNetwork** | **AzureMonitor** | Publish diagnostic logs & metrics ||

-| * | 1433 | **VirtualNetwork** | **SQL** | Azure SQL dependency ||

-| * | 1886 | **VirtualNetwork** | **AzureMonitor** | Azure Resource Health | Required for publishing health status to Resource Health. |

-| * | 5672 | **VirtualNetwork** | **EventHub** | Dependency from Log to Event Hubs policy and monitoring agent ||

-| * | 6379 - 6383, plus see **Notes** | **VirtualNetwork** | **VirtualNetwork** | Access Azure Cache for Redis Instances between Role Instances | For ISE to work with Azure Cache for Redis, you must open these [outbound and inbound ports described by the Azure Cache for Redis FAQ](../azure-cache-for-redis/cache-how-to-premium-vnet.md#outbound-port-requirements). |

-| * | 53 | **VirtualNetwork** | IP addresses for any custom Domain Name System (DNS) servers on your virtual network | DNS name resolution | Required only when you use custom DNS servers on your virtual network |

-In addition, you need to add outbound rules for [App Service Environment (ASE)](../app-service/environment/intro.md):

-* If you use Azure Firewall, you need to set up your firewall with the App Service Environment (ASE) [fully qualified domain name (FQDN) tag](../firewall/fqdn-tags.md#current-fqdn-tags), which permits outbound access to ASE platform traffic.

-* If you use a firewall appliance other than Azure Firewall, you need to set up your firewall with *all* the rules listed in the [firewall integration dependencies](../app-service/environment/firewall-integration.md#dependencies) that are required for App Service Environment.

-<a name="forced-tunneling"></a>

-#### Forced tunneling requirements

-If you set up or use [forced tunneling](../firewall/forced-tunneling.md) through your firewall, you have to permit extra external dependencies for your ISE. Forced tunneling lets you redirect Internet-bound traffic to a designated next hop, such as your virtual private network (VPN) or to a virtual appliance, rather than to the Internet so that you can inspect and audit outbound network traffic.

-If you don't permit access for these dependencies, your ISE deployment fails and your deployed ISE stops working.

-* User-defined routes

- To prevent asymmetric routing, you must define a route for each and every IP address that's listed below with **Internet** as the next hop.

- * [Azure Logic Apps inbound and outbound addresses for the ISE region](logic-apps-limits-and-config.md#firewall-configuration-ip-addresses-and-service-tags)

- * [Azure IP addresses for connectors in the ISE region, available in this download file](https://www.microsoft.com/download/details.aspx?id=56519)

- * [App Service Environment management addresses](../app-service/environment/management-addresses.md)

- * [Azure Traffic Manager management addresses](/azure/traffic-manager/traffic-manager-faqs#what-are-the-ip-addresses-from-which-the-health-checks-originate)

- * [Azure API Management Control Plane IP addresses](../api-management/virtual-network-reference.md#control-plane-ip-addresses)

-* Service endpoints

- You need to enable service endpoints for Azure SQL, Storage, Service Bus, KeyVault, and Event Hubs because you can't send traffic through a firewall to these services.

-* Other inbound and outbound dependencies

- Your firewall *must* allow the following inbound and outbound dependencies:

- * [Azure App Service Dependencies](../app-service/environment/firewall-integration.md#deploying-your-ase-behind-a-firewall)

- * [Azure Cache Service Dependencies](../azure-cache-for-redis/cache-how-to-premium-vnet.md#what-are-some-common-misconfiguration-issues-with-azure-cache-for-redis-and-virtual-networks)

- * [Azure API Management Dependencies](../api-management/virtual-network-reference.md)

-<a name="check-network-health"></a>

-## Check network health

-On your ISE menu, under **Settings**, select **Network health**. This pane shows the health status for your subnets and outbound dependencies on other services.

-

-> [!CAUTION]

-> If your ISE's network becomes unhealthy, the internal App Service Environment (ASE) that's used by your ISE can also become unhealthy.

-> If the ASE is unhealthy for more than seven days, the ASE is suspended. To resolve this state, check your virtual network setup.

-> Resolve any problems that you find, and then restart your ISE. Otherwise, after 90 days, the suspended ASE is deleted, and your

-> ISE becomes unusable. So, make sure that you keep your ISE healthy to permit the necessary traffic.

->

-> For more information, see these topics:

->

-> * [Azure App Service diagnostics overview](../app-service/overview-diagnostics.md)

-> * [Message logging for Azure App Service Environment](../app-service/environment/using-an-ase.md#logging)

-<a name="find-logic-apps"></a>

-## Manage your logic apps

-You can view and manage the logic apps that are in your ISE.

-1. On your ISE menu, under **Settings**, select **Logic apps**.

- 

-1. To remove logic apps that you no longer need in your ISE, select those logic apps, and then select **Delete**. To confirm that you want to delete, select **Yes**.

-> [!NOTE]

-> If you delete and recreate a child logic app, you must resave the parent logic app. The recreated child app will have different metadata.

-> If you don't resave the parent logic app after recreating its child, your calls to the child logic app will fail with an error of "unauthorized".

-> This behavior applies to parent-child logic apps, for example, those that use artifacts in integration accounts or call Azure functions.

-<a name="find-api-connections"></a>

-## Manage API connections

-You can view and manage the connections that were created by the logic apps running in your ISE.

-1. On your ISE menu, under **Settings**, select **API connections**.

- 

-1. To remove connections that you no longer need in your ISE, select those connections, and then select **Delete**. To confirm that you want to delete, select **Yes**.

-<a name="manage-api-connectors"></a>

-## Manage ISE connectors

-You can view and manage the API connectors that are deployed to your ISE.

-1. On your ISE menu, under **Settings**, select **Managed connectors**.

- 

-1. To remove connectors that you don't want available in your ISE, select those connectors, and then select **Delete**. To confirm that you want to delete, select **Yes**.

-<a name="find-custom-connectors"></a>

-## Manage custom connectors

-You can view and manage the custom connectors that you deployed to your ISE.

-1. On your ISE menu, under **Settings**, select **Custom connectors**.

- 

-1. To remove custom connectors that you no longer need in your ISE, select those connectors, and then select **Delete**. To confirm that you want to delete, select **Yes**.

-<a name="find-integration-accounts"></a>

-## Manage integration accounts

-1. On your ISE menu, under **Settings**, select **Integration accounts**.

- 

-1. To remove integration accounts from your ISE when no longer needed, select those integration accounts, and then select **Delete**.

-<a name="export-integration-account"></a>

-## Export integration account (preview)

-For a Standard integration account created from inside an ISE, you can export that integration account to an existing Premium integration account. The export process has two steps: export the artifacts, and then export the agreement states. Artifacts include partners, agreements, certificates, schemas, and maps. However, the export process currently doesn't support assemblies and RosettaNet PIPs.

-Your integration account also stores the runtime states for specific B2B actions and EDI standards, such as the MIC number for AS2 actions and the control numbers for X12 actions. If you configured your agreements to update these states every time that a transaction is processed and to use these states for message reconciliation and duplicate detection, make sure that you also export these states. You can export either all agreement states or one agreement state at a time.

-> [!IMPORTANT]

->

-> Make sure to choose a time window when your source integration account doesn't have any activity in your agreements to avoid state inconsistencies.

-### Prerequisites

-If you don't have a Premium integration account, [create a Premium integration account](./enterprise-integration/create-integration-account.md).

-### Export artifacts

-This process copies artifacts from the source to the destination.

-1. In the [Azure portal](https://portal.azure.com), open your Standard integration account.

-1. On the integration account menu, under **Settings**, select **Export**.

- > [!NOTE]

- >

- > If the **Export** option doesn't appear, make sure that you selected a Standard integration account that was created from inside an ISE.

-1. On the **Export** page toolbar, select **Export Artifacts**.

-1. Open the **Target integration account** list, which contains all the Premium accounts in your Azure subscription, select the Premium integration account that you want, and then select **OK**.

- The **Export** page now shows the export status for your artifacts.

-1. To confirm the exported artifacts, open your destination Premium integration account.

-### Export agreement state (optional)

-1. On the **Export** page toolbar, select **Export Agreement State**.

-1. On the **Export Agreement State** pane, open the **Target integration account** list, and select the Premium integration account that you want.

-1. To export all agreement states, don't select any agreement from the **Agreement** list. To export an individual agreement state, select an agreement from the **Agreement** list.

-1. When you're done, select **OK**.

- The **Export** page now shows the export status for your agreement states.

-<a name="add-capacity"></a>

-## Add ISE capacity

-The Premium ISE base unit has fixed capacity, so if you need more throughput, you can add more scale units, either during creation or afterwards. The Developer SKU doesn't include the capability to add scale units.

-> [!IMPORTANT]

-> Scaling out an ISE can take 20-30 minutes on average.

-1. In the [Azure portal](https://portal.azure.com), go to your ISE.

-1. To review usage and performance metrics for your ISE, on your ISE menu, select **Overview**.

- 

-1. Under **Settings**, select **Scale out**. On the **Configure** pane, select from these options:

- * [**Manual scale**](#manual-scale): Scale based on the number of processing units that you want to use.

- * [**Custom autoscale**](#custom-autoscale): Scale based on performance metrics by selecting from various criteria and specifying the threshold conditions for meeting that criteria.

- 

-<a name="manual-scale"></a>

-### Manual scale

-1. After you select **Manual scale**, for **Additional capacity**, select the number of scaling units that you want to use.

- 

-1. When you're done, select **Save**.

-<a name="custom-autoscale"></a>

-### Custom autoscale

-1. After you select **Custom autoscale**, for **Autoscale setting name**, provide a name for your setting and optionally, select the Azure resource group where the setting belongs.

- 

-1. For the **Default** condition, select either **Scale based on a metric** or **Scale to a specific instance count**.

- * If you choose instance-based, enter the number for the processing units, which is a value from 0 to 10.

- * If you choose metric-based, follow these steps:

- 1. In the **Rules** section, select **Add a rule**.

- 1. On the **Scale rule** pane, set up your criteria and action to take when the rule triggers.

- 1. For **Instance limits**, specify these values:

- * **Minimum**: The minimum number of processing units to use

- * **Maximum**: The maximum number of processing units to use

- * **Default**: If any problems happen while reading the resource metrics, and the current capacity is below the default capacity, autoscaling scales out to the default number of processing units. However, if the current capacity exceeds the default capacity, autoscaling doesn't scale in.

-1. To add another condition, select **Add scale condition**.

-1. When you're finished with your autoscale settings, save your changes.

-<a name="restart-ISE"></a>

-## Restart ISE

-If you change your DNS server or DNS server settings, you have to restart your ISE so that the ISE can pick up those changes. Restarting a Premium SKU ISE doesn't result in downtime due to redundancy and components that restart one at a time during recycling. However, a Developer SKU ISE experiences downtime because no redundancy exists. For more information, see [ISE SKUs](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level).

-1. In the [Azure portal](https://portal.azure.com), go to your ISE.

-1. On the ISE menu, select **Overview**. On the Overview toolbar, **Restart**.

-<a name="delete-ise"></a>

-## Delete ISE

-Before you delete an ISE that you no longer need or an Azure resource group that contains an ISE, check that you have no policies or locks on the Azure resource group that contains these resources or on your Azure virtual network because these items can block deletion.

-After you delete your ISE, you might have to wait up to 9 hours before you try to delete your Azure virtual network or subnets.

-## Next steps

-* [Add resources to integration service environments](../logic-apps/add-artifacts-integration-service-environment-ise.md)

-| **Consumption** | multitenant Azure Logic Apps | **AS2 (v2)** and **AS2** managed connectors (Standard class). The **AS2 (v2)** connector provides only actions, but you can use any trigger that works for your scenario. For more information, review the following documentation: <br><br>- [AS2 managed connector reference](/connectors/as2/) <br>- [AS2 (v2) managed connector operations](#as2-v2-operations) <br>- [AS2 message limits](logic-apps-limits-and-config.md#b2b-protocol-limits) |

-| **Consumption** | Integration service environment (ISE) | **AS2 (v2)** and **AS2** managed connectors (Standard class) and **AS2** ISE version, which has different message limits than the Standard class. The **AS2 (v2)** connector provides only actions, but you can use any trigger that works for your scenario. For more information, review the following documentation: <br><br>- [AS2 managed connector reference](/connectors/as2/) <br>- [AS2 (v2) managed connector operations](#as2-v2-operations) <br>- [AS2 message limits](logic-apps-limits-and-config.md#b2b-protocol-limits) |

-| **Consumption** | multitenant Azure Logic Apps | **EDIFACT** managed connector (Standard class). The **EDIFACT** connector provides only actions, but you can use any trigger that works for your scenario. For more information, see the following documentation: <br><br>- [EDIFACT managed connector reference](/connectors/edifact/) <br>- [EDIFACT message limits](logic-apps-limits-and-config.md#b2b-protocol-limits) |

-| **Consumption** | Integration service environment (ISE) | **EDIFACT** managed connector (Standard class) and **EDIFACT** ISE version, which has different message limits than the Standard class. The **EDIFACT** connector provides only actions, but you can use any trigger that works for your scenario. For more information, see the following documentation: <br><br>- [EDIFACT managed connector reference](/connectors/edifact/) <br>- [EDIFACT message limits](logic-apps-limits-and-config.md#b2b-protocol-limits) |

-| **Consumption** | Integration service environment (ISE) | Built-in connector, which appears in the designer with the **CORE** label. The **RosettaNet** connector provides only actions, but you can use any trigger that works for your scenario. For more information, review the following documentation: <br><br>- [RosettaNet connector operations](#rosettanet-operations) <br>- [ISE message limits](logic-apps-limits-and-config.md#message-size-limits) <br>- [Managed connectors in Azure Logic Apps](../connectors/managed.md) |

-The **X12** connector has one version across workflows in [multi-tenant Azure Logic Apps, single-tenant Azure Logic Apps, and the integration service environment (ISE)](logic-apps-overview.md#resource-environment-differences). For technical information about the **X12** connector, see the following documentation:

- For example, in an [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md), this connector's ISE version uses the [B2B message limits for ISE](logic-apps-limits-and-config.md#b2b-protocol-limits).

- For a Consumption or ISE plan-based logic app, choose a step:

- For a Consumption or ISE plan-based logic app, the designer looks like this example:

-This reference guide describes the limits and configuration information for Azure Logic Apps and related resources. Based on your scenario, solution requirements, the capabilities that you want, and the environment where you want to run your workflows, you choose whether to create a Consumption logic app workflow that runs in *multitenant* Azure Logic Apps or an integration service environment (ISE). Or, create a Standard logic app workflow that runs in *single-tenant* Azure Logic Apps or an App Service Environment (v3 - Windows plans only).

-The following table briefly summarizes differences between a Consumption logic app and a Standard logic app. You'll also learn how single-tenant Azure Logic Apps compares to multitenant Azure Logic Apps and an ISE for deploying, hosting, and running your logic app workflows.

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||--|||-|

-| Run history retention in storage | 90 days | 90 days <br>(Default) | 366 days | The amount of time to keep a workflow's run history in storage after a run starts. <br><br>**Note**: If the workflow's run duration exceeds the retention limit, this run is removed from the run history in storage. If a run isn't immediately removed after reaching the retention limit, the run is removed within 7 days. <br><br>Whether a run completes or times out, run history retention is always calculated by using the run's start time and the current limit specified in the workflow setting, [**Run history retention in days**](#change-retention). No matter the previous limit, the current limit is always used for calculating retention. <br><br>For more information, review [Change duration and run history retention in storage](#change-retention). |

-| Run duration | 90 days | - Stateful workflow: 90 days <br>(Default) <br><br>- Stateless workflow: 5 min <br>(Default) | 366 days | The amount of time that a workflow can continue running before forcing a timeout. The run duration is calculated by using a run's start time and the limit that's specified in the workflow setting, [**Run history retention in days**](#change-duration) at that start time. <br><br>**Important**: Make sure the run duration value is always less than or equal to the run history retention in storage value. Otherwise, run histories might be deleted before the associated jobs are complete. <br><br>For more information, review [Change run duration and history retention in storage](#change-duration). |

-| Recurrence interval | - Min: 1 sec <br><br>- Max: 500 days | - Min: 1 sec <br><br>- Max: 500 days | - Min: 1 sec <br><br>- Max: 500 days ||

-* In an ISE, you can decrease or increase the 90-day default limit.

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||--|||-|

-| Array items | 100,000 items | - Stateful workflow: 100,000 items <br>(Default) <br><br>- Stateless workflow: 100 items <br>(Default) | 100,000 items | The number of array items that a **For each** loop can process. <br><br>To filter larger arrays, you can use the [query action](logic-apps-perform-data-operations.md#filter-array-action). <br><br>To change the default limit in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Concurrent iterations | Concurrency off: 20 <br><br>Concurrency on: <br><br>- Default: 20 <br>- Min: 1 <br>- Max: 50 | Concurrency off: 20 <br>(Default) <br><br>Concurrency on: <br><br>- Default: 20 <br>- Min: 1 <br>- Max: 50 | Concurrency off: 20 <br><br>Concurrency on: <br><br>- Default: 20 <br>- Min: 1 <br>- Max: 50 | The number of **For each** loop iterations that can run at the same time, or in parallel. <br><br>To change this value in multitenant Azure Logic Apps, see [Change **For each** concurrency limit](../logic-apps/logic-apps-workflow-actions-triggers.md#change-for-each-concurrency) or [Run **For each** loops sequentially](logic-apps-workflow-actions-triggers.md#sequential-for-each). <br><br>To change the default limit in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||--|||-|

-| Iterations | - Default: 60 <br>- Min: 1 <br>- Max: 5,000 | Stateful workflow: <br><br>- Default: 60 <br>- Min: 1 <br>- Max: 5,000 <br><br>Stateless workflow: <br><br>- Default: 60 <br>- Min: 1 <br>- Max: 100 | - Default: 60 <br>- Min: 1 <br>- Max: 5,000 | The number of cycles that an **Until** loop can have during a workflow run. <br><br>To change this value in multitenant Azure Logic Apps, in the **Until** loop shape, select **Change limits**, and specify the value for the **Count** property. <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Timeout | Default: PT1H (1 hour) | Stateful workflow: PT1H (1 hour) <br><br>Stateless workflow: PT5M (5 min) | Default: PT1H (1 hour) | The amount of time that the **Until** loop can run before exiting and is specified in [ISO 8601 format](https://en.wikipedia.org/wiki/ISO_8601). The timeout value is evaluated for each loop cycle. If any action in the loop takes longer than the timeout limit, the current cycle doesn't stop. However, the next cycle doesn't start because the limit condition isn't met. <br><br>To change this value in multitenant Azure Logic Apps, in the **Until** loop shape, select **Change limits**, and specify the value for the **Timeout** property. <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||--|||-|

-| Trigger - concurrent runs | Concurrency off: Unlimited <br><br>Concurrency on (irreversible): <br><br>- Default: 25 <br>- Min: 1 <br>- Max: 100 | Concurrency off: Unlimited <br><br>Concurrency on (irreversible): <br><br>- Default: 100 <br>- Min: 1 <br>- Max: 100 | Concurrency off: Unlimited <br><br>Concurrency on (irreversible): <br><br>- Default: 25 <br>- Min: 1 <br>- Max: 100 | The number of concurrent runs that a trigger can start at the same time, or in parallel. <br><br>**Note**: When concurrency is turned on, the **SplitOn** limit is reduced to 100 items for [debatching arrays](../logic-apps/logic-apps-workflow-actions-triggers.md#split-on-debatch). <br><br>To change this value in multitenant Azure Logic Apps, see [Change trigger concurrency limit](../logic-apps/logic-apps-workflow-actions-triggers.md#change-trigger-concurrency) or [Trigger instances sequentially](../logic-apps/logic-apps-workflow-actions-triggers.md#sequential-trigger). <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Maximum waiting runs | Concurrency on: <br><br>- Min: 10 runs plus the number of concurrent runs <br>(Default)<br>- Max: 100 runs | Concurrency on: <br><br>- Min: 10 runs plus the number of concurrent runs <br>(Default)<br>- Max: 200 runs <br> | Concurrency on: <br><br>- Min: 10 runs plus the number of concurrent runs <br>(Default)<br>- Max: 100 runs | The number of workflow instances that can wait to run when your current workflow instance is already running the maximum concurrent instances. This setting takes effect only if concurrency is turned on. <br><br>To change this value in multitenant Azure Logic Apps, see [Change waiting runs limit](../logic-apps/logic-apps-workflow-actions-triggers.md#change-waiting-runs). <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| **SplitOn** items | Concurrency off: 100,000 items <br><br>Concurrency on: 100 items | Concurrency off: 100,000 items <br><br>Concurrency on: 100 items | Concurrency off: 100,000 items <br>(Default) <br><br>Concurrency on: 100 items <br>(Default) | For triggers that return an array, you can specify an expression that uses a **SplitOn** property that [splits or debatches array items into multiple workflow instances](../logic-apps/logic-apps-workflow-actions-triggers.md#split-on-debatch) for processing, rather than use a **For each** loop. This expression references the array to use for creating and running a workflow instance for each array item. <br><br>**Note**: When concurrency is turned on, the **SplitOn** limit is reduced to 100 items. |

-For more information about your logic app resource definition, review [Overview: Automate deployment for Azure Logic Apps by using Azure Resource Manager templates](../logic-apps/logic-apps-azure-resource-manager-templates-overview.md#logic-app-resource-definition).

-### Integration service environment (ISE)

-* [Developer ISE SKU](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level): Provides up to 500 executions per minute, but note these considerations:

- * Make sure that you use this SKU only for exploration, experiments, development, or testing - not for production or performance testing. This SKU has no service-level agreement (SLA), scale up capability, or redundancy during recycling, which means that you might experience delays or downtime.

- * Backend updates might intermittently interrupt service.

-* [Premium ISE SKU](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level): The following table describes this SKU's throughput limits, but to exceed these limits in normal processing, or run load testing that might go above these limits, [contact the Logic Apps team](mailto://logicappsemail@microsoft.com) for help with your requirements.

- | Name | Limit | Notes |

- ||-|-|

- | Base unit execution limit | System-throttled when infrastructure capacity reaches 80% | Provides ~4,000 action executions per minute, which is ~160 million action executions per month |

- | Scale unit execution limit | System-throttled when infrastructure capacity reaches 80% | Each scale unit can provide ~2,000 more action executions per minute, which is ~80 million more action executions per month |

- | Maximum scale units that you can add | 10 scale units | |

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||-|||-|

-| Variables per workflow | 250 variables | 250 variables <br>(Default) | 250 variables ||

-| Variable - Maximum content size | 104,857,600 characters | Stateful workflow: 104,857,600 characters <br>(Default) <br><br>Stateless workflow: 1,024 characters <br>(Default) | 104,857,600 characters | To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Variable (Array type) - Maximum number of array items | 100,000 items | 100,000 items <br>(Default) | Premium SKU: 100,000 items <br><br>Developer SKU: 5,000 items | To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-> For the **Logic App (Standard)** resource type in the single-tenant service, stateless workflows can only run *synchronously*.

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||-|||-|

-| Outbound request | 120 sec <br>(2 min) | 235 sec <br>(3.9 min) <br>(Default) | 240 sec <br>(4 min) | Examples of outbound requests include calls made by the HTTP trigger or action. <br><br>**Tip**: For longer running operations, use an [asynchronous polling pattern](../logic-apps/logic-apps-create-api-app.md#async-pattern) or an ["Until" loop](../logic-apps/logic-apps-workflow-actions-triggers.md#until-action). To work around timeout limits when you call another workflow that has a [callable endpoint](logic-apps-http-endpoint.md), you can use the built-in Azure Logic Apps action instead, which you can find in the designer's operation picker under **Built-in**. <br><br>To change the default limit in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Inbound request | 120 sec <br>(2 min) | 235 sec <br>(3.9 min) <br>(Default) | 240 sec <br>(4 min) | Examples of inbound requests include calls received by the Request trigger, HTTP Webhook trigger, and HTTP Webhook action. <br><br>**Note**: For the original caller to get the response, all steps in the response must finish within the limit unless you call another nested workflow. For more information, see [Call, trigger, or nest logic apps](../logic-apps/logic-apps-http-endpoint.md). <br><br>To change the default limit in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Name | Chunking enabled | Multitenant | Single-tenant | Integration service environment | Notes |

-|||-|-||-|

-| Content download - Maximum number of requests | Yes | 1,000 requests | 1,000 requests <br>(Default) | 1,000 requests ||

-| Message size | No | 100 MB | 100 MB | 200 MB | To work around this limit, see [Handle large messages with chunking](../logic-apps/logic-apps-handle-large-messages.md). However, some connectors and APIs don't support chunking or even the default limit. <br><br>- Connectors such as AS2, X12, and EDIFACT have their own [B2B message limits](#b2b-protocol-limits). <br><br>- ISE connectors use the ISE limit, not the non-ISE connector limits. <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Message size per action | Yes | 1 GB | 1,073,741,824 bytes <br>(1 GB) <br>(Default) | 5 GB | This limit applies to actions that either natively support chunking or let you enable chunking in their runtime configuration. <br><br>If you're using an ISE, the Azure Logic Apps engine supports this limit, but connectors have their own chunking limits up to the engine limit, for example, see the [Azure Blob Storage connector's API reference](/connectors/azureblob/). For more information about chunking, see [Handle large messages with chunking](../logic-apps/logic-apps-handle-large-messages.md). <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Content chunk size per action | Yes | Varies per connector | 52,428,800 bytes (52 MB) <br>(Default) | Varies per connector | This limit applies to actions that either natively support chunking or let you enable chunking in their runtime configuration. <br><br>To change the default value in the single-tenant service, review [Edit host and app settings for logic apps in single-tenant Azure Logic Apps](edit-app-settings-host-settings.md). |

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||-|||-|

-| Maximum number of code characters | 1,024 characters | 100,000 characters | 1,024 characters | To use the higher limit, create a **Logic App (Standard)** resource, which runs in single-tenant Azure Logic Apps, either [by using the Azure portal](create-single-tenant-workflows-azure-portal.md) or [by using Visual Studio Code and the **Azure Logic Apps (Standard)** extension](create-single-tenant-workflows-visual-studio-code.md). |

-| Maximum duration for running code | 5 sec | 15 sec | 1,024 characters | To use the higher limit, create a **Logic App (Standard)** resource, which runs in single-tenant Azure Logic Apps, either [by using the Azure portal](create-single-tenant-workflows-azure-portal.md) or [by using Visual Studio Code and the **Azure Logic Apps (Standard)** extension](create-single-tenant-workflows-visual-studio-code.md). |

-In multitenant Azure Logic Apps and the integration service environment only, you can create and use [custom managed connectors](/connectors/custom-connectors), which are wrappers around an existing REST API or SOAP API. In single-tenant Azure Logic Apps, you can create and use only [custom built-in connectors](https://techcommunity.microsoft.com/t5/integrations-on-azure/azure-logic-apps-running-anywhere-built-in-connector/ba-p/1921272).

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||-|||-|

-| Custom connectors | 1,000 per Azure subscription | Unlimited | 1,000 per Azure subscription ||

-| APIs per service | SOAP-based: 50 | Not applicable | SOAP-based: 50 ||

-| Parameters per API | SOAP-based: 50 | Not applicable | SOAP-based: 50 ||

-| Requests per minute for a custom connector | 500 requests per minute per connection | Based on your implementation | 2,000 requests per minute per *custom connector* ||

-| Connection timeout | 2 min | Idle connection: <br>4 min <br><br>Active connection: <br>10 min | 2 min ||

-* One [Free tier](../logic-apps/logic-apps-pricing.md#integration-accounts) integration account per Azure region. This tier is available only for public regions in Azure, for example, West US or Southeast Asia, but not for [Microsoft Azure operated by 21Vianet](/azure/chin).

-* 1,000 total integration accounts, including integration accounts in any [integration service environments (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) across both [Developer and Premium SKUs](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level).

-* Each ISE, whether [Developer or Premium](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level), can use a single integration account at no extra cost, although the included account type varies by ISE SKU. You can create more integration accounts for your ISE up to the total limit for an [extra cost](logic-apps-pricing.md#ise-pricing).

- | ISE SKU | Integration account limits |

- ||-|

- | **Premium** | 20 total accounts, including one Standard account at no extra cost. With this SKU, you can have only [Standard](../logic-apps/logic-apps-pricing.md#integration-accounts) accounts. No Free or Basic accounts are permitted. |

- | **Developer** | 20 total accounts, including one [Free](../logic-apps/logic-apps-pricing.md#integration-accounts) account (limited to 1). With this SKU, you can have either combination: <br><br>- A Free account and up to 19 [Standard](../logic-apps/logic-apps-pricing.md#integration-accounts) accounts. <br>- No Free account and up to 20 Standard accounts. <br><br>No Basic or more Free accounts are permitted. <br><br>**Important**: Use the [Developer SKU](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#ise-level) for experimenting, development, and testing, but not for production or performance testing. |

-To learn how pricing and billing work for ISEs, see the [Logic Apps pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing). For pricing rates, see [Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/).

-The following tables list the values for the number of artifacts limited to each integration account tier. For pricing rates, see [Logic Apps pricing](https://azure.microsoft.com/pricing/details/logic-apps/). To learn how pricing and billing work for integration accounts, see the [Logic Apps pricing model](../logic-apps/logic-apps-pricing.md#integration-accounts).

-| Assemblies | 10 | 25 | 1,000 | Unlimited, but currently unsupported for export from an ISE. |

-| RosettaNet partner interface process (PIP) | 10 | 1 | 500 | Unlimited, but currently unsupported for export from an ISE. |

-| Assembly | 8 MB | To upload files larger than 2 MB, use an [Azure storage account and blob container](../logic-apps/logic-apps-enterprise-integration-schemas.md). |

-| Schema | 8 MB | To upload files larger than 2 MB, use an [Azure storage account and blob container](../logic-apps/logic-apps-enterprise-integration-schemas.md). |

-| Name | Multitenant | Single-tenant | Integration service environment | Notes |

-||-|||-|

-| AS2 | v2 - 100 MB<br>v1 - 25 MB | Unavailable | v2 - 200 MB <br>v1 - 25 MB | Applies to decode and encode |

-| X12 | 50 MB | Unavailable | 50 MB | Applies to decode and encode |

-| EDIFACT | 50 MB | Unavailable | 50 MB | Applies to decode and encode |

-> - **SAP**: The return caller depends on whether the deployment environment is either multitenant Azure or ISE.

-> In an ISE, the SAP connector makes the call back to Azure Logic Apps.

-* Your own static IP addresses, which are separate from the static IP addresses that logic apps share in multitenant Azure Logic Apps. You can also set up a single public, static, and predictable outbound IP address to communicate with destination systems. That way, you don't have to set up extra firewall openings at those destination systems for each ISE.

-* [Single-tenant versus multi-tenant and integration service environment](single-tenant-overview-compare.md)

-## Consumption (multi-tenant)

-In multi-tenant Azure Logic Apps, a logic app and its workflow follow the [**Consumption** plan](https://azure.microsoft.com/pricing/details/logic-apps) for pricing and billing. You create such logic apps in various ways, for example, when you choose the **Logic App (Consumption)** resource type, use the **Azure Logic Apps (Consumption)** extension in Visual Studio Code, or when you create [automation tasks](create-automation-tasks-azure-resources.md).

-The following table summarizes how the Consumption model handles metering and billing for the following components when used with a logic app and a workflow in multi-tenant Azure Logic Apps:

-| Integration accounts | Metering applies based on the integration account type that you create and use with your logic app. Billing follows [*Integration Account* pricing](https://azure.microsoft.com/pricing/details/logic-apps/) unless your logic app is deployed and hosted in an [integration service environment (ISE)](#ise-pricing). For more information, review [Integration accounts](#integration-accounts). |

-The following table summarizes how the Consumption model handles metering and billing for these operation types when used with a logic app and workflow in multi-tenant Azure Logic Apps:

-<a name="ise-pricing"></a>

-## Integration service environment (ISE)

-When you create a logic app using the **Logic App (Consumption)** resource type, and you deploy to a dedicated [*integration service environment (ISE)*](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md), the logic app and its workflow follow the [Integration Service Environment plan](https://azure.microsoft.com/pricing/details/logic-apps) for pricing and billing. This pricing model depends on your [ISE level or *SKU*](connect-virtual-network-vnet-isolated-environment-overview.md#ise-level) and differs from the Consumption plan in that you're billed for reserved capacity and dedicated resources whether or not you use them.

-The following table summarizes how the ISE model handles metering and billing for capacity and other dedicated resources based on your ISE level or SKU:

-| ISE SKU | Metering and billing |

-||-|

-| **Premium** | The base unit has [fixed capacity](logic-apps-limits-and-config.md#integration-service-environment-ise) and is [billed at an hourly rate for the Premium SKU](https://azure.microsoft.com/pricing/details/logic-apps). If you need more throughput, you can [add more scale units](../logic-apps/ise-manage-integration-service-environment.md#add-capacity) when you create your ISE or afterwards. Each scale unit is billed at an [hourly rate that's roughly half the base unit rate](https://azure.microsoft.com/pricing/details/logic-apps). <p><p>For capacity and limits information, see [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise). |

-| **Developer** | The base unit has [fixed capacity](logic-apps-limits-and-config.md#integration-service-environment-ise) and is [billed at an hourly rate for the Developer SKU](https://azure.microsoft.com/pricing/details/logic-apps). However, this SKU has no service-level agreement (SLA), scale up capability, or redundancy during recycling, which means that you might experience delays or downtime. Backend updates might intermittently interrupt service. <p><p>**Important**: Make sure that you use this SKU only for exploration, experiments, development, and testing - not for production or performance testing. <p><p>For capacity and limits information, see [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise). |

-The following table summarizes how the ISE model handles the following components when used with a logic app and a workflow in an ISE:

-| Component | Description |

-|--|-|

-| Trigger and action operations | The ISE model includes free built-in, managed connector, and custom connector operations that your workflow can run, but subject to the [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise) and [custom connector limits in Azure Logic Apps](logic-apps-limits-and-config.md#custom-connector-limits). For more information, review [Trigger and action operations in the ISE model](#integration-service-environment-operations). |

-| Storage operations | The ISE model includes free storage consumption, such as data retention. For more information, review [Storage operations](#storage-operations). |

-| Integration accounts | The ISE model includes a single free integration account tier, based on your selected ISE SKU. For an [extra cost](https://azure.microsoft.com/pricing/details/logic-apps/), you can create more integration accounts for your ISE to use up to the [total ISE limit](../logic-apps/logic-apps-limits-and-config.md#integration-account-limits). For more information, review [Integration accounts](#integration-accounts). |

-<a name="integration-service-environment-operations"></a>

-### Trigger and action operations in the ISE model

-The following table summarizes how the ISE model handles the following operation types when used with a logic app and workflow in an ISE:

-| Operation type | Description | Metering and billing |

-|-|-|-|

-| [*Built-in*](../connectors/built-in.md) | These operations run directly and natively with the Azure Logic Apps runtime and in the same ISE as your logic app workflow. In the designer, you can find these operations under the **Built-in** label, but each operation also displays the **CORE** label. <p>For example, the HTTP trigger and Request trigger are built-in triggers. The HTTP action and Response action are built-in actions. Other built-in operations include workflow control actions such as loops and conditions, data operations, batch operations, and others. | The ISE model includes these operations *for free*, but are subject to the [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise). |

-| [*Managed connector*](../connectors/managed.md) | Whether *Standard* or *Enterprise*, managed connector operations run in either your ISE or multi-tenant Azure, based on whether the connector or operation displays the **ISE** label. <p><p>- **ISE** label: These operations run in the same ISE as your logic app and work without requiring the [on-premises data gateway](#data-gateway). <p><p>- No **ISE** label: These operations run in multi-tenant Azure. | The ISE model includes both **ISE** and no **ISE** labeled operations *for free*, but are subject to the [ISE limits in Azure Logic Apps](logic-apps-limits-and-config.md#integration-service-environment-ise). |

-| [*Custom connector*](../connectors/introduction.md#custom-connectors-and-apis) | In the designer, you can find these operations under the **Custom** label. | The ISE model includes these operations *for free*, but are subject to [custom connector limits in Azure Logic Apps](logic-apps-limits-and-config.md#custom-connector-limits). |

-For more information about how the ISE model works with operations that run inside other operations such as loops, process multiple items such as arrays, and retry policies, review [Other operation behavior](#other-operation-behavior).

-The following table summarizes how the Consumption, Standard, and ISE models handle operations that run inside other operations such as loops, process multiple items such as arrays, and retry policies:

-| Operation | Description | Consumption | Standard | ISE |

-|--|-|-|-|--|

-| [Loop actions](logic-apps-control-flow-loops.md) | A loop action, such as the **For each** or **Until** loop, can include other actions that run during each loop cycle. | Except for the initial number of included built-in operations, the loop action and each action in the loop are metered each time the loop cycle runs. If an action processes any items in a collection, such as a list or array, the number of items is also used in the metering calculation. <p><p>For example, suppose you have a **For each** loop with actions that process a list. The service multiplies the number of list items against the number of actions in the loop, and adds the action that starts the loop. So, the calculation for a 10-item list is (10 * 1) + 1, which results in 11 action executions. <p><p>Pricing is based on whether the operation types are built-in, Standard, or Enterprise. | Except for the included built-in operations, same as the Consumption model. | Not metered or billed. |

-| [Retry policies](logic-apps-exception-handling.md#retry-policies) | On supported operations, you can implement basic exception and error handling by setting up a [retry policy](logic-apps-exception-handling.md#retry-policies). | Except for the initial number of built-in operations, the original execution plus each retried execution are metered. For example, an action that executes with 5 retries is metered and billed as 6 executions. <p><p>Pricing is based on whether the operation types are built-in, Standard, or Enterprise. | Except for the built-in included operations, same as the Consumption model. | Not metered or billed. |

-The following table summarizes how the Consumption, Standard, and ISE models handle metering and billing for storage operations:

-| Consumption (multi-tenant) | Storage resources and usage are attached to the logic app resource. | Metering and billing *apply only to data retention-related storage consumption* and follow the [data retention pricing for the Consumption plan](https://azure.microsoft.com/pricing/details/logic-apps). |

-| Integration service environment (ISE) | Storage resources and usage are attached to the logic app resource. | Not metered or billed. |

-The following table summarizes how the Consumption, Standard, and ISE models handle metering and billing for integration accounts:

-| Consumption (multi-tenant) | Metering and billing use the [integration account pricing](https://azure.microsoft.com/pricing/details/logic-apps/), based on the account tier that you use. |

-| ISE | This model includes a single integration account, based on your ISE SKU. For an [extra cost](https://azure.microsoft.com/pricing/details/logic-apps/), you can create more integration accounts for your ISE to use up to the [total ISE limit](../logic-apps/logic-apps-limits-and-config.md#integration-account-limits). |

-You can use Azure Logic Apps in [Azure Government](../azure-government/documentation-government-welcome.md) supporting all impact levels in the regions described by the [Azure Government Impact Level 5 Isolation Guidance](../azure-government/documentation-government-impact-level-5.md). To meet these requirements, Azure Logic Apps supports the capability for you to create and run workflows in an environment with dedicated resources so that you can reduce the performance impact by other Azure tenants on your logic apps and avoid sharing computing resources with other tenants.

-* Based on whether you have Consumption or Standard logic app workflows, you have these options:

- * Standard logic app workflows can privately and securely communicate with an Azure virtual network through private endpoints that you set up for inbound traffic and virtual network integration for outbound traffic. For more information, review [Secure traffic between virtual networks and single-tenant Azure Logic Apps using private endpoints](secure-single-tenant-workflow-virtual-network-private-endpoint.md).

- * Consumption logic app workflows can run in an [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md) where they can use dedicated resources and access resources protected by an Azure virtual network. However, the ISE resource retires on August 31, 2024, due to its dependency on Azure Cloud Services (classic), which retires at the same time.

- > [!IMPORTANT]

- >

- > Some Azure virtual networks use private endpoints ([Azure Private Link](../private-link/private-link-overview.md))

- > for providing access to Azure PaaS services, such as Azure Storage, Azure Cosmos DB, or Azure SQL Database,

- > partner services, or customer services that are hosted on Azure.

- >

- > To create Consumption logic app workflows that need access to virtual networks with private endpoints,

- > you *must create and run your Consumption workflows in an ISE*. Or, you can create Standard workflows instead,

- > which don't need an ISE. Instead, your workflows can communicate privately and securely with virtual networks

- > by using private endpoints for inbound traffic and virtual network integration for outbound traffic. For more information, see

- > [Secure traffic between virtual networks and single-tenant Azure Logic Apps using private endpoints](secure-single-tenant-workflow-virtual-network-private-endpoint.md).

-## Next steps

-> [!IMPORTANT]

-> Changing the location type from **Region** to

-> [**Integration Service Environment**](connect-virtual-network-vnet-isolated-environment-overview.md)

-> affects your logic app's [pricing model](logic-apps-pricing.md#ise-pricing) that's used for billing,

-> [limits](logic-apps-limits-and-config.md#integration-account-limits), [integration account support](connect-virtual-network-vnet-isolated-environment-overview.md#ise-skus), and so on.

-> Before you select a different location type, make sure that you understand the resulting impact on your logic app.

-1. Make sure that the workflow designer has focus by selecting the designer's tab or surface so that the Properties window shows the **Choose Location Type** and **Location** properties for your logic app. The project's location type is set to either **Region** or **Integration Service Environment**.

-1. To change the location type, open the **Choose Location Type** property list, and select the location type that you want.

- For example, if the location type is **Integration Service Environment**, you can select **Region**.

- 

- * Select a different Azure region:

- * Select a different ISE:

- 

-* You can move an [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md) only to another resource group that exists in the same Azure region or Azure subscription. You can't move an ISE to a resource group that exists in a different Azure region or Azure subscription. Also, after such a move, you must update all references to the ISE in your logic app workflows, integration accounts, connections, and so on.

-To move a resource, such as a logic app, integration account, or [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md), to another Azure resource group, you can use the Azure portal, Azure PowerShell, Azure CLI, or REST API. These steps cover the Azure portal, which you can use when the resource's region stays the same. For other steps and general preparation, see [Move resources to a new resource group or subscription](../azure-resource-manager/management/move-resource-group-and-subscription.md).

-* Logic app resources that you create and run in an [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) use the [ISE pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing).

-* An [ISE](../logic-apps/logic-apps-pricing.md#ise-pricing) is a separate resource that you create as a deployment location for logic apps that need direct access to resources in a virtual network. ISEs use the [ISE pricing model](../logic-apps/logic-apps-pricing.md#ise-pricing) where the rate is based on the ISE SKU that you create and other settings. However, data retention and storage consumption don't incur costs.

-* A [custom connector](../logic-apps/logic-apps-pricing.md#consumption-pricing) is a separate resource that you create for a REST API that has no prebuilt connector for you to use in your logic apps. Custom connector executions use a [consumption pricing model](../logic-apps/logic-apps-pricing.md#consumption-pricing) except when you use them in an ISE.

-* Integration service environments (ISEs)

- If you [delete an ISE](ise-manage-integration-service-environment.md#delete-ise), the associated Azure virtual network, subnets, and other related resources continue to exist. After you delete the ISE, you might have to wait up to a specific number of hours before you can try deleting the virtual network or subnets.

- | **Location** | **Same as Resource Group** | The location type and specific location for deploying your logic app resource. The location type is either an Azure region or an existing [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md). <p>For this quickstart, keep the location type set to **Region** and the location set to **Same as Resource Group**. <p>**Note**: After you create your resource group project, you can [change the location type and the location](manage-logic-apps-with-visual-studio.md#change-location), but different location type affects your logic app in various ways. |

-Azure Logic Apps is a cloud-based platform for creating and running automated *logic app workflows* that integrate your apps, data, services, and systems. With this platform, you can quickly develop highly scalable integration solutions for your enterprise and business-to-business (B2B) scenarios. When you create a logic app resource, you select either the **Consumption** workflow type or **Standard** workflow type. A Consumption logic app can have only one workflow that runs in *multitenant* Azure Logic Apps or an *integration service environment*. A Standard logic app can have one or multiple workflows that run in *single-tenant* Azure Logic Apps or an App Service Environment v3 (ASE v3).

-The following table summarizes the differences between a **Consumption** logic app workflow and **Standard** logic app workflow. You also learn how the single-tenant environment differs from the multitenant environment and an integration service environment (ISE) for deploying, hosting, and running your workflows.

-Workflows that run in either single-tenant Azure Logic Apps or in an *integration service environment (ISE)* can directly access secured resources such as virtual machines (VMs), other services, and systems that exist in an [Azure virtual network](../virtual-network/virtual-networks-overview.md).

-Both single-tenant Azure Logic Apps and an ISE are dedicated instances of the Azure Logic Apps service, use dedicated resources, and run separately from multitenant Azure Logic Apps. Running workflows in a dedicated instance helps reduce the impact that other Azure tenants might have on app performance, also known as the ["noisy neighbors" effect](https://en.wikipedia.org/wiki/Cloud_computing_issues#Performance_interference_and_noisy_neighbors).

-Single-tenant Azure Logic Apps and an ISE also provide the following benefits:

-* Your own static IP addresses, which are separate from the static IP addresses that are shared by the logic apps in the multitenant Azure Logic Apps. You can also set up a single public, static, and predictable outbound IP address to communicate with destination systems. That way, you don't have to set up extra firewall openings at those destination systems for each ISE.

-**Integration service environment**

-| Option | Resources and tools | More information |

-|--|||

-| Azure portal | **Consumption** logic app deployed to an existing ISE resource | Same as [Quickstart: Create an example Consumption logic app workflow in multitenant Azure Logic Apps - Azure portal](quickstart-create-example-consumption-workflow.md), but select an ISE, not a multitenant region. |

-* **Deployment targets**: You can't deploy a **Standard** logic app resource to an [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md).

-> [!NOTE]

->

-> If your workflow runs in an [integration service environment (ISE)](connect-virtual-network-vnet-isolated-environment-overview.md)

-> that was created to use an [internal access endpoint](connect-virtual-network-vnet-isolated-environment-overview.md#endpoint-access),

-> you can view and access inputs and outputs from a workflow run history *only from inside your virtual network*. Make sure that you have network

-> connectivity between the private endpoints and the computer from where you want to access run history. For example, your client computer can exist

-> inside the ISE's virtual network or inside a virtual network that's connected to the ISE's virtual network, for example, through peering or a virtual

-> private network. For more information, see [ISE endpoint access](connect-virtual-network-vnet-isolated-environment-overview.md#endpoint-access).

-titleExtension: Azure Red Hat OpenShift

-description: Shows you how to quickly set up JBoss EAP on Azure Red Hat OpenShift (ARO) using the Azure portal and deploy an app with the Source-to-Image (S2I) feature.

-# customer intent: As a developer, I want to learn how to auto redeploy JBoss EAP on Azure Red Hat OpenShift using Source-to-Image (S2I) so that I can quickly deploy and update my application.

-# Quickstart: Auto-redeploy JBoss EAP on Azure Red Hat OpenShift with Source-to-Image (S2I)

-This article shows you how to quickly set up JBoss Enterprise Application Platform (EAP) on Azure Red Hat OpenShift (ARO) and deploy an app with the Source-to-Image (S2I) feature. The Source-to-Image feature enables you to build container images from source code without having to write Dockerfiles. The article uses a sample application that you can fork from GitHub and deploy to Azure Red Hat OpenShift. The article also shows you how to set up a webhook in GitHub to trigger a new build in OpenShift every time you push a change to the repository.

-This article uses the Azure Marketplace offer for JBoss EAP to accelerate your journey to ARO. The offer automatically provisions resources including an ARO cluster with a built-in OpenShift Container Registry (OCR), the JBoss EAP Operator, and optionally a container image including JBoss EAP and your application using Source-to-Image (S2I). To see the offer, visit the [Azure portal](https://aka.ms/eap-aro-portal). If you prefer manual step-by-step guidance for running JBoss EAP on ARO that doesn't use the automation enabled by the offer, see [Deploy a Java application with Red Hat JBoss Enterprise Application Platform (JBoss EAP) on an Azure Red Hat OpenShift 4 cluster](/azure/developer/java/ee/jboss-eap-on-aro).

-## Prerequisites

-## Create a Microsoft Entra service principal

-Use the following steps to create a service principal:

-1. Create a service principal by using the following command:

- ```azurecli

- az ad sp create-for-rbac --name "sp-aro-s2i-$(date +%s)"

- ```

- This command produces output similar to the following example:

- ```output

- {

- "appId": <app-ID>,

- "displayName": <display-Name>,

- "password": <password>,

- "tenant": <tenant>

- }

- ```

-1. Copy the value of the `appId` and `password` fields. You use these values later in the deployment process.

-## Fork the repository on GitHub

-Use the following steps to fork the sample repo:

-1. Open the repository <https://github.com/redhat-mw-demos/eap-on-aro-helloworld> in your browser.

-1. Fork the repository to your GitHub account.

-1. Copy the URL of the forked repository.

-## Deploy JBoss EAP on Azure Red Hat OpenShift

-This section shows you how to deploy JBoss EAP on Azure Red Hat OpenShift.

-Use the following steps to find the offer and fill out the **Basics** pane:

-1. In the search bar at the top of the Azure portal, enter *JBoss EAP*. In the search results, in the **Marketplace** section, select **JBoss EAP on Azure Red Hat OpenShift**, as shown in the following screenshot:

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/marketplace-search-results.png" alt-text="Screenshot of the Azure portal that shows JBoss EAP on Azure Red Hat OpenShift in search results." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/marketplace-search-results.png":::

- You can also go directly to the [JBoss EAP on Azure Red Hat OpenShift offer](https://aka.ms/eap-aro-portal) on the Azure portal.

-1. On the offer page, select **Create**.

-1. On the **Basics** pane, ensure that the value shown in the **Subscription** field is the same one that has the roles listed in the prerequisites section.

-1. You must deploy the offer in an empty resource group. In the **Resource group** field, select **Create new** and fill in a value for the resource group. Because resource groups must be unique within a subscription, pick a unique name. An easy way to have unique names is to use a combination of your initials, today's date, and some identifier. For example, *eaparo033123rg*.

-1. Under **Instance details**, select the region for the deployment. For a list of Azure regions where OpenShift operates, see [Regions for Red Hat OpenShift 4.x on Azure](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/?products=openshift&regions=all).

-1. Select **Next: ARO**.

-Use the following steps to fill out the **ARO** pane shown in the following screenshot:

-1. Under **Create a new cluster**, select **Yes**.

-1. Under **Provide information to create a new cluster**, for **Red Hat pull secret**, use the Red Hat pull secret that you obtained in the [Get a Red Hat pull secret](#get-a-red-hat-pull-secret) section. Use the same value for **Confirm secret**.

-1. For **Service principal client ID**, use the `appId` value that you obtained in the [Create a Microsoft Entra service principal](#create-a-microsoft-entra-service-principal) section.

-1. For **Service principal client secret**, use the `password` value that you obtained in the [Create a Microsoft Entra service principal](#create-a-microsoft-entra-service-principal) section. Use the same value for **Confirm secret**.

-1. Select **Next EAP Application**.

-The following steps show you how to fill out the **EAP Application** pane shown in the following screenshot, and then start the deployment.

-1. Select **YES** for **Deploy an application to OpenShift using Source-to-Image (S2I)?**.

-1. For **Deploy your own application or a sample application?**, select **Your own application**.

-1. For **Application source code repository URL**, use the URL of the forked repository that you created in the [Fork repository from GitHub](#fork-the-repository-on-github) section.

-1. For **Red Hat Container Registry Service account username**, use the username of the Red Hat Container Registry service account that you created in the [Create a Red Hat Container Registry service account](#create-a-red-hat-container-registry-service-account) section.

-1. For **Red Hat Container Registry Service account password**, use the password of the Red Hat Container Registry service account that you created in the [Create a Red Hat Container Registry service account](#create-a-red-hat-container-registry-service-account) section.

-1. For **Confirm password**, use the same value as in the previous step.

-1. Leave other fields with default values.

-1. Select **Next: Review + create**.

-1. Select **Review + create**. Ensure that the green **Validation Passed** message appears at the top. If the message doesn't appear, fix any validation problems, and then select **Review + create** again.

-1. Select **Create**.

-1. Track the progress of the deployment on the **Deployment is in progress** page.

-Depending on network conditions and other activity in your selected region, the deployment might take up to 40 minutes to complete.

-## Verify the functionality of the deployment

-This section shows you how to verify that the deployment completed successfully.

-If you navigated away from the **Deployment is in progress** page, use the following steps to get back to that page. If you're still on the page that shows **Your deployment is complete**, you can skip to step 5.

-1. In the corner of any Azure portal page, select the hamburger menu and then select **Resource groups**.

-1. In the box with the text **Filter for any field**, enter the first few characters of the resource group you created previously. If you followed the recommended convention, enter your initials, then select the appropriate resource group.

-1. In the navigation pane, in the **Settings** section, select **Deployments**. You see an ordered list of the deployments to this resource group, with the most recent one first.

-1. Scroll to the oldest entry in this list. This entry corresponds to the deployment you started in the preceding section. Select the oldest deployment, as shown in the following screenshot.

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/deployments.png" alt-text="Screenshot of the Azure portal that shows JBoss EAP on Azure Red Hat OpenShift deployments with the oldest deployment highlighted." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/deployments.png":::

-1. In the navigation pane, select **Outputs**. This list shows the output values from the deployment, which includes some useful information like **cmdToGetKubeadminCredentials** and **consoleUrl**.

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/deployment-outputs.png" alt-text="Screenshot of the Azure portal that shows JBoss EAP on Azure Red Hat OpenShift deployment outputs." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/deployment-outputs.png":::

-1. Open your local terminal, paste the value from the **cmdToGetKubeadminCredentials** field, and execute it. You see the admin account and credential for signing in to the OpenShift cluster console portal. The following example shows an admin account:

- ```azurecli

- az aro list-credentials -g eaparo033123rg -n aro-cluster

- ```

- This command produces output similar to the following example:

- ```output

- {

- "kubeadminPassword": "xxxxx-xxxxx-xxxxx-xxxxx",

- "kubeadminUsername": "kubeadmin"

- }

- ```

-1. Paste the value from the **consoleUrl** field into an Internet-connected web browser, and then press <kbd>Enter</kbd>.

-1. Fill in the admin user name and password, then select **Log in**.

-1. In the admin console of Azure Red Hat OpenShift, select **Operators** > **Installed Operators**, where you can find that the **JBoss EAP** operator is successfully installed, as shown in the following screenshot:

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/red-hat-openshift-cluster-console-portal-operators.png" alt-text="Screenshot of the Red Hat OpenShift cluster console portal that shows the Installed operators page." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/red-hat-openshift-cluster-console-portal-operators.png":::

-1. Paste the value from the **appEndpoint** field into an Internet-connected web browser, and then press <kbd>Enter</kbd>. You see the JBoss EAP application running on Azure Red Hat OpenShift, as shown in the following screenshot:

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/jboss-eap-application.png" alt-text="Screenshot of the JBoss EAP application running on Azure Red Hat OpenShift." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/jboss-eap-application.png":::

-## Set up webhooks with OpenShift

-This section shows you how to set up and use GitHub webhooks with OpenShift.

-### Get the GitHub webhook URL

-Use the following steps to get the webhook URL:

-1. Navigate to the **OpenShift Web Console** with the URL provided in the **consoleUrl** field.

-1. Navigate to **Builds** > **BuildConfigs** > **eap-app-build-artifacts**.

-1. Select **Copy URL with Secret**, as shown in the following screenshot:

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/github-webhook-url.png" alt-text="Screenshot of the Red Hat OpenShift cluster console portal BuildConfig details page with the Copy URL with Secret link highlighted." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/github-webhook-url.png":::

-### Configure GitHub webhooks

-Use the following steps to configure webhooks:

-1. Open the forked repository in your GitHub account.

-1. Navigate to the **Settings** tab.

-1. Navigate to the **Webhooks** tab.

-1. Select **Add webhook**.

-1. Paste the **URL with Secret** value into the **Payload URL** field.

-1. Change the **Content type** value to **application/json**.

-1. For **Which events would you like to trigger this webhook?**, select **Just the push event**.

-1. Select **Add webhook**.

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/github-webhook-settings.png" alt-text="Screenshot of GitHub that shows the Settings tab and Webhooks pane." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/github-webhook-settings.png":::

-From now on, every time you push a change to the repository, the webhook triggers a new build in OpenShift.

-### Test the GitHub webhooks

-Use the following steps to test the webhooks:

-1. Select the **Code** tab in the forked repository.

-1. Navigate to the *src/main/webapp/https://docsupdatetracker.net/index.html* file.

-1. After you have the file on the screen, navigate to the **Edit** button.

-1. Change the line 38 from `<h1 class="display-4">JBoss EAP on Azure Red Hat OpenShift</h1>` to `<h1 class="display-4">JBoss EAP on Azure Red Hat OpenShift - Updated - 01 </h1>`.

-1. Select **Commit changes**.

-After you commit the changes, the webhook triggers a new build in OpenShift. From the OpenShift Web Console, navigate to **Builds** > **Builds** to see a new build in **Running** status.

-### Verify the update

-Use the following steps to verify the update:

-1. After the build completes, navigate to **Builds** > **Builds** to see two new builds in **Complete** status.

-1. Open a new browser tab and navigate to the **appEndpoint** URL.

- You should see the updated message on the screen.

- :::image type="content" source="media/howto-deploy-java-jboss-enterprise-application-platform-app/jboss-eap-application-with-updated-info.png" alt-text="Screenshot of the JBoss EAP sample application with updated information." lightbox="media/howto-deploy-java-jboss-enterprise-application-platform-app/jboss-eap-application-with-updated-info.png":::