使用 Visual Studio Code 在单租户 Azure 逻辑应用中创建标准逻辑应用工作流
适用于:Azure 逻辑应用(标准)
本操作指南介绍如何使用 Visual Studio Code 和 Azure 逻辑应用(标准)扩展创建在单租户 Azure 逻辑应用中运行的示例集成工作流。 在创建此工作流之前,需要创建一个提供以下功能的标准逻辑应用资源:
逻辑应用可以包含多个有状态和无状态工作流。
同一逻辑应用和租户中的工作流在与 Azure 逻辑应用运行时相同的进程中运行,因此它们共享相同的资源并提供更好的性能。
可以使用 Visual Studio Code 开发环境在本地创建、运行和测试工作流。
准备就绪后,你可以将逻辑应用部署到 Azure,其中,工作流可以在单租户 Azure 逻辑应用环境或应用服务环境 v3(仅限基于 Windows 的应用服务计划)中运行。 借助 Azure 逻辑应用容器化运行时,你还能在可以运行 Kubernetes 的任何位置(包括 Azure、Azure Kubernetes 服务、本地甚至其他云平台)部署和运行工作流。
注意
将逻辑应用部署到 Kubernetes 群集目前以公共预览版提供。
有关单租户 Azure 逻辑应用的详细信息,请查看 Azure 逻辑应用中的单租户与多租户。
虽然示例工作流是基于云的工作流,并且只有两个步骤,但可以从数百个操作创建工作流,这些操作可以跨云、本地和混合环境连接各种应用、数据、服务和系统。 示例工作流从内置的“请求”触发器开始,然后执行 Office 365 Outlook 操作。 触发器为工作流创建可调用终结点,并等待来自任何调用方的入站 HTTPS 请求。 当触发器收到请求并触发时,会向指定电子邮件地址发送电子邮件以及触发器中所选的输出来运行下一个操作。
提示
如果没有 Office 365 帐户,可以使用任何其他可从电子邮件帐户发送消息的可用操作,例如使用 Outlook.com。
若要改为使用 Azure 门户创建此示例工作流,请按照使用单租户 Azure 逻辑应用和 Azure 门户创建集成工作流中的步骤进行操作。 可使用这两个选项在相同类型的环境中开发、运行和部署逻辑应用工作流。 但是借助 Visual Studio Code,你可以在开发环境中本地开发、测试和运行工作流。
你将逐渐完成以下高级任务:
- 为你的逻辑应用和空白的有状态工作流创建项目。
- 添加触发器和操作。
- 在本地运行、测试、调试和查看运行历史记录。
- 查找用于访问防火墙的域名详细信息。
- 部署到 Azure,这包括选择启用 Application Insights。
- 在 Visual Studio Code 和 Azure 门户中管理已部署的逻辑应用。
- 启用无状态工作流的运行历史记录。
- 在部署后启用或打开 Application Insights。
先决条件
访问和连接
如果计划在本地生成标准逻辑应用项目,并只使用在 Azure 逻辑应用运行时上本机运行的内置连接器来运行工作流,则不需要以下要求。 但是,请确保具有以下连接和 Azure 帐户凭据,以便将项目从 Visual Studio Code 发布或部署到 Azure、使用在全局 Azure 中运行的托管连接器,或访问已在 Azure 中部署的标准逻辑应用资源和工作流:
能够访问 Internet,以便可以下载要求,从 Visual Studio Code 连接到你的 Azure 帐户,以及从 Visual Studio Code 发布到 Azure。
Azure 帐户和订阅。 如果没有订阅,可以注册 Azure 帐户。
若要创建与本文中相同的示例工作流,你需要一个使用 Microsoft 工作或学校帐户进行登录的 Office 365 Outlook 电子邮件帐户。
如果你选择不同的电子邮件连接器,比如Outlook.com,你仍然可以遵循这个示例,整体常规步骤是一样的。 但是,你的选项可能在某些方面有所不同。 例如,如果你使用 Outlook.com 连接器,请改用你的个人 Microsoft 帐户进行登录。
工具
下载并安装 Visual Studio Code,这是免费的。
下载并安装适用于 Visual Studio Code 的 Azure 帐户扩展,以便在 Visual Studio Code 中的所有 Azure 扩展之间享受 Azure 登录和订阅筛选的单一共同体验。 本操作指南包含使用此体验的步骤。
使用任一种方法为你的特定操作系统下载并安装以下 Visual Studio Code 依赖项:
- 自动安装所有依赖项。
- 单独下载并安装每个依赖项。
自动安装所有依赖项
从版本 2.81.5开始,Visual Studio Code 的 Azure 逻辑应用(标准)扩展包括一个依赖项安装程序,该程序会自动在一个新二进制文件夹中安装所有必需的依赖项,并使任何现有依赖项保持不变。
此扩展包括以下依赖项:
依赖项 说明 用于 Visual Studio Code 的 C# 启用 F5 功能以运行工作流。 适用于 Visual Studio Code 的 Azurite 提供本地数据存储和模拟器,可与 Visual Studio Code 搭配使用,这样就可以在本地开发环境中处理逻辑应用项目并运行工作流。 如果不希望 Azurite 自动启动,可以禁用此选项:
1. 在“文件”菜单中,选择“首选项”>“设置”。
2. 在“用户”选项卡上,选择“扩展”>“Azure 逻辑应用(标准)”。
3.找到名为“Azure 逻辑应用标准:自动启动 Azurite”的设置,并清除选中的复选框。.NET SDK 6.x.x 包括 .NET Runtime 6.x.x,这是 Azure 逻辑应用(标准)运行时的先决条件。 Azure Functions Core Tools - 4.x 版本 根据操作系统(Windows、 macOS 或 Linux)安装版本。
这些工具包括为Azure 逻辑应用(标准版)扩展在 Visual Studio Code 中使用的 Azure Functions 运行时提供支持的同一运行时的版本。Node.js 版本 16.x.x(除非已安装较新版本) 启用运行 JavaScript 的内联代码操作动作所必需的。 安装程序不执行以下任务:
- 检查所需的依赖项是否已存在。
- 仅安装缺少的依赖项。
- 更新旧版本的现有依赖项。
从版本 2.81.5 开始,下载并安装适用于 Visual Studio Code 的 Azure 逻辑应用(标准)扩展。
在 Visual Studio Code 中的活动栏中,选择“扩展”。 (键盘操作:按 Ctrl+Shift+X)
在“扩展”窗格中,打开省略号(...)菜单,然后选择“从 VSIX 安装”。
查找并选择下载的 VSIX 文件。
安装完成后,扩展会自动激活并运行“Validate and install dependency binaries”命令。 若要查看进程日志,请打开“输出”窗口。
出现以下提示时,选择“是(推荐)” 以确认要自动安装所需的依赖项:
如有必要,请重新加载 Visual Studio Code。
确认依赖项正确显示在以下文件夹中:
C:\Users\<用户名>\.azurelogicapps\dependencies\<dependency-name>
在 Visual Studio Code 中确认以下扩展设置:
在“文件”菜单中,选择“首选项”>“设置”。
在“用户”选项卡上,选择“扩展”>“Azure 逻辑应用(标准)”。
检查以下设置:
扩展设置 值 依赖项路径 C:\Users\<用户名>\.azurelogicapps\dependencies 依赖项超时 60 秒 Dotnet 二进制路径 C:\Users\<用户名>\.azurelogicapps\dependencies\DotNetSDK\dotnet.exe Func Core Tools 二进制路径 C:\Users\<用户名>\.azurelogicapps\dependencies\FuncCoreTools\func Node JS 二进制路径 C:\Users\<用户名>\.azurelogicapps\dependencies\NodeJs\node 自动启动 Azurite Enabled 自动启动设计时 Enabled
如果现有的逻辑应用项目在 .vscode/tasks.json 文件中存储了自定义任务,请确保在打开项目之前将 tasks.json 文件保存到 其他位置。
打开项目时,系统会提示更新 tasks.json 文件以使用所需的依赖项。 如果选择继续,扩展将覆盖 tasks.json 文件。
打开逻辑应用项目时,将显示以下通知:
通知 操作 始终在启动时启动后台设计时过程? 若要更快地打开工作流设计器,请选择“是(推荐)”。 将 Azurite 配置为在项目启动时自动启动? 若要让 Azurite 存储在项目打开时自动启动,请选择“启用自动启动”。 在 Visual Studio Code 顶部显示的命令窗口中,按 Enter 接受默认路径:
C\Users\<用户名>\.azurelogicapps\.azurite
预览版的已知问题
如果选择在没有任何版本的 .NET Core SDK 的计算机上自动安装所有依赖项,将显示以下消息:
“无法找到 .NET Core SDK:运行 dotnet 时出错 -- 信息:错误:命令失败:dotnet --信息‘dotnet’不能被识别为内部或外部命令、可操作程序或批处理文件。 ‘dotnet’不能被识别为内部或外部命令、可运行程序或批处理文件。 。 不会启用 .NET Core 调试。 确保已安装 .NET Core SDK 并位于路径上。”
之所以收到此消息,是因为 .NET Core 框架在扩展激活时仍在安装。 你可以放心选择禁用此消息。
如果在打开现有逻辑应用项目或为“func 主机启动”启动调试任务 (tasks.json) 时遇到问题,并显示此消息,请按照以下步骤解决问题:
将 dotnet 二进制路径添加到环境路径变量。
在 Windows 任务栏的搜索框中,输入“环境变量”,然后选择“编辑系统环境变量”。
在“系统属性”框的“高级”选项卡上,选择“环境变量”。
在“环境变量”框中,从“<用户名>的用户变量”列表中选择“路径”,然后选择“编辑”。
如果列表中未显示以下值,请选择“新建”以添加以下值:
C:\Users\<用户名>\.azurelogicapps\dependencies\DotNetSDK
完成后,请选择“确定”。
关闭所有 Visual Studio Code 窗口,然后重新打开项目。
如果在安装和验证二进制依赖项时遇到问题,例如:
- Linux 权限问题
- 出现以下错误:<文件或路径>不存在
- 验证卡在了<依赖项名称>。
按照以下步骤再次运行“Validate and install binary dependencies”命令:
在“视图”菜单中选择“命令面板”。
当命令窗口出现时,输入并运行“Validate and install binary dependencies”命令。
如果没有安装 .NET Core 7 或更高版本,并且打开了包含 Azure Functions 项目的 Azure 逻辑应用工作区,将收到以下消息:
加载项目 [项目名称].csproj 时出现问题。 有关详细信息,请参阅日志。
此缺少的组件不会影响 Azure Functions 项目,因此可以放心忽略此消息。
单独安装每个依赖项
依赖项 说明 .NET SDK 6.x.x 包括 .NET Runtime 6.x.x,这是 Azure 逻辑应用(标准)运行时的先决条件。 Azure Functions Core Tools - 4.x 版本 - Windows:使用 Microsoft Installer (MSI) 版本,即 func-cli-X.X.XXXX-x*.msi
。
- macOS
- Linux
这些工具包括为Azure 逻辑应用(标准版)扩展在 Visual Studio Code 中使用的 Azure Functions 运行时提供支持的同一运行时的版本。
如果你的安装版本早于这些版本,请先卸载该版本,或者确保 PATH 环境变量指向你下载并安装的版本。Node.js 版本 16.x.x(除非已安装较新版本) 启用运行 JavaScript 的内联代码操作动作所必需的。
注意:对于 Windows,请下载 MSI 版本。 如果你改用 ZIP 版本,则必须手动使 Node.js 可用:通过使用你的操作系统的 PATH 环境变量。如果已经安装了自动安装所有依赖项(预览版)的 Azure 逻辑应用(标准)扩展版本,请跳过此步骤。 否则,请下载并安装适用于 Visual Studio Code 的 Azure 逻辑应用(标准)扩展。
在 Visual Studio Code 中的左侧工具栏中,选择“扩展”。
在“扩展”搜索框中,输入 azure logic apps standard。 在结果列表中,选择“Azure 逻辑应用(标准版)”>“安装”。
安装完成后,该扩展将显示在“扩展: 已安装”列表中。
提示
如果该扩展未显示在“已安装”列表中,请尝试重启 Visual Studio Code。
目前,可以同时安装消耗版(多租户)和标准版(单租户)扩展。 开发体验在某些方面彼此不同,但你的 Azure 订阅可以同时包含标准版和消耗版逻辑应用类型。 在 Visual Studio Code 中,Azure 窗口中显示 Azure 订阅中 Azure 部署和托管的所有逻辑应用,但按以下方式组织应用:
逻辑应用(消耗版)部分:订阅中的所有消耗逻辑应用。
资源部分:订阅中的所有标准逻辑应用。 以前,这些逻辑应用出现在逻辑应用(标准版)部分中,该部分现已移动到资源部分中。
若要在 Visual Studio Code 本地运行基于 Webhook 的触发器和操作(例如内置的 HTTP Webhook 触发器),则你需要为回调 URL 设置转发。
如果你通过支持使用 Application Insights 的设置来创建逻辑应用资源,则可以选择为你的逻辑应用资源启用诊断日志记录和跟踪。 你可以在创建逻辑应用时或在部署后执行此操作。 你需要有一个 Application Insights 实例,但你可以在创建逻辑应用时提前创建此资源,或在部署后创建此资源。
设置 Visual Studio Code
若要确保正确安装所有扩展,请重新加载或重启 Visual Studio Code。
确认 Visual Studio Code 会自动查找并安装扩展更新,以便所有扩展可以获得最新的更新。 否则,你必须手动卸载过时的版本并安装最新版本。
在“文件”菜单上,转到“首选项”>“设置”。
在“用户”菜单上,转到“功能”>“扩展”。
确认已选择“自动检查更新”,并将“自动更新”设置为“所有扩展”。
确认 Azure 逻辑应用(标准版本)扩展的 Azure 逻辑应用标准版:项目运行时设置已设置为版本 ~4:
注意
使用“内联代码操作”操作时需要此版本。
在“文件”菜单上,转到“首选项”>“设置”。
在“用户”菜单上,转到“功能”>“扩展”>“Azure 逻辑应用(标准版)”。
例如,可以在此处查找“Azure 逻辑应用标准版: 项目运行时”设置,或者使用搜索框查找其他设置:
连接到 Azure 帐户
在 Visual Studio Code 活动栏上,选择 Azure 图标。
在 Azure 窗口的资源下,选择登录到 Azure。 出现“Visual Studio Code 身份验证”页面时,请使用 Azure 帐户登录。
登录后,Azure 窗口将显示与你的 Azure 帐户相关联的 Azure 订阅。 如果预期的订阅未显示,或者你希望该窗格仅显示特定订阅,请执行以下步骤:
在订阅列表中,将指针移动到第一个订阅旁边,直到“选择订阅”按钮(筛选器图标)出现。 选择“筛选”图标。
或者,在 Visual Studio Code 状态栏中,选择你的 Azure 帐户。
当另一个订阅列表出现时,选择所需的订阅,然后确保选择“确定”。
创建本地项目
创建逻辑应用之前,请先创建一个本地项目,以便可以从 Visual Studio Code 管理、运行和部署逻辑应用。 基础项目类似于 Azure Functions 项目(也称为函数应用项目)。 但是,这些项目类型彼此独立,因此,逻辑应用和函数应用不能存在于同一项目中。
在计算机上,创建一个空的本地文件夹以用于稍后将在 Visual Studio Code 中创建的项目。
在 Visual Studio Code 中,关闭所有打开的文件夹。
在 Azure 窗口中,从“工作区”部分工具栏上的“Azure 逻辑应用”菜单中选择“创建新项目”。
如果 Windows Defender 防火墙提示你为
Code.exe
(这是 Visual Studio Code)和func.exe
(这是 Azure Functions Core Tools)授予网络访问权限,请选择“专用网络(如我的家庭或工作网络)”>“允许访问”。浏览到你创建项目文件夹的位置,选择该文件夹,然后继续。
从显示的模板列表中,选择“有状态工作流”或“无状态工作流”。 在此示例中,请选择“有状态工作流”。
为你的工作流提供一个名称,然后按 Enter。 此示例使用 Stateful-Workflow 作为名称。
注意
可能会收到名为 azureLogicAppsStandard.createNewProject 的错误消息,其中包含错误消息:“无法写入工作区设置,因为 azureFunctions.suppressProject 不是已注册的配置”。 如果出现这种情况,请尝试直接从 Visual Studio Marketplace 或从 Visual Studio Code 内部安装适用于 Visual Studio Code 的 Azure Functions 扩展。
如果 Visual Studio Code 提示你在当前的 Visual Studio Code 或新的 Visual Studio Code 窗口中打开项目,请选择在当前窗口中打开。 否则,请选择在新窗口中打开。
Visual Studio Code 将完成项目的创建。
在 Visual Studio 活动栏中,打开“资源管理器”窗格(如果尚未打开)。
“资源管理器”窗格将显示你的项目,该项目现在包括自动生成的项目文件。 例如,该项目有一个显示了你的工作流名称的文件夹。 在该文件夹中,workflow.json 文件包含你的工作流的基础 JSON 定义。
在 Visual Studio Code 中,逻辑应用项目具有以下类型之一:
- 基于扩展捆绑包 (Node.js)(默认类型)
- 基于 NuGet 包 (.NET)(可从默认类型转换)
根据这些类型,项目包含略有不同的文件夹和文件。 基于 NuGet 的项目包含一个 .bin 文件夹,其中包含包和其他库文件。 基于捆绑包的项目不包括 .bin 文件夹和其他文件。 某些场景需要基于 NuGet 的项目以运行应用,例如,在想要开发和运行自定义内置操作时。 有关将项目转换为使用 NuGet 的详细信息,请参阅启用内置连接器创作。
默认的基于捆绑包的项目具有类型于以下示例的文件夹和文件结构:
MyBundleBasedLogicAppProjectName | .vscode | Artifacts || Maps ||| MapName1 ||| ... || Schemas ||| SchemaName1 ||| ... | WorkflowName1 || workflow.json || ... | WorkflowName2 || workflow.json || ... | workflow-designtime | .funcignore | connections.json | host.json | local.settings.json
你可以在项目的根级别找到包含其他项的以下文件和文件夹:
名称 文件夹或文件 说明 .vscode 文件夹 包含与 Visual Studio Code 相关的设置文件,如 extensions.json、launch.json、settings.json 和 tasks.json 文件。 项目 文件夹 包含在支持企业对企业 (B2B) 场景的工作流中定义和使用的集成帐户项目。 例如,示例结构包含用于 XML 转换和验证操作的映射和架构。 <WorkflowName> 文件夹 对于每个工作流,<WorkflowName> 文件夹包含 workflow.json 文件,其中包含该工作流的基础 JSON 定义。 workflow-designtime 文件夹 包含与开发环境相关的设置文件。 .funcignore 文件 包含与已安装的 Azure Functions Core Tools 相关的信息。 connections.json 文件 包含工作流使用的用于任何托管连接和 Azure 函数的元数据、终结点和密钥。
重要说明:若要在各种环境中使用不同的连接和函数,请确保实现此 connections.json 文件的参数化并更新终结点。host.json 文件 包含特定于运行时的配置设置和值,例如,单租户 Azure 逻辑应用平台、逻辑应用、工作流、触发器和操作的默认限制。 在逻辑应用项目的根级别,host.json 元数据文件包含配置设置和默认值,相同逻辑应用中的所有工作流会在运行时(无论是在本地还是在 Azure 中)使用这些配置设置和默认值。
注意:创建逻辑应用时,Visual Studio Code 会在存储容器中创建一个备份 host.snapshot.*.json 文件 。 如果你删除逻辑应用,此备份文件不会被删除。 如果你创建另一个同名的逻辑应用,系统会创建另一个快照文件。 对于同一逻辑应用,最多只能有 10 个快照。 如果超出限制,你将收到以下错误:Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))
若要解决此错误,请从存储容器中删除额外的快照文件。local.settings.json 文件 包含工作流在本地运行时使用的应用设置、连接字符串和其他设置。 换句话说,这些设置和值仅在本地开发环境中运行项目时适用。 在部署到 Azure 期间,文件和设置将被忽略,并且不包含在部署中。
此文件会将设置和值存储为本地环境变量,本地开发工具会将其用作appSettings
值。 可以通过使用“应用设置”和“参数”在运行时和部署时调用和引用这些环境变量 。
重要说明:local.settings.json 包含机密,因此请确保从项目源代码理管理中排除此文件。注意
默认情况下,local.settings.json文件中,标准逻辑应用的语言辅助角色运行时值为
dotnet
。 在此之前,node
是默认值。 但是,dotnet
现在是所有新的和现有的已部署标准逻辑应用的默认值,即使对于具有不同值的应用也是如此。 此更改不会影响工作流的运行时,并且一切都应和以前一样。 有关详细信息,请参阅 FUNCTIONS_WORKER_RUNTIME 应用设置。标准逻辑应用的 APP_KIND 应用设置已设置为 workflowApp,但在某些情况下(例如使用 Azure 资源管理器模板进行自动化,和其他未包含该设置的情况)会缺少此应用设置。 如果某些操作不起作用(如执行 JavaScript 代码操作或工作流停止工作),请检查 APP_KIND 应用设置是否存在且设置为 workflowApp。 有关详细信息,请参阅 APP_KIND 应用设置。
将项目转换为基于 NuGet 包 (.NET)
默认情况下,Visual Studio Code 创建一个逻辑应用项目,该项目是基于扩展捆绑包 (Node.js),而不是基于 NuGet 包 (.NET)。 例如,如果需要基于 NuGet 包 (.NET) 的逻辑应用项目,若要启用内置连接器创作,则必须将项目从基于扩展捆绑包 (Node.js) 转换为基于 NuGet 包 (.NET)。
重要
此操作是不可撤消的单向操作。
在“资源管理器”窗格中的你的项目根目录下,将鼠标指针移动到所有其他文件和文件夹下方的任何空白区域,打开快捷菜单,然后选择转换为基于 NuGet 的逻辑应用项目。
当出现提示时,确认项目转换。
启用内置的连接器创作
可以使用单租户 Azure 逻辑应用扩展性框架为所需的所有服务创建自己的内置连接器。 与 Azure 服务总线和 SQL Server 等内置连接器相似,这些连接器可提供更高的吞吐量、低延迟和本地连接,并在与单租户 Azure 逻辑应用运行时相同的进程中本机运行。
目前仅可在 Visual Studio Code 中使用创作功能,该功能默认情况下不启用。 若要创建这些连接器,请执行以下步骤:
查看并遵循随处运行的 Azure 逻辑应用 - 内置的连接器扩展性一文中的步骤。
向项目添加自定义项目
在逻辑应用工作流中,某些连接器依赖于映射、架构或程序集等项目。 在 Visual Studio Code 中,可以将这些项目上传到逻辑应用项目,类似于在 Azure 门户中通过逻辑应用资源菜单在“项目”下上传这些项目,例如:
向项目添加映射
若要向项目添加映射,请在项目层次结构中展开 Artifacts>Maps,可以将映射放置在此文件夹。
向项目添加架构
若要向项目添加架构,请在项目层次结构中展开 Artifacts>Schemas,可以将架构放置在此文件夹。
向项目添加程序集
标准逻辑应用可以使用或引用特定类型的程序集,可以在 Visual Studio Code 中将这些程序集上传到项目中。 但是,必须将它们添加到项目中的特定文件夹。 下表提供了每个程序集类型的详细信息及其在项目中的确切放置位置。
程序集类型 | 说明 |
---|---|
客户端/SDK 程序集 (.NET Framework) | 此程序集类型提供有关存储和部署适用于 .NET Framework 的客户端和自定义 SDK 的信息。 例如,SAP 内置连接器使用这些程序集加载 SAP NCo 不可再发行 DLL 文件。 请确保将这些程序集添加到以下文件夹:\lib\builtinOperationSdks\net472 |
客户端/SDK 程序集 (Java) | 此程序集类型提供有关存储和部署适用于 Java 的自定义 SDK 的信息。 例如,JDBC 内置连接器使用这些 JAR 文件来查找自定义关系数据库 (RDB) 的 JDBC 驱动程序。 请确保将这些程序集添加到以下文件夹:\lib\builtinOperationSdks\JAR |
自定义程序集 (.NET Framework) | 此程序集类型提供有关存储和部署自定义 DLL 的信息。 例如,转换 XML 操作将这些程序集用于 XML 转换期间所需的自定义转换函数。 请确保将这些程序集添加到以下文件夹:\lib\custom\net472 |
下图显示了每个程序集类型在项目中的放置位置:
有关在 Microsoft Azure 门户中将程序集上传到逻辑应用资源的详细信息,请参阅添加引用的程序集。
迁移基于 NuGet 的项目以使用“lib\*”程序集
重要
只有基于 NuGet 的逻辑应用项目才需要此任务。
如果在程序集支持不适用于标准逻辑应用工作流时创建了逻辑应用项目,则可以将以下行添加到 <project-name>.csproj 文件中,以处理使用程序集的项目:
<ItemGroup>
<LibDirectory Include="$(MSBuildProjectDirectory)\lib\**\*"/>
</ItemGroup>
<Target Name="CopyDynamicLibraries" AfterTargets="_GenerateFunctionsExtensionsMetadataPostPublish">
<Copy SourceFiles="@(LibDirectory)" DestinationFiles="@(LibDirectory->'$(MSBuildProjectDirectory)\$(PublishUrl)\lib\%(RecursiveDir)%(Filename)%(Extension)')"/>
</Target>
在设计器中打开工作流定义文件
展开工作流的项目文件夹(本示例中名为 Stateful-Workflow),然后打开 workflow.json 文件。
打开 workflow.json 文件的快捷菜单,然后选择打开设计器。
在 Azure 中启用连接器列表打开后,选择使用 Azure 提供的连接器,这适用于所有托管连接器或“共享”连接器,这些连接器在 Azure 中托管和运行,而内置连接器、本机连接器或“应用内”连接器直接以 Azure 逻辑应用运行时运行。
注意
无状态工作流目前仅支持托管连接器中的操作,不支持触发器。 尽管你可以选择在 Azure 中为无状态工作流启用连接器,但设计器不会显示任何托管连接器触发器供你选择。
选择订阅列表打开后,选择要用于你的逻辑应用项目的 Azure 订阅。
资源组列表打开后,选择创建新资源组。
为资源组提供一个名称,然后按 Enter。 此示例使用 Fabrikam-Workflows-RG。
从位置列表中,选择在创建资源组和资源时要使用的 Azure 区域。 此示例使用“中国东部 2”。
执行此步骤后,Visual Studio Code 将打开工作流设计器。
注意
当 Visual Studio Code 启动工作流设计时 API 时,你可能会收到一条消息,指出启动可能需要几秒钟时间。 你可以忽略此消息,也可以选择“确定”。
如果设计器未打开,请查看故障排除部分中的设计器未能打开。
设计器出现后,设计器上会显示添加触发器提示。
在设计器上,选择添加触发器,这将打开添加触发器窗格和一个库,其中显示了具有要选择的触发器的所有连接器。
接下来,向工作流添加触发器和操作。
添加触发器和操作
在设计器中打开空白工作流后,设计器上会显示添加触发器提示。 现在,可以通过添加触发器和操作开始创建工作流了。
重要
若要在本地运行使用基于 Webhook 的触发器或操作(例如内置的 HTTP Webhook 触发器或操作)的工作流,则必须通过为 Webhook 的回调 URL 设置转发来启用此功能。
此示例中的工作流使用以下触发器和操作:
名为当收到 HTTP 请求时的请求内置连接器触发器,它将收到入站调用或请求,并创建其他服务或逻辑应用可以调用的终结点。
名为发送电子邮件的 Office 365 Outlook 托管连接器操作。 若要遵循本操作指南,需要 Office 365 Outlook 电子邮件帐户。 如果你有一个受其他连接器支持的电子邮件帐户,则可以使用该连接器,但该连接器的用户体验将与此示例中的步骤不同。
名为响应的请求内置连接器操作,用于发送答复并将数据返回给调用方。
添加“请求”触发器
在工作流设计器的添加触发器窗格中,打开运行时列表,然后选择应用内,以便仅查看可用的内置连接器触发器。
使用搜索框查找名为“当收到 HTTP 请求时”的“请求”触发器,然后将该触发器添加到你的工作流。 有关详细信息,请参阅使用触发器和操作构建工作流。
当触发器出现在设计器上时,触发器的信息窗格会打开,并显示触发器的参数、设置和其他相关任务。
提示
如果信息窗格未显示,请确保在设计器上选中该触发器。
保存工作流。 在设计器工具栏上选择“保存”。
如果需要从设计器中删除某个项,请遵循从设计器中删除项的这些步骤。
添加 Office 365 Outlook 操作
在设计器的“请求”触发器下,选择加号 (+) >“添加操作”。
在打开的添加操作窗格中,从运行时列表中选择共享,以便仅查看可用的托管连接器操作。
使用搜索框查找名为发送电子邮件 (V2) 的 Office 365 Outlook 托管连接器操作,然后将该操作添加到你的工作流。 有关详细信息,请参阅使用触发器和操作构建工作流。
在操作的身份验证窗格打开时,选择登录,以创建与你的电子邮件帐户的连接。
按照后续提示选择你的帐户,允许访问并允许返回到 Visual Studio Code。
注意
如果在完成提示之前过去了太多的时间,则身份验证过程将超时并失败。 在这种情况下,请返回到设计器,然后重试登录以创建连接。
出现 Microsoft 提示时,选择 Office 365 Outlook 的用户帐户,然后选择允许访问。
当 Azure 逻辑应用提示打开 Visual Studio Code 链接时,选择打开。
当 Visual Studio Code 提示打开 Azure Tools 时,选择“打开”。
提示
若要跳过此类将来提示,请在出现关联的提示时选择以下选项:
打开 Visual Studio Code 链接的权限:选择“始终允许 logic-apis-chinanorth3.consent.azure-apim.net 在关联的应用中打开此类型的链接”。 此域根据为逻辑应用资源选择的 Azure 区域而更改。
打开 Azure Tools 的权限:选择“不再请求此扩展”。
在 Visual Studio Code 创建连接后,一些连接器会显示消息“连接仅在 {n} 天内有效”。 此时间限制仅应用于在 Visual Studio Code 中创作逻辑应用工作流时的持续时间。 部署之后,此限制不再存在,因为工作流在运行时可以通过使用其自动启用的系统分配的托管标识进行身份验证。 该托管标识与你在创建连接时使用的身份验证凭据或连接字符串不同。 如果你禁用了该系统分配的托管标识,则连接在运行时不起作用。
在设计器中,如果“发送电子邮件”操作未显示为选中状态,请选择该操作。
在操作信息窗格的参数选项卡上,提供操作所需的信息,例如:
属性 需要 值 说明 To 是 <your-email-address> 电子邮件收件人,这可以是你自己的电子邮件地址(用于测试)。 此示例使用虚构的电子邮件 sophia.owen@fabrikam.com。 主题 是 来自示例工作流的电子邮件 电子邮件主题 正文 是 来自示例工作流的 Hello! 电子邮件正文内容 注意
如果在测试选项卡上做出任何更改,请确保选择保存,这样才能在切换选项卡或改为关注设计器之前提交这些更改。 否则,Visual Studio Code 不会保留你所做的更改。
保存工作流。 在设计器上,选择“保存”。
启用本地运行的 Webhook
在将基于 Webhook 的触发器或操作(例如 HTTP Webhook)用于运行在 Azure 中的逻辑应用工作流时,Azure 逻辑应用运行时将通过生成回调 URL 并将其注册到服务终结点来订阅该终结点。 然后,触发器或操作将等待服务终结点调用此 URL。 但是,在 Visual Studio Code 中工作时,生成的回调 URL 以 http://localhost:7071/...
开头。 此 URL 用于你的 localhost 服务器,该服务器是专用的,因此服务终结点无法调用此 URL。
若要在 Visual Studio Code 中本地运行基于 Webhook 的触发器和操作,你需要设置一个公共 URL,该 URL 将公开 localhost 服务器,并将来自服务终结点的调用安全地转发到 Webhook 回调 URL。 你可以使用转发服务和工具(例如 ngrok),它将打开到 localhost 端口的 HTTP 隧道,也可以使用你自己的工具。
使用 ngrok 设置调用转发
转到 ngrok 网站。 注册新帐户或登录到帐户(如果有的话)。
获取你的个人身份验证令牌,你的 ngrok 客户端需要使用该令牌连接到你的帐户并向其进行身份验证。
若要查找你的身份验证令牌页,请在帐户仪表板菜单上展开“身份验证”,然后选择“你的身份验证令牌”。
从“你的身份验证令牌”框中,将令牌复制到一个安全位置。
从 ngrok 下载页或你的帐户仪表板,下载 ngrok 所需的版本,然后提取 .zip 文件。 有关详细信息,请参阅步骤 1:解压缩以进行安装。
在计算机上,打开你的命令提示符工具。 浏览到 ngrok.exe 文件所在的位置。
通过运行以下命令将 ngrok 客户端连接到你的 ngrok 帐户。 有关详细信息,请参阅步骤 2:连接你的帐户。
ngrok authtoken <your_auth_token>
通过运行以下命令,打开到 localhost 端口 7071 的 HTTP 隧道。 有关详细信息,请参阅步骤 3:将其激发。
ngrok http 7071
从输出中,找到以下行:
http://<domain>.ngrok.io -> http://localhost:7071
复制并保存具有以下格式的 URL:
http://<domain>.ngrok.io
在应用设置中设置转发 URL
在 Visual Studio Code 中的设计器上,添加要使用的基于 Webhook 的触发器或操作。
此示例将继续执行 HTTP + Webhook 触发器。
当显示了主机终结点位置提示时,输入之前创建的转发(重定向)URL。
注意
如果忽略此提示,则会出现警告,指出必须提供转发 URL,因此请选择“配置”,然后输入 URL。 完成此步骤后,对于可能添加的后续 Webhook 触发器或操作,将不会显示该提示。
要显示该提示,请在项目根级别打开 local.settings.json 文件的快捷菜单,然后选择“配置 Webhook 重定向终结点”。 现在,提示将会再次显示,以便你可以提供转发 URL。
Visual Studio Code 将转发 URL 添加到项目根文件夹中的 local.settings.json 文件。 在
Values
对象中,现在会出现名为Workflows.WebhookRedirectHostUri
的属性并且它设置为转发 URL,例如:{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "dotnet", "FUNCTIONS_V2_COMPATIBILITY_MODE": "true", <...> "Workflows.WebhookRedirectHostUri": "http://xxxXXXXxxxXXX.ngrok.io", <...> } }
注意
以前,FUNCTIONS_WORKER_RUNTIME 设置的默认值为
node
。 现在,dotnet
是所有新的和现有的已部署标准逻辑应用的默认值,甚至对于具有不同值的应用也是如此。 此更改不应影响工作流的运行时,并且一切都应按与以前相同的方式工作。 有关详细信息,请参阅 FUNCTIONS_WORKER_RUNTIME 应用设置。
首次启动本地调试会话或在不调试的情况下运行工作流时,Azure 逻辑应用运行时会将工作流注册到服务终结点,并订阅该终结点以用于通知 Webhook 操作。 工作流下次运行时,运行时将不会注册或重新订阅,因为本地存储中已存在订阅注册。
如果工作流运行使用本地运行的基于 Webhook 的触发器或操作,则为该工作流运行停止调试会话时,不会删除现有的订阅注册。 若要注销,必须手动移除或删除订阅注册。
注意
在工作流开始运行后,终端窗口可能会显示类似于以下示例的错误:
message='Http request failed with unhandled exception of type 'InvalidOperationException' and message: 'System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'
在这种情况下,请打开项目根文件夹中的 local.settings.json 文件,并确保该属性设置为 true
:
"FUNCTIONS_V2_COMPATIBILITY_MODE": "true"
管理用于调试的断点
在通过启动调试会话来运行和测试逻辑应用工作流之前,你可以在每个工作流的 workflow.json 文件中设置断点。 无需进行其他设置。
目前,断点仅可用于操作,不可用于触发器。 每个操作定义都包含以下断点位置:
请在显示了操作名称的行上设置开始断点。 当在调试会话过程中命中此断点时,你可以在操作的输入被评估前查看操作的输入。
请在显示了操作的右大括号 ( } ) 的行上设置结束断点。 当在调试会话过程中命中此断点时,你可以在操作完成运行之前查看操作的结果。
若要添加断点,请执行以下步骤:
打开要调试的工作流的 workflow.json 文件。
在要设置断点的行上,在左栏中选择该栏。 若要删除断点,请选择该断点。
启动调试会话时,“运行”视图将显示在代码窗口的左侧,而“调试”工具栏将显示在顶部附近。
注意
如果“运行”视图未自动显示,请按 Ctrl+Shift+D。
若要查看命中断点时可用的信息,请在“运行”视图中观察“变量”窗格。
若要继续执行工作流,请在“调试”工具栏上选择“继续”(“播放”按钮)。
可以在工作流运行期间随时添加和删除断点。 但是,如果在运行开始后更新 workflow.json 文件,则断点不会自动更新。 若要更新断点,请重启逻辑应用。
有关一般信息,请参阅断点 - Visual Studio Code。
在本地运行、测试和调试
若要测试逻辑应用工作流,请按照以下步骤启动调试会话,并查找由“请求”触发器创建的终结点的 URL。 稍后向该终结点发送请求时,你需要使用此 URL。
若要更轻松地调试无状态工作流,你可以启用该工作流的运行历史记录。
如果 Azurite 模拟器已在运行,请继续执行下一步。 否则,请确保在运行工作流之前启动模拟器:
在 Visual Studio Code 中,从视图菜单中选择命令面板。
命令面板出现后,输入 Azurite: Start。
有关 Azurite 命令的详细信息,请参阅 Visual Studio Code 中 Azurite 扩展的文档。
在 Visual Studio Code 活动栏上,打开“运行”菜单,然后选择“启动调试”(F5)。
此时将打开“终端”窗口,以便你可以查看调试会话。
注意
如果收到错误运行 preLaunchTask“generateDebugSymbols”后存在错误,请参阅故障排除部分中的调试会话未能启动。
现在,在“请求”触发器上查找终结点的回叫 URL。
重新打开“资源管理器”窗格,以便可以查看你的项目。
从 workflow.json 文件的快捷菜单上,选择“概述”。
查找“回叫 URL”值,它类似于示例“请求”触发器的此 URL:
http://localhost:7071/api/<workflow-name>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>
复制并保存回叫 URL 属性值。
若要测试回叫 URL 并触发工作流,请使用 HTTP 请求工具及其说明将 HTTP 请求发送到 URL,包括“请求”触发器所需的方法。
此示例使用 GET 方法与复制的 URL 配合使用,如以下示例所示:
GET http://localhost:7071/api/Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>
当触发了触发器时,示例工作流将运行,并发送类似于以下示例的电子邮件:
在 Visual Studio Code 中,返回到你的工作流的概述页。
如果你创建了有状态工作流,则在发送的请求触发工作流后,概述页将显示工作流的运行状态和历史记录。
提示
如果未显示运行状态,请尝试通过选择“刷新”来刷新概述页。 如果由于不符合条件或找不到数据而跳过了触发器,则不会发生运行。
下表显示了每个工作流运行可能具有并在 Visual Studio Code 中显示的最终状态:
运行状态 说明 Aborted 由于外部问题(例如,系统中断或 Azure 订阅过期),运行已停止或未完成。 已取消 运行已触发并已启动,但收到了取消请求。 已失败 运行中的至少一个操作失败。 工作流中未设置后续操作来处理失败。 正在运行 运行已被触发并正在进行,但如果运行由于操作限制或当前定价计划而被限制,也可能会显示此状态。 提示:如果你设置了诊断日志记录,则可以获取发生的任何限制事件的相关信息。
成功 运行已成功。 如果有任何操作失败,工作流中的后续操作已处理了该失败。 已超时 运行超时,因为当前持续时间超出了运行持续时间限制,该限制由“运行历史记录保留期(天)” 设置控制。 运行持续时间是使用运行开始时间和在该开始时间有效的运行持续时间限制来计算的。 注意:如果运行的持续时间还超出了当前的运行历史记录保留期限制(该限制也由“运行历史记录保留期(天)”设置控制),则每日清理作业会将该运行从运行历史记录中清除。 无论运行是超时还是完成,始终都将使用运行的开始时间和当前保留期限制来计算保留期。 因此,如果你减小进行中的某个运行的持续时间限制,则该运行将超时。但是,运行将保留或从运行历史记录中清除,具体取决于运行持续时间是否超出了保留期限制。
正在等待 运行尚未启动或已暂停,例如,由于前一个工作流实例仍在运行。 若要查看特定运行中每个步骤的状态以及步骤的输入和输出,请选择该运行对应的省略号 (...) 按钮,然后选择显示运行。
Visual Studio Code 将打开监视视图并显示运行中每个步骤的状态。
注意
如果某个运行失败,并且监视视图中的某个步骤显示“400 请求无效”错误,则此问题可能是由触发器名称或操作名称较长导致的,因为这会造成基础的统一资源标识符 (URI) 超出默认字符数限制。 有关详细信息,请参阅 400 错误请求。
下表显示了每个工作流操作可能具有并在 Visual Studio Code 中显示的可能状态:
操作状态 说明 Aborted 由于外部问题(例如,系统中断或 Azure 订阅过期),操作已停止或未完成。 已取消 操作正在运行,但收到了取消请求。 已失败 操作已失败。 正在运行 操作当前正在运行。 已跳过 此操作已被跳过,因为与其紧邻的前一个操作失败。 操作有一个 runAfter
条件,该条件要求前一个操作成功完成,然后才能运行当前操作。成功 操作已成功。 重试成功 操作已在一次或多次重试后成功。 若要查看重试历史记录,请在运行历史记录详细信息视图中选择该操作,以便可以查看输入和输出。 已超时 操作由于超出了操作设置指定的超时限制而停止。 正在等待 适用于正在等待来自调用方的入站请求的 Webhook 操作。 若要查看每个步骤的输入和输出,请选择要检查的步骤。 若要进一步查看该步骤的原始输入和输出,请选择“显示原始输入”或“显示原始输出”。
若要停止调试会话,请在“运行”菜单上,选择“停止调试” (Shift + F5)。
返回响应
如果工作流从“请求”触发器开始,则可以使用名为“响应”的请求内置操作将响应返回给向工作流发送请求的调用方。
在工作流设计器的发送电子邮件操作下,选择加号 (+) >添加操作。
此时会打开添加操作窗格,供你选择下一个操作。
在添加操作窗格的运行时列表中,选择应用内。 查找并添加响应操作。
当响应操作显示在设计器上后,操作的详细信息窗格将自动打开。
在“参数”选项卡上,提供要调用的函数所需的信息。
此示例返回发送电子邮件操作的输出,即正文参数值。
对于正文参数,请在编辑框内选择,然后选择闪电图标,将打开动态内容列表。 此列表显示工作流中先前触发器和操作的可用输出值。
在动态内容列表中的“发送电子邮件”下,选择“正文”。
完成后,“响应”操作的“正文”属性现在设置为“发送电子邮件”操作的“正文”输出值。
在设计器上,选择“保存”。
重新测试逻辑应用
对逻辑应用进行更新后,可以通过在 Visual Studio 中重新运行调试器并发送另一个请求来触发已更新的逻辑应用以运行另一个测试(类似于在本地运行、测试和调试中的步骤)。
在 Visual Studio Code 活动栏上,打开“运行”菜单,然后选择“启动调试”(F5)。
在 Postman 或你用于创建和发送请求的工具中,发送另一个请求来触发你的工作流。
如果你创建了有状态工作流,请在工作流的概述页上检查最新运行的状态。 若要查看该运行中每个步骤的状态、输入和输出,请选择该运行对应的省略号 (...) 按钮,然后选择显示运行。
例如,下面是在使用“响应”操作更新示例工作流后执行的某个运行的分步状态。
若要停止调试会话,请在“运行”菜单上,选择“停止调试” (Shift + F5)。
查找用于防火墙访问的域名
在 Azure 门户中部署并运行你的逻辑应用工作流之前,如果你的环境具有限制流量的严格网络要求或防火墙,则必须为工作流中存在的任何触发器或操作连接设置权限。
若要查找这些连接的完全限定的域名 (FQDN),请执行以下步骤:
在你的逻辑应用项目中,打开 connections.json 文件(该文件是在你将第一个基于连接的触发器或操作添加到工作流后创建的)并查找
managedApiConnections
对象。针对创建的每个连接,复制
connectionRuntimeUrl
属性值并将其保存到一个安全的位置,以便可以使用此信息设置防火墙。此示例 connections.json 文件包含两个连接(一个 AS2 连接和一个 Office 365 连接),这些连接具有以下
connectionRuntimeUrl
值:AS2:
"connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba
Office 365:
"connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f
{ "managedApiConnections": { "as2": { "api": { "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/as2" }, "connection": { "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}" }, "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba, "authentication": { "type":"ManagedServiceIdentity" } }, "office365": { "api": { "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/office365" }, "connection": { "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}" }, "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f, "authentication": { "type":"ManagedServiceIdentity" } } } }
部署到 Azure
在 Visual Studio Code 中,可以直接将项目发布到 Azure 来部署标准逻辑应用资源。 你可以将逻辑应用作为新资源发布,这将自动创建任何必要的资源,例如 Azure 存储帐户,这类似于函数应用要求。 另外,可以将逻辑应用发布到以前部署的标准逻辑应用资源,这会覆盖该逻辑应用。
部署标准逻辑应用资源需要使用在部署过程中选择的托管计划和定价层。 有关详细信息,请查看托管计划和定价层。
发布到新的标准逻辑应用资源
在 Visual Studio Code 活动栏上选择 Azure 图标,打开 Azure 窗口。
在 Azure 窗口中,从“工作区”部分工具栏上的“Azure 逻辑应用”菜单中选择“部署到逻辑应用”。
在出现提示时,选择要用于逻辑应用部署的 Azure 订阅。
从 Visual Studio Code 打开的列表中,从以下选项中进行选择:
- 在 Azure 中创建新的逻辑应用(标准版) (快速)
- 在 Azure 中创建新的逻辑应用(标准版)(高级)
- 以前部署的逻辑应用(标准版)资源(如果存在)
此示例将继续在 Azure 中创建新的逻辑应用(标准版)(高级)。
要创建新的标准逻辑应用资源,请执行以下步骤:
为新的逻辑应用提供一个全局唯一的名称,这是将用于逻辑应用(标准版)资源的名称。 此示例使用 Fabrikam-Workflows-APP。
为新的逻辑应用选择一个托管计划。 请为你的计划创建名称,或者选择现有计划(仅限基于 Windows 的应用程序服务计划)。 此示例选择“创建新的应用服务计划”。
为托管计划提供一个名称,然后为所选计划选择一个定价层。
有关详细信息,请查看托管计划和定价层。
为了获得最佳性能,请为部署选择与你的项目相同的资源组。
注意
尽管可以创建或使用其他资源组,但这样做可能会影响性能。 如果你创建或选择其他资源组,但在出现确认提示后取消,则还会取消你的部署。
对于有状态工作流,请选择“创建新的存储帐户”或选择一个现有存储帐户。
如果逻辑应用的创建和部署设置支持使用 Application Insights,则可以选择为逻辑应用启用诊断日志记录和跟踪。 可以在 Visual Studio Code 中部署逻辑应用时或在部署后执行此操作。 你需要有一个 Application Insights 实例,但你可以在部署逻辑应用时提前创建此资源,或在部署后创建此资源。
若要立即启用日志记录和跟踪,请执行以下步骤:
选择一个现有 Application Insights 资源或“创建新的 Application Insights 资源”。
在 Azure 门户中,转到你的 Application Insights 资源。
在资源菜单中,选择“概述”。 查找并复制检测密钥值。
在 Visual Studio Code 中,在你的项目的根文件夹中打开 local.settings.json 文件。
在
Values
对象中,添加APPINSIGHTS_INSTRUMENTATIONKEY
属性,并将值设置为检测密钥,例如:{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "dotnet", "APPINSIGHTS_INSTRUMENTATIONKEY": <instrumentation-key> } }
提示
你可以检查触发器和操作名称是否正确显示在你的 Application Insights 实例中。
在 Azure 门户中,转到你的 Application Insights 资源。
在资源菜单中的“调查”下,选择“应用程序映射”。
查看映射中显示的操作名称。
来自内置触发器的某些入站请求在应用程序映射中可能会显示为重复项。 这些重复项使用工作流名称(而非使用
WorkflowName.ActionName
格式)作为操作名称,并且源自 Azure Functions 主机。接下来,你可以根据需要调整逻辑应用收集并发送到 Application Insights 实例的跟踪数据的严重性级别。
每次发生工作流相关事件时(例如,当触发了某个工作流时,或者当某个操作运行时),运行时会发出各种跟踪。 这些跟踪涵盖工作流的生存期,包括但不限于以下事件类型:
- 服务活动,例如启动、停止和错误。
- 作业和调度程序活动。
- 工作流活动,例如触发器、操作和运行。
- 存储请求活动,例如成功或失败。
- HTTP 请求活动,例如入站、出站、成功和失败。
- 任何开发跟踪,例如调试消息。
每个事件类型都分配有一个严重性级别。 例如,
Trace
级别捕获最详细的消息,而Information
级别捕获工作流中的常规活动,例如逻辑应用、工作流、触发器和操作何时开始和停止。 下表描述了各个严重性级别及其跟踪类型:严重性级别 跟踪类型 严重 此类日志描述逻辑应用中无法恢复的故障。 调试 此类日志可用于在开发期间进行调查,例如,入站和出站 HTTP 调用。 错误 此类日志指示工作流执行中的失败,但不会指示逻辑应用中的一般失败。 信息 此类日志跟踪逻辑应用或工作流中的常规活动,例如: - 触发器、操作或运行何时开始和结束。
- 逻辑应用何时启动或结束。跟踪 此类日志包含最详细的消息,例如,存储请求或调度程序活动,以及与工作流执行活动相关的所有消息。 警告 此类日志在逻辑应用中突出显示一个异常状态,但不会阻止其运行。 若要设置严重性级别,请在项目的根级别打开 host.json 文件,然后查找
logging
对象。 此对象控制逻辑应用中所有工作流的日志筛选,并遵循用于日志类型筛选的 ASP.NET Core 布局。{ "version": "2.0", "logging": { "applicationInsights": { "samplingExcludedTypes": "Request", "samplingSettings": { "isEnabled": true } } } }
如果
logging
对象未包含包括Host.Triggers.Workflow
属性的logLevel
对象,请添加这些项。 将该属性设置为所需跟踪类型的严重性级别,例如:{ "version": "2.0", "logging": { "applicationInsights": { "samplingExcludedTypes": "Request", "samplingSettings": { "isEnabled": true } }, "logLevel": { "Host.Triggers.Workflow": "Information" } } }
完成部署步骤后,Visual Studio Code 将开始创建和部署发布逻辑应用所需的资源。
若要查看和监视部署过程,请在“视图”菜单上选择“输出”。 从“输出”窗口的工具栏列表中,选择“Azure 逻辑应用”。
Visual Studio Code 将逻辑应用部署到 Azure 后,将显示以下消息:
恭喜,现在你的逻辑应用在 Azure 中处于活动状态,并已默认启用。
接下来,你可以了解如何执行以下任务:
向项目中添加空白工作流
逻辑应用项目中可以有多个工作流。 若要向项目中添加空白工作流,请执行以下步骤:
在 Visual Studio Code 活动栏上,选择 Azure 图标。
在 Azure 窗口中,从“工作区”部分工具栏上的“Azure 逻辑应用”菜单中选择“创建工作流”。
选择要添加的工作流类型:“有状态”或“无状态”
为你的工作流提供一个名称。
完成后,项目中会出现一个新的工作流文件夹,其中包含工作流定义的 workflow.json 文件。
在 Visual Studio Code 中管理已部署的逻辑应用
在 Visual Studio Code 中,你可以查看 Azure 订阅中所有已部署的逻辑应用(无论它们是消耗还是标准逻辑应用资源),然后选择可帮助你管理这些逻辑应用的任务。 但如果要访问这两种资源类型,则需要使用适用于 Visual Studio Code 的 Azure 逻辑应用(消耗)和 Azure 逻辑应用(标准)扩展。
在 Visual Studio Code 活动栏上,选择 Azure 图标。 在资源中,展开订阅,然后展开逻辑应用,其中显示了在 Azure 中为该订阅部署的所有逻辑应用。
打开要管理的逻辑应用。 从逻辑应用的快捷菜单中,选择要执行的任务。
例如,你可以选择的任务包括停止、启动、重启或删除已部署逻辑应用,等等。 可以通过使用 Azure 门户禁用或启用工作流。
注意
停止逻辑应用和删除逻辑应用操作以不同的方式影响工作流实例。 有关详细信息,请参阅停止逻辑应用的注意事项和删除逻辑应用的注意事项。
若要查看逻辑应用中的所有工作流,请展开你的逻辑应用,然后展开“工作流”节点。
若要查看某个特定工作流,请打开该工作流的快捷菜单,然后选择“在设计器中打开”,这将以只读模式打开工作流。
若要编辑工作流,可以使用以下选项:
在 Visual Studio Code 中,在工作流设计器中打开项目的 workflow.json 文件,进行编辑,并将逻辑应用重新部署到 Azure。
在 Azure 门户中打开你的逻辑应用。 然后可以打开、编辑和保存你的工作流。
若要在 Azure 门户中打开已部署的逻辑应用,请打开逻辑应用的快捷菜单,然后选择“在门户中打开”。
Azure 门户将在浏览器中打开,自动使你登录到门户(如果你已登录到 Visual Studio Code)并显示你的逻辑应用。
你还可以单独登录到 Azure 门户,使用门户搜索框查找你的逻辑应用,然后从结果列表中选择你的逻辑应用。
停止逻辑应用的注意事项
停止逻辑应用会通过以下方式影响工作流实例:
Azure 逻辑应用会立即取消所有正在进行和挂起的运行。
Azure 逻辑应用不会创建或运行新的工作流实例。
下次满足触发器的条件时,触发器不会触发。 但是,触发器状态会记住逻辑应用的停止点。 因此,如果重启逻辑应用,触发器就会触发自上次运行以来的所有未处理项。
若要阻止触发器触发自上次运行以来的未处理项,请在重启逻辑应用之前清除触发器状态:
在 Visual Studio Code 活动栏上选择 Azure 图标,打开 Azure 窗口。
在资源部分中,展开订阅,这会显示该订阅的所有已部署逻辑应用。
展开你的逻辑应用,然后展开名为“工作流”的节点。
打开工作流,然后编辑该工作流触发器的任何部分。
保存所做更改。 此步骤会重置触发器的当前状态。
对每个工作流重复此操作。
完成后,重启逻辑应用。
删除逻辑应用的注意事项
删除逻辑应用会以下列方式影响工作流实例:
Azure 逻辑应用会立即取消正在进行和挂起的运行,但不会在应用所使用的存储上运行清理任务。
Azure 逻辑应用不会创建或运行新的工作流实例。
如果删除工作流,然后重新创建相同的工作流,则重新创建的工作流不会具有与删除的工作流相同的元数据。 若要刷新元数据,必须重新保存调用已删除工作流的所有工作流。 这样,调用方就可获取重新创建的工作流的正确信息。 否则,对重新创建的工作流的调用将失败并显示
Unauthorized
错误。 此行为也适用于在集成帐户中使用项目的工作流和调用 Azure 函数的工作流。
在门户中管理已部署的逻辑应用
从 Visual Studio Code 将逻辑应用部署到 Azure 门户之后,可以查看 Azure 订阅中所有已部署的逻辑应用,无论它们是消耗还是标准逻辑应用资源。 目前,在 Azure 中,每种资源类型都作为单独的类别进行组织和管理。 要查找标准逻辑应用,请执行以下步骤:
在 Azure 门户搜索框中,输入“逻辑应用”。 当结果列表出现时,在“服务”下选择“逻辑应用” 。
在“逻辑应用”窗格中,选择你从 Visual Studio Code 部署的逻辑应用。
Azure 门户将打开所选逻辑应用的单个资源页。
若要查看此逻辑应用中的工作流,请在逻辑应用菜单上选择“工作流”。
“工作流”窗格将显示当前逻辑应用中的所有工作流。 此示例显示了你在 Visual Studio Code 中创建的工作流。
若要查看工作流,请在“工作流”窗格中选择该工作流。
工作流窗格将打开,并显示更多信息和你可对该工作流执行的任务。
例如,若要查看工作流中的步骤,请选择“设计器”。
工作流设计器将打开并显示你在 Visual Studio Code 中构建的工作流。 你现在可以在 Azure 门户中对此工作流进行更改。
在门户中添加另一个工作流
通过 Azure 门户,你可以将空白工作流添加到从 Visual Studio Code 部署的标准逻辑应用资源中并在 Azure 门户中构建这些工作流。
在 Azure 门户中,选择已部署的标准逻辑应用资源。
在逻辑应用资源菜单中,选择工作流。 在“工作流”窗格上,选择“添加”。
在“新建工作流”窗格中,提供工作流的名称。 选择“有状态”或“无状态”>“创建”。
在 Azure 部署了“工作流”窗格中显示的新工作流后,选择该工作流,以便管理和执行其他任务,例如打开设计器或代码视图。
例如,打开新工作流的设计器将显示一个空白画布。 现在,你可以在 Azure 门户中构建此工作流。
为无状态工作流启用运行历史记录
若要更轻松地调试某个无状态工作流,可以为该工作流启用运行历史记录,并在完成后禁用运行历史记录。 对于 Visual Studio Code,请按照下面的步骤操作;如果使用的是 Azure 门户,请参阅在 Azure 门户中创建基于单租户的工作流。
在 Visual Studio Code 项目中,在根文件夹级别打开 local.settings.json 文件。
添加
Workflows.{yourWorkflowName}.operationOptions
属性,并将值设置为WithStatelessRunHistory
,例如:Windows
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "dotnet", "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory" } }
macOS 或 Linux
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=fabrikamstorageacct; \ AccountKey=<access-key>;EndpointSuffix=core.chinacloudapi.cn", "FUNCTIONS_WORKER_RUNTIME": "dotnet", "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory" } }
在名为“workflow-designtime”的项目文件夹中,打开“local.settings.json”文件并进行相同的更改。
若要在完成时禁用运行历史记录,请将
Workflows.{yourWorkflowName}.OperationOptions
属性设置为None
,或者删除此属性及其值。
在 Azure 门户中启用监视视图
将逻辑应用(标准版)资源从 Visual Studio Code 部署到 Azure 后,可使用 Azure 门户和该工作流的“监视器”体验来查看该资源中工作流的所有可用的运行历史记录和详细信息。 但是,必须先对该逻辑应用资源启用“监视器”视图功能。
在 Azure 门户中,打开标准逻辑应用资源。
在逻辑应用资源菜单的 API 下,选择 CORS。
在“CORS”窗格上,在“允许的来源”下添加通配符 (*)。
完成后,在“CORS”工具栏上选择“保存”。
在部署后启用或打开 Application Insights
在工作流执行过程中,你的逻辑应用会发出遥测数据以及其他事件。 使用此遥测数据可以更好地了解工作流的运行情况以及逻辑应用运行时如何以各种方式工作。 你可以使用 Application Insights 来监视工作流,该工具可提供近乎实时的遥测数据(实时指标)。 使用该数据来诊断问题、设置警报和构建图表时,此功能可帮助你更轻松地调查失败和性能问题。
如果逻辑应用的创建和部署设置支持使用 Application Insights,则可以选择为逻辑应用启用诊断日志记录和跟踪。 可以在 Visual Studio Code 中部署逻辑应用时或在部署后执行此操作。 你需要有一个 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 部分)
从设计器中删除项
若要从设计器中删除工作流中的某个项,请执行以下任一步骤:
选择该项,打开该项的快捷菜单 (Shift + F10),然后选择“删除”。 若要确认,请选择“确定”。
选择该项,然后按 Delete 键。 若要确认,请选择“确定”。
选择该项,以便为该项打开详细信息窗格。 在窗格的右上角,打开省略号 (...) 菜单,然后选择“删除”。 若要确认,请选择“确定”。
提示
如果省略号菜单不可见,请充分扩展 Visual Studio Code 窗口,以使详细信息窗格在右上角显示省略号 ( ... ) 按钮。
排查错误和问题
设计器未能打开
尝试打开设计器时出现以下错误:“无法启动工作流设计时”。 如果你以前尝试打开了该设计器,然后停用或删除了你的项目,则扩展捆绑包可能无法正确下载。 若要检查错误是否由此原因导致,请执行以下步骤:
在 Visual Studio Code 中,打开“输出”窗口。 从“视图”菜单中,选择“输出”。
从“输出”窗口的标题栏中的列表中,选择“Azure 逻辑应用(标准版)”以便查看来自扩展的输出,例如:
查看输出并检查是否显示了以下错误消息:
A host error has occurred during startup operation '{operationID}'. System.Private.CoreLib: The file 'C:\Users\{userName}\AppData\Local\Temp\Functions\ ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows\1.1.7\bin\ DurableTask.AzureStorage.dll' already exists. Value cannot be null. (Parameter 'provider') Application is shutting down... Initialization cancellation requested by runtime. Stopping host... Host shutdown completed.
若要解决此错误,请删除位于 ...\Users{your-username}\AppData\Local\Temp\Functions\ExtensionBundles 位置的 ExtensionBundles 文件夹,然后重试在设计器中打开 workflow.json 文件。
对于以前创建的工作流,设计器选取器中缺少新的触发器和操作
单租户 Azure 逻辑应用支持将内置操作用于 Azure 函数操作、Liquid 操作和 XML 操作(例如 XML 验证和转换 XML)。 但是,对于以前创建的逻辑应用,如果 Visual Studio Code 使用的是过时版本的扩展捆绑包 Microsoft.Azure.Functions.ExtensionBundle.Workflows
,则这些操作可能不会出现在设计器选取器中供你选择。
此外,“Azure 函数操作”连接器和操作不会显示在设计器选取器中,除非你在创建逻辑应用时启用或选择了“使用 Azure 提供的连接器”。 如果你在创建应用时未启用 Azure 部署的连接器,则可以在 Visual Studio Code 中从你的项目启用它们。 打开 workflow.json 的快捷菜单并选择“使用 Azure 提供的连接器”。
若要修复过时的捆绑包,请按照以下步骤删除过时的捆绑包,这会使 Visual Studio Code 自动将扩展捆绑包更新到最新版本。
注意
此解决方案仅适用于使用 Visual Studio Code 通过 Azure 逻辑应用(标准版)扩展创建的逻辑应用,不适用于使用 Azure 门户创建的逻辑应用。 请参阅 Azure 门户中的设计器缺少受支持的触发器和操作。
保存所有不希望丢失的工作,然后关闭 Visual Studio。
在你的计算机上,浏览到以下文件夹,其中包含现有捆绑包的带版本号的文件夹:
...\Users\{your-username}\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows
删除早期捆绑包的版本文件夹,例如,如果存在版本 1.1.3 的文件夹,请删除该文件夹。
现在,浏览到以下文件夹,其中包含所需 NuGet 程序包的带版本号的文件夹:
...\Users\{your-username}\.nuget\packages\microsoft.azure.workflows.webjobs.extension
删除早期版本包的版本文件夹。
重新打开 Visual Studio Code 和你的项目,在设计器中打开 workflow.json 文件。
缺少的触发器和操作现在将出现在设计器中。
触发器或操作中出现“400 错误请求”
当某个运行失败时,如果在监视视图中检查该运行,在名称较长的触发器或操作上可能会显示此错误,这些名称太长会导致基础统一资源标识符 (URI) 超出默认字符数限制。
若要解决此问题并调整较长的 URI,请按照以下步骤在计算机上编辑 UrlSegmentMaxCount
和 UrlSegmentMaxLength
注册表项。 适用于 Windows 的 Http.sys 注册表设置主题中介绍了这些项的默认值。
重要
在开始之前,请务必保存你的工作。 此解决方案要求你在完成后重启计算机,以便使更改生效。
在你的计算机上,打开“运行”窗口并运行
regedit
命令,这将打开注册表编辑器。在“User Account Control”框中选择“Yes”,以允许对计算机进行更改。
在左侧窗格中,在“Computer”下面沿路径“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters”展开节点,然后选择“Parameters”。
在右侧窗格中,查找
UrlSegmentMaxCount
和UrlSegmentMaxLength
注册表项。充分增大这些项的值,使 URI 可以容纳你要使用的名称。 如果这些项不存在,请执行以下步骤,将它们添加到“Parameters”文件夹:
从“Parameters”快捷菜单中,选择“新建”>“DWORD(32-位)值”。
在出现的编辑框中,输入
UrlSegmentMaxCount
作为新的项名称。打开新项的快捷菜单并选择“修改”。
在出现的“编辑字符串”框中,以十六进制或十进制格式输入所需的“数值数据”项值。 例如,十六进制的
400
等效于十进制的1024
。若要添加
UrlSegmentMaxLength
项值,请重复这些步骤。
在增大或添加这些项值后,注册表编辑器如以下示例所示:
准备就绪后,重启计算机,以使更改生效。
调试会话未能启动
尝试启动调试会话时,你收到错误运行 preLaunchTask“generateDebugSymbols”后存在错误。 若要解决此问题,请编辑项目中的 tasks.json 文件以跳过符号生成。
在你的项目中,展开名为“.vscode”的文件夹,然后打开“tasks.json”文件。
在下面的任务中,删除
"dependsOn: "generateDebugSymbols"
行以及上一行末尾的逗号,例如:早于:
{ "type": "func", "command": "host start", "problemMatcher": "$func-watch", "isBackground": true, "dependsOn": "generateDebugSymbols" }
晚于:
{ "type": "func", "command": "host start", "problemMatcher": "$func-watch", "isBackground": true }
后续步骤
我们希望你就 Azure 逻辑应用(标准版)扩展的使用体验提供反馈!
- 如果发现 bug 或问题,请在 GitHub 中创建问题。
- 如有问题、请求、意见和其他反馈,请使用此反馈表单。