在 Azure 门户中创建示例标准逻辑应用工作流 - Azure Logic Apps

创建标准逻辑应用资源

在 Azure 门户中，使用 Azure 帐户登录。

在 Azure 门户搜索框中，输入“ 逻辑应用 ”，然后选择“ 逻辑应用 ”。

在“逻辑应用”页上，选择“添加” 。

在“创建逻辑应用”页中的“基本信息”选项卡上，提供有关你的逻辑应用的以下基本信息：

< Azure-resource-group-name > 你在其中创建逻辑应用和相关资源的 Azure 资源组。此名称在各个区域中必须是唯一的，并且只能包含字母、数字、连字符 ( - )、下划线 (_)、括号 (()) 和句点 (.)。

此示例创建一个名为 Fabrikam-Workflows-RG 的资源组。 逻辑应用名称 < logic-app-name > 逻辑应用资源名称在各个区域中必须唯一，且只能包含字母、数字、连字符( - )、下划线( _ )、括号( () )和句点( . )。

注意：逻辑应用的名称会自动获取后缀 .azurewebsites.net ，因为标准逻辑应用资源由单租户 Azure 逻辑应用运行时提供支持，该运行时使用 Azure Functions 扩展性模型，并作为扩展托管在 Azure Functions 运行时上。 Azure Functions 使用相同的应用命名约定。

此示例创建一个名为 Fabrikam-Workflows 的逻辑应用。 < plan-name > 要使用的计划名称。选择一个现有计划名称或为新计划提供一个名称。

此示例使用的名称为“ My-App-Service-Plan ”。

注意：仅支持基于 Windows 的应用服务计划。请勿使用基于 Linux 的应用服务计划。 < pricing-tier > 用于逻辑应用和工作流的定价层。你的选择会影响逻辑应用和工作流使用的定价、计算、内存和存储。

有关详细信息，请查看托管计划和定价层。 Workflow 只有在“计划类型”设置为“标准”逻辑应用类型时，才会显示和应用此选项。默认情况下，此选项设置为“工作流”并创建一个空的逻辑应用资源，可以在其中添加你的第一个工作流。

注意：目前，“Docker 容器”选项要求已启用 Azure Arc 的 Kubernetes 群集上有自定义位置，你可将该群集与已启用 Azure Arc 的逻辑应用（标准版）配合使用。逻辑应用资源位置、自定义位置和群集必须相同。 < Azure-region > 用于存储应用信息的 Azure 数据中心区域。此示例将示例逻辑应用部署到 Azure 中的“美国西部”区域。

- 如果先前选择了“Docker 容器”，请从“区域”列表中选择自定义位置。

- 如果要将应用部署到现有的应用服务环境 v3 资源，可以从“区域”列表中选择该环境。

如果选择支持可用性区域冗余的 Azure 区域，则会启用“区域冗余”部分。此部分提供了为逻辑应用启用可用性区域冗余的选项。但是，当前支持的 Azure 区域不包括 美国西部 ，因此可以忽略本示例的此部分。有关详细信息，请参阅通过区域冗余和可用性区域保护逻辑应用免受区域故障的影响。

完成后，设置应如以下示例所示：

在“托管”选项卡上，提供有关要用于逻辑应用的存储解决方案和托管计划的以下信息。

- Azure 存储
- SQL 和 Azure 存储 要用于工作流相关的项目和数据的存储类型。

- 若要仅部署到 Azure，请选择“Azure 存储”。

- 若要将 SQL 用作主存储，并将 Azure 存储用作辅助存储，请选择“SQL 和 Azure 存储”，并查看在单租户 Azure 逻辑应用中为标准逻辑应用设置 SQL 数据库存储。

注意：如果要部署到 Azure 区域，则仍然需要 Azure 存储帐户，该帐户用于在 Azure 逻辑应用平台上完成对逻辑应用配置的一次托管。进行中的工作流状态、运行历史记录和其他运行时项目均存储在 SQL 数据库中。

若要部署到托管在 Azure Arc 群集上的自定义位置，将 SQL 用作存储提供程序即可。 < Azure-storage-account-name > 要用于存储事务的 Azure 存储帐户。

此资源名称在各个区域中必须唯一，长度为 3-24 个字符，并且仅包含数字和小写字母。选择一个现有的帐户，或者创建一个新帐户。

此示例创建了名为 mystorageacct 的存储帐户。

