你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标准型单租户逻辑应用与消耗型多租户逻辑应用之间的差异
Azure 逻辑应用是一个基于云的平台，用于创建和运行集成应用、数据、服务和系统的自动化逻辑应用工作流。 借助此平台，可以快速为企业和企业到企业 (B2B) 方案开发高度可缩放的集成解决方案。 创建逻辑应用资源时，可以选择“消耗”或“标准”托管选项。 消耗型逻辑应用只能有一个在多租户 Azure 逻辑应用中运行的工作流。 标准型逻辑应用可以包含一个或多个在单租户 Azure 逻辑应用或应用服务环境 v3 (ASE v3) 中运行的工作流。
在选择要创建的逻辑应用资源之前，请查看以下指南，了解不同的逻辑应用工作流类型之间的对比。 然后，可以做出更好的选择，确定哪个逻辑应用工作流和环境最适合你的方案、解决方案要求，以及要部署和运行工作流的目标。
如果你不熟悉 Azure 逻辑应用，请查看什么是 Azure 逻辑应用？和什么是逻辑应用工作流？。
逻辑应用工作流类型和环境
下表总结了消耗型逻辑应用工作流和标准型逻辑应用工作流之间的差异。 你还将了解单租户环境与多租户环境在部署、托管和运行工作流方面的差异。
| 托管选项 | 好处 | 资源共享和使用 | 定价和计费模型 | 限制管理 |
|---|---|---|---|---|
| 消耗 主机环境：多租户 Azure 逻辑应用 |
- 最容易入门 - 仅为所使用内容付费 - 完全托管 |
单个逻辑应用资源只能拥有一个工作流。 跨 Microsoft Entra 租户的所有逻辑应用可共享相同的处理（计算）、存储、网络等。 出于冗余目的，将在配对区域中复制数据。 为实现高可用性，已启用异地冗余存储 (GRS)。 |
消耗（按执行付费） | Azure 逻辑应用管理这些限制的默认值，但如果特定限制存在更改值的选项，则可以更改其中某些值。 |
| 标准（工作流服务计划） 主机环境： 单租户 Azure 逻辑应用 注意：如果你的方案需要容器，请使用已启用 Azure Arc 的逻辑应用创建基于单租户的逻辑应用。 有关详细信息，请参阅什么是已启用 Azure Arc 的逻辑应用？ |
- 更多内置连接器托管在单租户运行时上，可实现更高的吞吐量和更低的规模成本 - 围绕运行时和性能设置的更多控制和微调功能 - 集成了对虚拟网络和专用终结点的支持。 - 创建自己的内置连接器。 |
单个逻辑应用资源可以拥有多个有状态和无状态工作流。 单个逻辑应用和租户中的工作流共享相同的处理（计算）、存储和网络等。 数据所在区域与部署逻辑应用的区域相同。 |
标准，基于处于所选定价层的托管计划。 如果运行有状态工作流（这些工作流使用外部存储，Azure 逻辑应用运行时将执行遵循 Azure 存储定价的存储事务。 |
你可以根据方案的需求更改多个限制的默认值。 重要说明：某些限制的具有固定的上限。 在 Visual Studio Code 中，你对逻辑应用项目配置文件中的默认限制值的更改不会反应在设计器体验中。 有关详细信息，请参阅在单租户 Azure 逻辑应用中编辑中逻辑应用的应用和环境设置。 |
| 标准（应用服务环境 v3） 主机环境： 应用服务环境 v3 (ASEv3) - 仅限 Windows 计划 |
与单租户相同的功能，加上以下优势： - 完全隔离逻辑应用。 - 创建和运行比在单租户 Azure 逻辑应用中更多的逻辑应用。 - 无论创建和运行多少逻辑应用，都只需为 ASE 应用服务计划付费。 - 可以使用更多虚拟机实例或其他应用服务计划启用自动缩放或手动缩放。 - 从选定的 ASEv3 继承网络设置。 例如，当你部署到内部 ASE 时，工作流可以访问与 ASE 关联的虚拟网络中的资源，并拥有内部访问点。 注意：如果从内部 ASE 的外部访问，运行该 ASE 中的工作流的历史记录是无法访问操作输入和输出的。 |
单个逻辑应用可以有多个有状态和无状态工作流。 单个逻辑应用和租户中的工作流共享相同的处理（计算）、存储和网络等。 数据所在区域与部署逻辑应用的区域相同。 |
应用服务计划 | 你可以根据方案的需求更改多个限制的默认值。 重要说明：某些限制的具有固定的上限。 在 Visual Studio Code 中，你对逻辑应用项目配置文件中的默认限制值的更改不会反应在设计器体验中。 有关详细信息，请参阅在单租户 Azure 逻辑应用中编辑中逻辑应用的应用和环境设置。 |
标准逻辑应用和工作流
标准逻辑应用和工作流由重新设计的单租户 Azure 逻辑应用运行时提供支持。 此运行时采用 Azure Functions 扩展性模型，并作为扩展托管在 Azure Functions 运行时上。 此设计为逻辑应用工作流提供了可移植性、灵活性和更高的性能，以及继承自 Azure Functions 平台和 Azure 应用服务生态系统的其他功能和优势。 例如，可以在 Azure 应用服务环境 v3（仅限 Windows 计划） 中创建、部署和运行基于单租户的逻辑应用及其工作流。
标准型逻辑应用推出了一个可托管多个工作流的资源结构，类似于 Azure 函数应用可托管多个函数。 使用一对多映射，同一逻辑应用和租户中的工作流可以共享计算和处理资源，从而基于其邻近性而提供更好的性能。 此结构不同于消耗型逻辑应用资源，在消耗型中，逻辑应用资源和工作流之间具有一对一的映射关系。
若要了解有关可移植性、灵活性和性能改进的详细信息，请继续阅读以下各节。 有关单租户 Azure 逻辑应用运行时和 Azure Functions 扩展性的详细信息，请查看以下文档：
可移植性和灵活性
创建标准逻辑应用和工作流时，可以在你的其他环境中部署和运行工作流，例如 Azure 应用服务环境 v3（仅限 Windows 计划）。 如果将 Visual Studio Code 与 Azure 逻辑应用（标准）扩展结合使用，则可以在开发环境中本地开发、生成并运行工作流，而无需将其部署到 Azure。 如果你的方案需要容器，则可以使用已启用 Azure Arc 的逻辑应用创建单租户逻辑应用。 有关详细信息，请参阅什么是已启用 Azure Arc 的逻辑应用？
与多租户模型相比，这些功能提供了重大改进以及实质性的好处，因为多租户模式要求你针对 Azure 中现有的正在运行的资源进行开发。 用于自动执行消耗型逻辑应用资源部署的多租户模型基于 Azure 资源管理器模板（ARM 模板），它能够组合并处理应用和基础结构的资源预配。
借助标准型逻辑应用资源，部署会容易一些，因为可以将应用部署与基础结构部署分离开来。 可以将单租户 Azure 逻辑应用运行时和工作流打包在一起，作为逻辑应用资源或项目的一部分。 可以使用一般步骤或任务来生成、组合逻辑应用资源，并将其压缩到随时可部署的项目中。 若要部署基础结构，仍可以使用 ARM 模板单独预配这些资源以及用于这些目的的其他进程和管道。
若要部署应用，请将项目复制到主机环境，然后启动应用以运行工作流。 或者，使用你了解并使用过的工具和进程将项目集成到部署管道中。 这样，无论用于开发的技术堆栈如何，都可以使用自己选择的工具进行部署。
通过使用标准生成和部署选项，你可以将应用开发与基础结构部署分开进行关注。 因此，你将获得更通用的项目模型，你可以在其中应用多个用于通用应用的类似或相同的部署选项。 为应用生成部署管道以及在发布到生产环境之前运行所需的测试和验证时，还可以从更一致的体验中受益。
性能
借助标准型逻辑应用，可以在同一逻辑应用资源和租户中创建和运行多个工作流。 通过这种一对多的映射，这些工作流共享计算、处理、存储和网络等资源，从而基于其邻近性而提供更好的性能。
标准型逻辑应用资源和单租户 Azure 逻辑应用运行时提供了另一项显著的改进，将更常用的托管连接器作为内置连接器操作提供。 例如，你可以将内置连接器操作用于 Azure 服务总线、Azure 事件中心、SQL Server 等。 同时，托管连接器版本仍然可用并且可以继续工作。
使用新的内置连接器操作时，将创建称为“内置连接”或“服务提供程序连接”的连接。 它们对应的托管连接称为 API 连接，该连接作为随后必须使用 ARM 模板进行部署的 Azure 资源单独创建并运行。 内置操作及其连接在本地运行于与工作流相同的进程中。 两者都托管在单租户 Azure 逻辑应用运行时上。 因此，由于与工作流的邻近性，内置操作及其连接提供的性能更好。 此设计还适用于部署管道，因为服务提供程序连接被打包到相同的生成项目中。
数据驻留
标准型逻辑应用资源托管在单租户 Azure 逻辑应用中，它不会在部署这些逻辑应用资源的区域外部存储、处理或复制数据，这意味着，工作流中的数据将保留在创建和部署其父资源的同一区域中。
直接访问 Azure 虚拟网络中的资源
在任一单租户 Azure 逻辑应用中运行的工作流都可以直接访问 Azure 虚拟网络中存在的安全资源，例如虚拟机 (VM)、其他服务和系统。
单租户 Azure 逻辑应用是 Azure 逻辑应用服务的专用实例，使用专用资源，并独立于多租户 Azure 逻辑应用运行。 在专用实例中运行工作流有助于降低其他 Azure 租户对应用性能的影响，此影响也称为“邻近干扰”影响。
单租户 Azure 逻辑应用还提供以下优势：
你自己的静态 IP 地址，它们不同于多租户 Azure 逻辑应用中的逻辑应用共享的静态 IP 地址。 还可以设置单个公共的、静态的和可预测的出站 IP 地址，以便与目标系统通信。 这样就无需在这些目标系统上设置额外的防火墙开口。
增加了对运行持续时间、存储保留、吞吐量、HTTP 请求和响应超时、消息大小和自定义连接器请求的限制。 有关详细信息，请查看 Azure 逻辑应用的限制和配置。
创建、生成和部署选项
若要基于所需环境创建逻辑应用资源，你有多个选择，例如：
单租户环境
| 选项 | 资源和工具 | 更多信息 |
|---|---|---|
| Azure 门户 | 标准型逻辑应用 | 在单租户 Azure 逻辑应用中创建“标准”逻辑应用工作流 - Azure 门户 |
| Visual Studio Code | Azure 逻辑应用（标准版）扩展 | 在单租户 Azure 逻辑应用中创建“标准”逻辑应用工作流 - Visual Studio Code |
| Azure CLI | 逻辑应用 Azure CLI 扩展 | az logicapp |
| Azure 资源管理器 | - 本地 - DevOps |
单租户 Azure 逻辑应用 |
| 已启用 Azure Arc 的逻辑应用 | 已启用 Azure Arc 的逻辑应用示例 | - 什么是已启用 Azure Arc 的逻辑应用？ - 使用已启用 Azure Arc 的逻辑应用创建和部署基于单租户的逻辑应用工作流 |
| Azure REST API | Azure 应用服务 REST API* 注意：标准逻辑应用 REST API 包含在 Azure 应用服务 REST API 中。 |
Azure REST API 参考入门 |
多租户环境
| 选项 | 资源和工具 | 更多信息 |
|---|---|---|
| Azure 门户 | 消耗型逻辑应用 | 快速入门：在多租户 Azure 逻辑应用中创建示例消耗型逻辑应用工作流 - Azure 门户 |
| Visual Studio Code | Azure 逻辑应用（消耗版）扩展 | 快速入门：在多租户 Azure 逻辑应用中创建示例消耗型逻辑应用工作流 - Visual Studio Code |
| Azure CLI | 逻辑应用 Azure CLI 扩展 | - 快速入门：在多租户 Azure 逻辑应用中创建和管理消耗型逻辑应用工作流 - Azure CLI - az logic |
| Azure 资源管理器 | 创建逻辑应用 ARM 模板 | 快速入门：在多租户 Azure 逻辑应用中创建和部署消耗型逻辑应用工作流 - ARM 模板 |
| Azure PowerShell | Az.LogicApp 模块 | Azure PowerShell 入门 |
| Azure REST API | Azure 逻辑应用 REST API | Azure REST API 参考入门 |
尽管开发体验因创建的逻辑应用资源类型（消耗版或标准版）而异，但可以在 Azure 订阅下找到并访问所有已部署的逻辑应用 。
例如，在 Azure 门户中，逻辑应用页会同时显示消耗型和标准型逻辑应用资源。 在 Visual Studio Code 中，已部署的逻辑应用显示在 Azure 订阅下，但消耗型逻辑应用显示在 Azure 逻辑应用（消耗）扩展下的 Azure 窗口中，而标准型逻辑应用则显示在“资源”部分下。
有状态和无状态工作流
在标准型逻辑应用中，可以创建以下工作流类型：
有状态
如果需要保留、查看或引用来自先前事件的数据，则创建有状态工作流。 这些工作流将所有操作的输入、输出和状态保存到外部存储。 完成每次运行后，可以通过这些信息来查看工作流运行详细信息和历史记录。 如果服务中断，有状态工作流提供高复原能力。 在服务和系统还原后，你可从已保存的状态重新构造中断的运行，并再次运行工作流来完成操作。 有状态工作流可以比无状态工作流持续运行更长的时间。
默认情况下，多租户和单租户 Azure 逻辑应用中的有状态工作流以异步方式运行。 所有基于 HTTP 的操作都遵循标准异步操作模式。 在 HTTP 操作调用某个终结点、服务、系统或 API 或向其发送请求后，请求接收方立即返回“202 已接受”响应。 此代码确认接收方已接受请求，但尚未完成处理。 响应可能包括一个
location标头，该标头指定的 URI 和刷新 ID 可供调用方用于轮询或检查异步请求的状态，直到接收方停止处理并返回“200 正常”成功响应或其他非 202 响应。 但是，调用方不必等待请求完成处理即可继续运行下一操作。 有关详细信息，请参阅异步微服务集成强制实施微服务自治。无状态
如果不需要在每个运行完成后保留、查看或引用外部存储中的先前事件的数据（供以后查看），请创建无状态工作流。 这些工作流将每个操作的所有输入和输出及其状态仅保存在内存中，而不保存在外部存储中。 结果就是，由于外部存储不保存工作流运行详细信息和历史记录，因此无状态工作流可以在更短时间内完成运行（通常不超过 5 分钟）、性能更高、响应时间更短、吞吐量更高且运行成本更低。 不过，如果服务中断，已中断的运行不会自动还原，因此调用方需要重新手动提交已中断的运行。
无状态工作流在处理总大小不超过 64 KB 的数据或内容（例如文件）时提供最佳性能。 内容较大（例如，多个大型附件）可能会显著降低工作流的性能，甚至会由于内存不足异常而导致工作流崩溃。 如果工作流可能需要处理较大的内容，请改用有状态工作流。
注意
在无状态工作流中，只能使用推送触发器，而不能指定工作流的运行计划。 这些基于 Webhook 的触发器会等待事件发生或数据变得可用。 例如，重复触发器仅适用于有状态工作流。 若要启动工作流，请选择推送触发器，例如请求、事件中心或服务总线触发器。 若要详细了解受限、不可用或不受支持的触发器、操作和连接器，请查看已更改、受限、不可用或不受支持的功能。
无状态工作流仅同步运行，因此不使用有状态工作流所用的标准异步操作模式。 不过，所有返回“202 已接受”响应的基于 HTTP 的操作都会继续完成工作流执行过程中的下一步。 如果响应包含
location标头，则无状态工作流不会轮询指定的 URI 来检查状态。 若要遵循标准异步操作模式，请改用有状态工作流。为了简化调试，你可为无状态工作流启用运行历史记录（这对性能有一些影响），然后在完成时再禁用运行历史记录。 有关详细信息，请参阅在 Visual Studio Code 中创建基于单租户的工作流或在 Azure 门户中创建基于单租户的工作流。
重要
你必须决定要在创建时实施的工作流类型（有状态或无状态）。 创建后更改工作流类型会导致运行时错误。
有状态和无状态工作流之前的差异摘要
| 有状态 | 无状态 |
|---|---|
| 存储运行历史记录、输入和输出 | 默认情况下，不存储运行历史记录、输入或输出 |
| 托管连接器触发器可用且被允许 | 托管连接器触发器不可用或不被允许 |
| 支持分块 | 不支持分块 |
| 支持异步操作 | 不支持异步操作 |
| 在主机配置中编辑默认的最大运行持续时间 | 非常适用于最大持续时间在 5 分钟以内的工作流 |
| 处理大型消息 | 非常适用于处理小型消息（大小在 64 KB 以内） |
有状态和无状态工作流之前的嵌套行为差异
可以使用请求触发器、HTTP Webhook 触发器，或者具有 ApiConnectionWebhook 类型且可接收 HTTPS 请求的托管连接器触发器，使工作流可从同一标准型逻辑应用中存在的其他工作流调用。
下表描述了在父工作流调用子工作流之后，嵌套工作流可遵循的行为模式：
异步轮询模式
父工作流不会等待子工作流响应其初始调用。 但是，父级会持续检查子级的运行历史记录，直到子级完成运行。 默认情况下，有状态工作流采用这种模式，它非常适合可能会超出请求超时限制的长期运行的子工作流。
同步模式（“触发并忘记”）
子工作流通过立即返回
202 ACCEPTED响应来确认父工作流的调用。 但是，父级不会等待子级返回结果。 相反，父级会继续执行工作流中的下一个操作，并在子级完成运行时接收结果。 不包含响应操作的有状态子工作流始终遵循同步模式，并提供运行历史记录供你查看。若要启用此行为，请在工作流的 JSON 定义中，将
operationOptions属性设置为DisableAsyncPattern。 有关详细信息，请查看触发器和操作类型 - 操作选项。触发并等待
无状态工作流在内存中运行。 因此，父工作流调用无状态子工作流时，父工作流会等待子工作流返回结果的响应。 此模式的工作方式类似于使用内置的 HTTP 触发器或操作来调用子工作流。 不包含响应操作的无状态子工作流会立即返回
202 ACCEPTED响应，但父工作流会等待子工作流完成，然后才继续到下一操作。 这些行为仅适用于无状态子工作流。
下表根据父工作流和子工作流是有状态、无状态还是混合工作流类型，来确定子工作流的行为。 表后面的列表
| 父工作流 | 子工作流 | 子工作流行为 |
|---|---|---|
| 有状态 | 有状态 | 同步或异步，带有 "operationOptions": "DisableAsyncPattern" 设置 |
| 有状态 | 无状态 | 触发并等待 |
| 无状态 | 有状态 | 同步 |
| 无状态 | 无状态 | 触发并等待 |
其他单租户模型功能
单租户模型和标准型逻辑应用包括许多当前功能和新功能，例如：
通过超过数百个托管连接器，针对本地系统的服务型软件 (SaaS) 应用、平台即服务 (PaaS) 和服务加连接器创建逻辑应用及其工作流。
现在，在标准型工作流中，提供了更多的托管连接器作为内置连接器。 内置版本在单租户 Azure 逻辑应用运行时上以原生方式运行。 某些内置连接器也被非正式地称为服务提供程序连接器。 有关列表，请查看消耗型和标准型内置连接器。
可以使用单租户 Azure 逻辑应用扩展性框架为所需的所有服务创建你自己的自定义内置连接器。 与 Azure 服务总线和 SQL Server 等内置连接器相似，自定义内置连接器可提供更高的吞吐量、低延迟和本地连接，因为它们在与单租户运行时相同的进程中运行。 但是，自定义内置连接器与目前不受支持的自定义托管连接器并不相似。 有关详细信息，请查看自定义连接器概述和为单租户 Azure 逻辑应用中的标准逻辑应用创建自定义内置连接器。
如果没有集成帐户，可对 Liquid 操作和 XML 操作使用以下操作。 这些操作包括以下操作：
XML：转换 XML 和 XML 验证
Liquid：将 JSON 转换为 JSON、将 JSON 转换为文本、将 XML 转换为 JSON 以及将 XML 转换为文本
注意
若要在标准型工作流中使用这些操作，需要具有 Liquid 映射、XML 映射或 XML 架构。 可以在 Azure 门户中，从逻辑应用的资源菜单的“项目”（下其中包括“架构”和“映射”部分），上传这些项目 。 或者，可以使用相应的“映射”和“架构”文件夹，将这些项目添加到 Visual Studio Code 项目的“项目”文件夹 。 然后，可以在同一逻辑应用中跨多个工作流使用这些工件。
标准型逻辑应用工作流可以在任何位置运行，因为 Azure 逻辑应用可生成共享访问签名 (SAS) 连接字符串，而这些逻辑应用可使用这些字符串将请求发送到云连接运行时终结点。 Azure 逻辑应用会将这些连接字符串随其他应用程序设置一起保存，这样你在 Azure 中部署时，可在 Azure Key Vault 中轻松存储这些值。
标准型逻辑应用工作流支持同时启用系统分配的托管标识 和多个用户分配的托管标识，尽管一次只能选择一个要使用的标识。 虽然内置、基于服务提供商的连接器支持使用系统分配的标识，但大多数连接器目前不支持选择用户分配的托管标识进行身份验证，SQL Server 和 HTTP 连接器除外。
注意
在默认情况下，已启用系统分配的标识，以便在运行时对连接进行身份验证。 该标识与你在创建连接时使用的身份验证凭据或连接字符串不同。 如果禁用该标识，则运行时连接无效。 若要查看此设置，请在逻辑应用菜单的“设置”下，选择“标识” 。
可在 Visual Studio Code 开发环境中本地运行、测试和调试逻辑应用及其工作流。
在运行和测试逻辑应用之前，可在工作流的 workflow.json 文件中添加和使用断点来简化调试。 不过，断点目前仅可用于操作，不可用于触发器。 有关详细信息，请参阅在 Visual Studio Code 中创建基于单租户的工作流。
将逻辑应用及其工作流从 Visual Studio Code 直接发布或部署到各种托管环境中，例如 Azure 和已启用 Azure Arc 的逻辑应用。
如果你的 Azure 订阅和逻辑应用设置支持，可使用 Application Insights 为逻辑应用启用诊断日志记录和跟踪功能。
访问网络功能（例如连接功能）并以专用方式与 Azure 虚拟网络集成，这与你在使用 Azure Functions 高级计划创建和部署逻辑应用时的 Azure Functions 很相似。 有关详细信息，请查看以下文档：
为标准型逻辑应用中单个工作流使用的托管连接重新生成访问密钥。 在此任务中，请遵循消耗型逻辑应用的相同步骤，但在工作流级别执行，而不是逻辑应用资源级别。
适用于标准版的内置连接器
标准型工作流可以使用许多与消耗型工作流相同的内置连接器，但并非全部。 反之亦然，标准型工作流具有许多在消耗型工作流中不可用的内置连接器。
例如，标准型工作流有适用于 Azure Blob、Azure Cosmos DB、Azure 事件中心、Azure 服务总线、DB2、FTP、MQ、SFTP、SQL Server 等的托管连接器和内置连接器。 尽管消耗型工作流没有这些相同的内置连接器版本，但其他内置连接器（例如 Azure API 管理和 Azure 应用服务）可用。
在单租户 Azure 逻辑应用中，具有特定属性的内置连接器称为“服务提供程序”（非正式）。 一些内置连接器仅支持一种方法来验证与基础服务的连接。 其他内置连接器可以提供选择，例如使用连接字符串、Microsoft Entra ID 或托管标识。 所有内置连接器都与重新设计的 Azure 逻辑应用运行时在同一进程中运行。 有关详细信息，请查看标准逻辑应用工作流的内置连接器列表。
重要
请确保正确设置并测试任何基于服务提供商的触发器，以确认操作成功。 基于服务提供商的失败触发器可能会创建不必要的缩放，这可以显著增加计费成本。 例如，一个常见的错误是设置触发器而不向逻辑应用授予对目标（例如服务总线队列、Azure 存储 blob 容器等）的权限或访问权限。 此外，请确保随时监视此类触发器，以便可以及时检测和修复任何问题。
已更改、受限、不可用或不受支持的功能
对于标准型逻辑应用工作流，下列功能已经过更改，或者目前受限、不可用或不受支持：
触发器和操作：内置触发器和操作在 Azure 逻辑应用中本地运行，而托管连接器使用共享资源在 Azure 中托管和运行。 对于标准型工作流，一些内置触发器和操作当前不可用，例如滑动窗口、Azure 应用服务和 Azure API 管理。 若要启动有状态或无状态工作流，请使用内置触发器，例如请求、事件中心或服务总线触发器。 定期触发器仅适用于有状态工作流，不适用于无状态工作流。 在设计器中，内置触发器和操作与应用内标签一起显示，而托管连接器触发器和操作则与共享标签一起显示。
无状态工作流只能使用推送触发器，而不能指定工作流的运行计划。 这些基于 Webhook 的触发器会等待事件发生或数据变得可用。 例如，重复触发器仅适用于有状态工作流。 若要启动工作流，请选择推送触发器，例如请求、事件中心或服务总线触发器。 虽然可为无状态工作流启用托管连接器，但连接器库中不会显示任何托管连接器的轮询触发器供你添加。
注意
若要在 Visual Studio Code 中本地运行，基于 Webhook 的触发器和操作需要额外设置。 有关详细信息，请参阅在 Visual Studio Code 中创建基于单租户的工作流。
以下触发器和操作已经过更改，或者目前功能受限、不受支持或不可用：
Azure Functions - 选择 Azure 函数这一内置操作现在名为“Azure 函数操作 - 调用 Azure 函数”。 此操作目前仅适用于通过 HTTP 触发器模板创建的函数。
在 Azure 门户中，可选择一个 HTTP 触发器函数，你可通过用户体验创建连接来访问此函数。 如果使用 Visual Studio Code 在代码视图或 workflow.json 文件中检查函数操作的 JSON 定义，则操作会使用
connectionName引用来引用函数。 此版本会将函数的信息抽象化处理为一个连接，可在逻辑应用项目的 connections.json 文件中找到它，这是在 Visual Studio Code 中创建连接后提供的。注意
在单租户模型中，函数操作仅支持查询字符串身份验证。 Azure 逻辑应用会在建立连接时从函数中获取默认密钥、将该密钥存储在应用的设置中，并在调用函数时使用该密钥来进行身份验证。
与多租户模型一样，如果你续订此密钥（例如通过门户中的 Azure Functions 体验），且由于密钥无效，函数操作会失效。 若要解决此问题，需要重新创建与你想要调用的函数的连接，或者使用新密钥更新应用的设置。
Azure 逻辑应用 - 创建逻辑应用工作流这一内置操作现在名为“工作流操作 - 在此工作流应用中调用工作流”。
目前不支持 Gmail 连接器。
当前不支持自定义托管连接器。 但是，在使用 Visual Studio Code 时，可以创建自定义内置操作。 有关详细信息，请查看使用 Visual Studio Code 创建基于单租户的工作流。
标准逻辑应用工作流只能有一个触发器，不支持多个触发器。
身份验证：以下身份验证类型目前不适用于标准型工作流：
Microsoft Entra ID 开放式身份验证 (Microsoft Entra ID OAuth)，用于对基于请求的触发器（例如请求触发器和 HTTP Webhook 触发器）进行入站调用。
托管标识身份验证：同时提供系统分配的托管标识和用户分配的托管标识支持。 默认情况下，会自动启用系统分配的托管标识。 但是，大多数基于服务提供商的内置连接器目前不支持选择用户分配的托管标识进行身份验证。
XML 转换：目前仅支持 XSLT 1.0。
Visual Studio Code 中的断点调试：虽然可在工作流的 workflow.json 文件中添加和使用断点，但目前仅可对操作使用断点，不可将其用于触发器。 有关详细信息，请参阅在 Visual Studio Code 中创建基于单租户的工作流。
触发器历史记录和运行历史记录：对于标准型逻辑应用，Azure 门户中的触发器历史记录和运行历史记录显示在工作流级别，而非逻辑应用资源级别。 有关详细信息，请查看使用 Azure 门户创建基于单租户的工作流。
工作流运行历史记录的备份和还原：标准型逻辑应用目前不支持工作流运行历史记录的备份和还原。
Terraform 模板：不能将这些模板与标准逻辑应用资源一起用于进行完整的基础结构部署。 有关详细信息，请参阅什么是 Azure 上的 Terraform？
Azure API 管理：当前无法将标准型逻辑应用资源导入 Azure API 管理。 但是，可以导入消耗型逻辑应用资源。
严格的网络和防火墙流量权限
如果你的环境设有限制流量的严格网络要求或防火墙，则必须允许访问以在工作流中实现任何触发器或操作连接。 可以选择允许来自服务标记的流量，并使用与 Azure 应用服务相同级别的限制或策略。 还需查找完全限定的域名 (FQDN) 并为连接适用这些域名。 有关详细信息，请查看以下文档中的相应部分：
后续步骤
我们还希望你就单租户 Azure 逻辑应用体验提供反馈！
- 如果发现 bug 或问题，请在 GitHub 中创建问题。
- 如有问题、请求、意见和其他反馈，请使用此反馈表单。