如果创建和部署设置支持使用 Application Insights ，可以选择为逻辑应用工作流启用诊断日志记录和跟踪。

在“监视”选项卡上的“Application Insights”下，将“启用 Application Insights”设置为“是”（如果尚未选择）。

对于“Application Insights”设置，请选择一个现有 Application Insights 实例，如果要创建新的实例，请选择“新建”并提供要使用的名称。

在 Azure 验证你的逻辑应用设置后，在“查看 + 创建”选项卡上选择“创建”，例如：

如果在此步骤中收到验证错误，请打开并查看错误详细信息。例如，如果所选区域达到了你要尝试创建的资源的配额，则你可能必须尝试另一个区域。

Azure 完成部署后，你的逻辑应用资源将自动处于活动状态，但不会执行任何操作，因为资源为空，并且尚未添加任何工作流。

在部署完成页上，选择“转到资源”，以便可以添加空白工作流。

在“ 新建工作流 ”窗格打开后，为工作流提供一个名称，并选择“ 有状态 ”或“ 无状态 ”工作流类型。完成操作后，选择“创建”。

此示例添加了名为 Stateful-Workflow 的空白有状态工作流。默认情况下，工作流处于启用状态，但在你添加触发器和操作之前，它不会执行任何操作。

从工作流列表中，选择该空白有状态工作流。

在工作流菜单上的“开发人员”下，选择“设计器” 。

设计器界面显示了选择触发操作的提示。默认情况下，提示已选择，以便具有可用触发器的窗格已显示打开。

那么现在，你将添加一个用于启动工作流的触发器。

添加触发器

此示例工作流从名为“ 收到 HTTP 请求时 ”的内置请求触发器开始。此触发器会创建一个终结点，其他服务或逻辑应用工作流可以调用该终结点，并等待这些入站调用或请求到达。内置操作以本机方式运行，直接在 Azure 逻辑应用运行时中运行。

标准（预览）

在工作流设计器中，确保空白工作流处于打开状态，并且在设计器界面上选中了“ 选择操作 ”提示。

使用请求作为搜索词，按照以下步骤将名为“ 收到 HTTP 请求时 ”的内置请求触发器添加到工作流。

当触发器出现在设计器上时，触发器的信息窗格会打开，显示触发器的属性、设置和其他操作。

如果信息窗格未显示，请确保在设计器上选中该触发器。

保存工作流。在设计器工具栏上选择“保存”。

在工作流设计器中，确保空白工作流处于打开状态，并且在设计器界面上选中了“ 添加触发器 ”提示。

使用请求作为搜索词，按照以下步骤将名为“ 收到 HTTP 请求时 ”的内置请求触发器添加到工作流。

当触发器出现在设计器上时，触发器的信息窗格会打开，显示触发器的属性、设置和其他操作。

保存工作流。在设计器工具栏上选择“保存”。

首次保存工作流时，如果工作流是通过请求触发器启动的，则 Azure 逻辑应用会自动为请求触发器创建的终结点生成 URL。稍后，在你测试工作流时，将向此 URL 发送请求，这会激发触发器并启动工作流运行。

此示例工作流继续使用名为“ 发送电子邮件 ”的 Office 365 Outlook 托管连接器操作。托管连接器操作在 Azure 中运行，而不是在本机运行，它直接在 Azure 逻辑应用运行时上运行。

标准（预览）

设计器上将显示“ 选择操作 ”提示，并且“ 添加操作 ”窗格将打开，以便你可以选择下一个操作。

通过使用 office 365 发送电子邮件 作为搜索词，按照以下步骤将名为“ 发送电子邮件 (V2) ”的 Office 365 Outlook 操作添加到工作流。

在操作的信息窗格的“ 创建连接 ”选项卡上，选择“ 登录 ”，以便可以创建与电子邮件帐户的连接。

当系统提示你访问电子邮件帐户时，请使用你的帐户凭据登录。

如果收到错误消息 “失败，出现错误：‘浏览器已关闭。’。请重新登录” ，请检查浏览器是否阻止第三方 Cookie。如果这些 cookie 被阻止，请尝试将 https://portal.azure.com 添加到可以使用 cookie 的站点列表。如果使用的是 incognito 模式，请确保在该模式下工作时不会阻止第三方 cookie。

如有必要，请重新加载页面，打开你的工作流，再次添加电子邮件操作，然后尝试创建连接。

在 Azure 创建连接后，“发送电子邮件”操作将显示在设计器上，并且默认情况下处于选中状态。如果未选择该操作，请选择，以便其信息窗格也打开。

在操作信息窗格的“ 参数 ”选项卡上，提供操作所需的信息，例如：

在信息窗格的“ 设置 ”、“ 静态结果 ”或“ 随后运行 ”选项卡上进行任何更改时，请确保在切换选项卡或将焦点更改为设计器之前选择“ 完成 ”以提交这些更改。否则，设计器不会保留所做的更改。

保存所有内容。在设计器工具栏上选择“保存”。

如果你的环境具有限制流量的严格网络要求或防火墙，则必须为工作流中存在的任何触发器或操作连接设置权限。若要查找完全限定的域名，请查看查找用于防火墙访问的域名。

否则，若要测试工作流，请手动触发运行。

此时会打开“ 浏览操作 ”窗格，以便你可以选择下一个操作。

通过使用 office 发送电子邮件 作为搜索词，按照以下步骤将名为“ 发送电子邮件 (V2) ”的 Office 365 Outlook 操作添加到工作流。

在操作的信息窗格的“ 创建连接 ”选项卡上，选择“ 登录 ”，以便可以创建与电子邮件帐户的连接。

当系统提示你访问电子邮件帐户时，请使用你的帐户凭据登录。

如有必要，请重新加载页面，打开你的工作流，再次添加电子邮件操作，然后尝试创建连接。

在 Azure 创建连接后，“发送电子邮件”操作将显示在设计器上，并且默认情况下处于选中状态。如果未选择该操作，请选择，以便其信息窗格也打开。

在操作信息窗格的“ 参数 ”选项卡上，提供操作所需的信息，例如：

保存所有内容。在设计器工具栏上选择“保存”。

否则，若要测试工作流，请手动触发运行。

查找用于防火墙访问的域名

在 Azure 门户中部署逻辑应用并运行工作流之前，如果你的环境具有限制流量的严格网络要求或防火墙，则必须为逻辑应用中存在的工作流中的任何触发器或操作连接设置网络或防火墙权限。

若要查找逻辑应用和工作流所使用的入站和出站 IP 地址，请执行以下步骤：

在逻辑应用菜单上的“设置”下，选择“网络(预览版)” 。

在“网络”页上，查找并查看“入站流量”和“出站流量”部分。

若要查找用于连接的完全限定的域名 (FQDN)，请执行以下步骤：

在逻辑应用菜单上的“工作流”下，选择“连接”。在“API 连接”选项卡上，选择连接的资源名称，例如：

充分扩展浏览器的宽度，以便在浏览器的右上角出现“JSON 视图”时，选择“JSON 视图”。

复制 connectionRuntimeUrl 属性值并将其保存到安全位置，以便可以使用此信息设置防火墙。

对于每个连接，重复相关步骤。

触发工作流

在此示例中，工作流在请求触发器收到入站请求时运行，该请求将发送到触发器所创建的终结点的 URL。首次保存工作流时，Azure 逻辑应用自动生成了此 URL。因此，你需要找到此 URL，然后才能发送此请求来触发工作流。

在工作流设计器上，选择名为“当收到 HTTP 请求时”的请求触发器。

在信息窗格打开后，在“ 参数 ”选项卡上找到“ HTTP POST URL ”属性。若要复制生成的 URL，请选择“复制 URL”（“复制文件”图标），并暂时将 URL 保存到其他位置。此 URL 遵循以下格式：

https://<*logic-app-name*>.azurewebsites.net:443/api/<*workflow-name*>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<*shared-access-signature*>

对于此示例，URL 如下所示：

https://fabrikam-workflows.azurewebsites.net:443/api/Fabrikam-Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=xxxxxXXXXxxxxxXXXXxxxXXXXxxxxXXXX

还可以在逻辑应用的“概览”窗格中的“工作流 URL”属性中找到终结点 URL。

在资源菜单中，选择“概述”。

在“概述”窗格中，找到“工作流 URL”属性。

若要复制终结点 URL，请将指针移到“终结点 URL”文本的末尾，然后选择“复制到剪贴板”（“复制文件”图标）。

若要发送请求来测试 URL，请打开 Postman 或你习惯用来创建和发送请求的工具。

此示例使用 Postman 继续。有关详细信息，请参阅 Postman 入门。

在 Postman 工具栏上，选择“新建”。

在“新建”窗格上的“构建基块”下，选择“请求”。

在“ 保存请求 ”窗口的“ 请求名称 ”下，提供请求名称，例如 测试工作流触发器 。

在“选择要保存到的集合或文件夹”下，选择“创建集合”。

在“所有集合”下，为要创建的用于组织你的请求的集合提供一个名称，按 Enter，然后选择“保存到<集合名称>”。此示例使用 逻辑应用请求 作为集合名称。

在 Postman 应用中，会打开请求窗格，以便将请求发送到请求触发器的终结点 URL。

在请求窗格上的方法列表（当前显示了 GET 作为默认请求方法）旁边的地址栏中，粘贴以前复制的 URL，然后选择“发送”。

当触发了触发器时，示例工作流将运行，并发送类似于以下示例的电子邮件：

查看运行历史记录

对于有状态工作流，在每个工作流运行后，你可以查看运行历史记录，包括整个运行的状态、触发器的状态，以及每个操作的状态及其输入和输出。在 Azure 门户中，运行历史记录和触发器历史记录显示在工作流级别，而非逻辑应用级别。若要在运行历史记录上下文外部查看触发器历史记录，请参阅查看触发器历史记录。

在 Azure 门户中的工作流菜单上，选择“概述”。

在“概述”窗格上，选择“运行历史记录”，其中显示了该工作流的运行历史记录。

如果未显示最新的运行状态，请在“概述”窗格工具栏上选择“刷新” 。如果由于不符合条件或找不到数据而跳过了触发器，则不会发生运行。

下表显示了每个工作流运行可能具有并在门户中显示的最终状态：

运行已被触发并正在进行，但如果运行由于操作限制或当前定价计划而被限制，也可能会显示此状态。

提示：如果你设置了诊断日志记录，则可以获取发生的任何限制事件的相关信息。运行已成功。如果有任何操作失败，工作流中的后续操作已处理了该失败。运行超时，因为当前持续时间超出了运行持续时间限制，该限制由 “运行历史记录保留期(天)” 设置控制。运行持续时间是使用运行开始时间和在该开始时间有效的运行持续时间限制来计算的。

注意：如果运行的持续时间还超出了当前的运行历史记录保留期限制（该限制也由 “运行历史记录保留期(天)” 设置控制），则每日清理作业会将该运行从运行历史记录中清除。无论运行是超时还是完成，始终都将使用运行的开始时间和当前保留期限制来计算保留期。因此，如果你减小进行中的某个运行的持续时间限制，则该运行将超时。但是，运行将保留或从运行历史记录中清除，具体取决于运行持续时间是否超出了保留期限制。运行尚未启动或已暂停，例如，由于前一个工作流实例仍在运行。此操作已跳过，因为不满足其 runAfter 条件（例如，先前的操作失败）。每个操作都有一个


    runAfter

对象，你可以在其中设置必须满足的条件，然后才能执行当前操作。操作已成功。操作已成功，但是在一次或多次重试后才成功。若要查看重试历史记录，请在运行历史记录详细信息视图中选择该操作，以便可以查看输入和输出。操作由于超出了操作设置指定的超时限制而停止。适用于正在等待来自调用方的入站请求的 Webhook 操作。

查看触发器历史记录

对于有状态工作流，你可以独立于运行历史记录上下文查看每个运行的触发器历史记录，包括触发器状态以及输入和输出。在 Azure 门户中，触发器历史记录和运行历史记录显示在工作流级别，而非逻辑应用级别。若要查找此历史数据，请执行以下步骤：

在 Azure 门户中的工作流菜单上，选择“概述”。

在“概述”页面上，选择“触发历史记录” 。

“触发器历史记录”窗格将显示你的工作流运行的触发器历史记录。

若要查看特定的触发器历史记录，请选择该运行的 ID。

最佳做法和建议

为了获得最佳设计器的响应能力和性能，请查看并遵循以下准则：

每个工作流使用不超过 50 个操作。超过此数量的操作可能会降低设计器的性能。

考虑在必要时将业务逻辑拆分为多个工作流。

每个逻辑应用资源的工作流不超过 10-15 个。

在部署后启用或打开 Application Insights

在工作流运行过程中，你的逻辑应用会发出遥测数据以及其他事件。使用此遥测数据可以更好地了解工作流的运行情况以及逻辑应用运行时如何以各种方式工作。你可以使用 Application Insights 来监视工作流，该工具可提供近乎实时的遥测数据（实时指标）。使用该数据来诊断问题、设置警报和构建图表时，此功能可帮助你更轻松地调查失败和性能问题。

如果逻辑应用的创建和部署设置支持使用 Application Insights ，则可以选择为逻辑应用启用诊断日志记录和跟踪。你可以在从 Azure 门户中创建逻辑应用时或在部署后执行此操作。你需要有一个 Application Insights 实例，但你可以在创建逻辑应用时提前创建此资源，或在部署后创建此资源。

若要在已部署的逻辑应用上启用 Application Insights 或要打开 Application Insights 仪表板（如果已启用），请执行以下步骤：

在 Azure 门户中，找到你的已部署逻辑应用。

在逻辑应用菜单上，在“设置”下，选择“Application Insights” 。

如果未启用 Application Insights，请在“Application Insights”窗格上选择“启用 Application Insights”。在窗格更新后，选择底部的“应用”>“是” 。

如果启用了 Application Insights，请在“Application Insights”窗格上选择“查看 Application Insights 数据”。

在 Application Insights 打开后，你可以查看逻辑应用的各种指标。有关详细信息，请查看以下主题：

Azure Logic Apps Running Anywhere - Monitor with Application Insights - part 1 （随处运行的 Azure 逻辑应用 - 使用 Application Insights 进行监视 - 第 1 部分）

Azure Logic Apps Running Anywhere - Monitor with Application Insights - part 2 （随处运行的 Azure 逻辑应用 - 使用 Application Insights 进行监视 - 第 2 部分）

为无状态工作流启用运行历史记录

若要更轻松地调试某个无状态工作流，可以为该工作流启用运行历史记录，并在完成后禁用运行历史记录。对于 Azure 门户，请按照下面的步骤操作；如果使用的是 Visual Studio Code，请参阅在 Visual Studio Code 中创建有状态和无状态工作流。

在 Azure 门户中，打开你的标准逻辑应用资源。

在逻辑应用菜单上的“设置”下，选择“配置” 。

在“应用程序设置”选项卡上，选择“新建应用程序设置” 。

在“添加/编辑应用程序设置”窗格上的“名称”框中，输入此操作选项名称：

Workflows.{ yourWorkflowName }.OperationOptions

在“ 值 ”框中，输入以下值： WithStatelessRunHistory

若要完成此任务，请选择“确定”。在“配置”窗格工具栏上，选择“保存”。

要在完成时禁用运行历史记录，请将名为 .{ your-workflow-name }.OperationOptions 的属性设置为无，或者删除该属性及其值。

使用托管连接器或基于服务提供程序的内置连接器在工作流中创建连接时，这些连接实际上是独立的 Azure 资源，具有自己的资源定义。

在你的逻辑应用的菜单中，从“工作流”下选择“连接”。

根据你要查看的连接类型选择以下选项之一：

选择该项，然后按 Delete 键。若要确认，请选择“确定”。

选择该项，以便为其打开信息窗格。在窗格的右上角，打开省略号 ( ... ) 菜单，然后选择“删除”。若要确认，请选择“确定”。

如果省略号菜单不可见，请充分扩展浏览器窗口，以便使信息窗格在右上角显示省略号( ... )按钮。

重启、停止或启动逻辑应用

你可以启动或停止单个逻辑应用，或者一次性启动或停止多个逻辑应用。还可以在不先停止的情况下重启单个逻辑应用。基于单租户的逻辑应用可以包含多个工作流，因此你可以停止整个逻辑应用或仅禁用工作流。

停止逻辑应用和禁用工作流操作具有不同的效果。有关详细信息，请参阅停止逻辑应用的注意事项和禁用工作流的注意事项。

停止逻辑应用的注意事项

停止逻辑应用会通过以下方式影响工作流实例：

Azure 逻辑应用会立即取消所有正在进行和挂起的运行。

Azure 逻辑应用不会创建或运行新的工作流实例。

下次满足触发器的条件时，触发器不会触发。但是，触发器状态会记住逻辑应用的停止点。因此，如果重启逻辑应用，触发器就会触发自上次运行以来的所有未处理项。

若要阻止每个工作流触发自上次运行以来的未处理项，请在重启逻辑应用之前按照以下步骤清除触发状态：

在 Azure 门户中打开逻辑应用。

在逻辑应用菜单的“工作流”下，选择“工作流”。

打开工作流，然后编辑该工作流触发器的任何部分。

保存所做更改。此步骤会重置触发器的当前状态。

对每个工作流重复此操作。

完成后，重启逻辑应用。

若要在不停止的情况下重启逻辑应用，请在“概述”窗格工具栏上选择“重启”。

若要停止正在运行的逻辑应用，请在“概述”窗格工具栏上选择“停止”。确认选择。

若要启动已停止的逻辑应用，请在“概述”窗格工具栏上选择“启动”。

如果逻辑应用已停止，则只会看到“启动”选项。如果逻辑应用已经在运行，则只会看到“停止”选项。你可以随时重启逻辑应用。

若要确认操作是成功还是失败，请在 Azure 主工具栏上打开“通知”列表（钟形图标）。

停止或启动多个逻辑应用

可以同时停止或启动多个逻辑应用，但不能在不先停止多个逻辑应用的情况下重启这些逻辑应用。

在 Azure 门户的主搜索框中，输入“ 逻辑应用 ”，然后选择“ 逻辑应用 ”。

在“逻辑应用”页上，查看逻辑应用的“状态”列。

在复选框列中，选择要停止或启动的逻辑应用。

若要停止所选的正在运行的逻辑应用，请在“概述”窗格工具栏上选择“禁用/停止”。确认选择。

若要启动所选的已停止的逻辑应用，请在“概述”窗格工具栏上选择“启用/启动”。

若要确认操作是成功还是失败，请在 Azure 主工具栏上打开“通知”列表（钟形图标）。

禁用或启用工作流

若要在下一次满足触发条件时阻止触发器触发，请禁用工作流。你可以禁用或启用单个工作流，但不能同时禁用或启用多个工作流。禁用工作流会通过以下方式影响工作流实例：

Azure 逻辑应用会继续所有正在进行和挂起的运行，直到完成为止。根据卷或积压工作 (backlog)，此过程可能需要一些时间才能完成。

Azure 逻辑应用不会创建或运行新的工作流实例。

下一次满足触发器的条件时，触发器不会触发。但是，触发器状态会记住工作流的禁用点。因此，如果重新启用工作流，此触发器将会触发自上次运行以来的所有未处理项。

若要阻止触发器触发自上次运行以来未处理的项，请在重新激活工作流之前清除触发器的状态：

在工作流中，编辑工作流触发器的任何部分。

保存所做更改。此步骤会重置触发器的当前状态。

重新激活工作流。

在禁用了工作流时，仍可以重新提交运行。

禁用工作流和停止逻辑应用操作具有不同的效果。有关详细信息，请参阅停止逻辑应用的注意事项。

禁用工作流

在逻辑应用菜单的“工作流”下，选择“工作流”。在复选框列中，选择要禁用的工作流。

在“工作流”窗格工具栏上，选择“禁用” 。

若要确认操作是成功还是失败，请在 Azure 主工具栏上打开“通知”列表（钟形图标）。

启用工作流

在逻辑应用菜单的“工作流”下，选择“工作流”。在复选框列中，选择要启用的工作流。

在“工作流”窗格工具栏上，选择“启用” 。

若要确认操作是成功还是失败，请在 Azure 主工具栏上打开“通知”列表（钟形图标）。

删除逻辑应用或工作流

你可以删除单个逻辑应用或同时删除多个逻辑应用。基于单租户的逻辑应用可以包含多个工作流，因此你可以删除整个逻辑应用或仅删除工作流。

删除逻辑应用

删除逻辑应用会立即取消正在进行和挂起的运行，但不会在应用使用的存储上运行清理任务。

在 Azure 门户的主搜索框中，输入“ 逻辑应用 ”，然后选择“ 逻辑应用 ”。

从“逻辑应用”列表的复选框列中，选择要删除的单个或多个逻辑应用。在工具栏中选择“删除”。

确认框出现时，输入“ 是 ”，然后选择“ 删除 ”。

若要确认操作是成功还是失败，请在 Azure 主工具栏上打开“通知”列表（钟形图标）。

删除工作流

删除工作流会通过以下方式影响工作流实例：

Azure 逻辑应用会立即取消正在进行和挂起的运行，但会在工作流使用的存储上运行清理任务。

Azure 逻辑应用不会创建或运行新的工作流实例。

如果删除工作流，然后重新创建相同的工作流，则重新创建的工作流不会具有与删除的工作流相同的元数据。若要刷新元数据，必须重新保存调用已删除工作流的所有工作流。这样，调用方就可获取重新创建的工作流的正确信息。否则，对重新创建的工作流的调用会失败，出现 Unauthorized 错误。此行为也适用于在集成帐户中使用项目的工作流和调用 Azure 函数的工作流。

在 Azure 门户中打开逻辑应用。

在逻辑应用菜单的“工作流”下，选择“工作流”。在复选框列中，选择要删除的一个或多个工作流。

在工具栏中选择“删除”。

若要确认操作是成功还是失败，请在 Azure 主工具栏上打开“通知”列表（钟形图标）。

恢复已删除的逻辑应用

如果使用源代码管理，可以无缝将删除的标准逻辑应用资源重新部署到单租户 Azure 逻辑应用中。但是，如果不使用源代码管理，请尝试以下步骤来恢复已删除的逻辑应用。

在尝试恢复已删除的逻辑应用之前，请查看以下注意事项：

只能恢复使用 工作流标准 托管计划的已删除标准逻辑应用资源。无法恢复删除的消耗逻辑应用资源。

如果工作流以“请求”触发器开始，则已恢复的逻辑应用的回叫 URL 与已删除的逻辑应用的 URL 不同。

在已恢复的逻辑应用中，已删除的逻辑应用的运行历史记录不可用。>

在“访问密钥”页上，复制帐户的主连接字符串，并保存供以后使用，例如：

DefaultEndpointsProtocol=https;AccountName=< storage-account-name >;AccountKey=< access-key >;EndpointSuffix=core.windows.net

在存储帐户菜单的“数据存储”下，选择“文件共享”，复制与逻辑应用关联的文件共享的名称，并保存供以后使用。

使用相同的托管计划和定价层新建标准逻辑应用资源。可以使用新名称，也可以重复使用已删除的逻辑应用中的名称。

在继续操作之前，请停止逻辑应用。在逻辑应用菜单中，选择“概述”。在“概述”窗格工具栏上，选择“停止” 。

在逻辑应用菜单的“设置”下，选择“配置” 。

在“配置”页上，更新以下应用程序设置值，并记得在完成后保存更改。

对于以前创建的工作流，设计器选取器中缺少新的触发器和操作

单租户 Azure 逻辑应用支持将内置操作用于 Azure 函数操作、Liquid 操作和 XML 操作（例如 XML 验证和转换 XML）。但是，对于之前创建的逻辑应用，如果逻辑应用使用过时版本的扩展捆绑包 Microsoft.Azure.Functions.ExtensionBundle.Workflows ，这些操作可能不会出现在设计器中供你选择。

若要解决此问题，请按照以下步骤删除过时的版本，以便扩展捆绑包可以自动更新到最新版本。

此特定解决方案仅适用于使用 Azure 门户创建的标准逻辑应用资源，不适用于使用 Visual Studio Code 和 Azure 逻辑应用（标准版）扩展创建并部署的逻辑应用。请参阅 Visual Studio Code 中的设计器缺少受支持的触发器和操作。

在 Azure 门户中，停止你的逻辑应用。

在逻辑应用菜单中，选择“概述”。

在“概述”窗格的工具栏上，选择“停止”。

在逻辑应用菜单上的“开发工具”下，选择“高级工具”。

在“高级工具”窗格上，选择“转到”，这将为你的逻辑应用打开 Kudu 环境。

在 Kudu 工具栏上，打开“调试控制台”菜单，并选择“CMD”。

此时将打开一个控制台窗口，以便你可以使用命令提示符浏览到捆绑包文件夹。另外，你可以浏览控制台窗口上方显示的目录结构。

浏览到以下文件夹，其中包含现有捆绑包的带版本号的文件夹：

...\home\data\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows

删除现有捆绑包的版本文件夹。在控制台窗口中，可以运行以下命令，将 { bundle-version } 替换为现有版本：

rm -rf {bundle-version}

例如： rm -rf 1.1.3

如果收到 “权限被拒” 或 “文件正在使用” 之类的错误，请在浏览器中刷新页面，并重新尝试之前的步骤，直到该文件夹删除。

在 Azure 门户中，返回到你的逻辑应用的“概述”页，然后选择“重启”。

门户将自动获取并使用最新的捆绑包。

我们想要倾听你对此方案的体验反馈！

如果发现 bug 或问题，请在 GitHub 中创建问题。

如有问题、请求、意见和其他反馈，请使用此反馈表单。