介绍了 SharePoint 现在如何依赖工作流管理器 1.0 执行所有工作流处理和管理工作，并介绍了调试选项。
提供者：Andrew Connell、 Voitanos
注意
自 2020 年 8 月 1 日起，SharePoint 2010 工作流已对新租户停用，并于 2020 年 11 月 1 日从现有租户中删除。 如果你使用的是 SharePoint 2010 工作流，我们建议迁移到 Power Automate 或其他支持的解决方案。 有关详细信息，请参阅 SharePoint 2010 工作流停用。
工作流团队与 Azure 团队合作，共同打造了名为“工作流管理器”的产品。 工作流管理器通过可伸缩的可用方式，托管最新版 Windows Workflow Foundation 运行时和所有必需服务。 它利用 Microsoft Azure 服务总线实现性能和可伸缩性。部署后，它在本地部署和云（类似于 Office 365）中的运行方式完全相同。 然后，SharePoint 会进行连接，并配置为将所有工作流执行和相关任务都移交给工作流管理器场。
鉴于这种体系结构变化，需要对客户用来创建自定义工作流的两个主要工作流创作工具（SharePoint Designer 2013 和 Visual Studio 2012）进行一些更改。 不过，开发者在 SharePoint 2007 和 SharePoint 2010 中利用的调试技术仍适用。 借助新的体系结构，使用 SharePoint Designer 2013 或 Visual Studio 2012 创建的工作流可以使用新选项 Fiddler，监视 SharePoint 和工作流管理器之间的流量。
SharePoint 工作流调试概述
调试为 SharePoint 创建的自定义工作流与旧版（包括 SharePoint 2010 和 SharePoint 2007）类似。 一些调试选项是否可用取决于创建工作流所用的工具（SharePoint Designer 2013 或 Visual Studio 2012），以及 SharePoint 部署类型（如本地部署或 Office 365（托管））。 工作流作者可以利用 4 种工作流调试技术：
- 记录到工作流历史记录列表
- 设置断点
- 向控制台发送调试消息
- 通过 Fiddler 监控 SharePoint 和 工作流管理器 之间的流量
每个选项都有优点和缺点。 了解使用两种工作流创作工具（SharePoint Designer 2013 或 Visual Studio 2008），以及工作流部署类型（本地部署或 Office 365）的情况下可用的选项会有所帮助。 下表包含创作工具、部署目标和每种方案中可用选项的矩阵。
| 产品 | SharePoint 本地 | Office 365 SharePoint Online |
|---|---|---|
| SharePoint Designer 2013, SharePoint Online | 记录到历史记录列表 Fiddler | 记录到历史记录列表 |
| Visual Studio 2012 | 记录到历史记录列表断点控制台调试消息 Fiddler | 记录到历史记录列表断点 |
使用工作流历史记录列表调试
唯一对每种类型 SharePoint 部署都可用的调试选项是，将日志消息写入工作流历史记录列表。 By using this method, you can use either the Log to History List action in SharePoint Designer 2013 or the WriteToHistory activity in Visual Studio 2012 to write a string message as a new item to the list, specified in the workflow association, which is the container for all history logging messages. These can be simple strings or constructed by concatenating the contents of variables within the workflow.
使用历史记录列表作为调试工具不是理想做法，因为用户可以看到消息。 因此，当调试会话完成且将工作流用于生产中后，工作流开发人员会希望删除这些消息，从而在调试和部署之间创建其他步骤。 尽管如此，这是在所有方案中都可用的唯一选项，无论使用哪种工具创建工作流或使用哪种 SharePoint 部署类型。
使用 Visual Studio 2012 断点调试
另一个调试选项是利用断点。 断点仅适用于使用 Visual Studio 2008 创建的工作流，因为 SharePoint Designer 2013 无法设置断点或将调试程序附加到运行的过程。 这些断点在 SharePoint 本地部署和托管部署（如 Office 365）中都可用。 在此方案中，你将在工作流的活动中设置断点，然后以调试模式启动工作流。
图 1. 启动工作流
Visual Studio 会将工作流部署到目标 SharePoint 环境中并附加一个调试程序。 当工作流过程达到设置断点的活动时，Visual Studio 重新获得焦点，让你检查工作流变量的值并单步调试 Visual Studio 2008 中的每个活动，如下图所示。
图 2. 工作流断点
使用调试消息和测试服务主机调试工作流
将 工作流管理器 引入 SharePoint 工作流层提供了两个新调试机会，可在使用 Visual Studio 2008 创建自定义工作流和在本地部署中进行测试时使用。 Visual Studio 2008 包含 WriteLine 活动，该活动接受使用基于单一字符串的消息作为输入。
图 3. WriteLine 活动
This activity will write the message that resembles the System.Diagnostics.Debug.WriteLine() method in a standard .NET Windows Console Application. The Workflow Manager 1.0 development tool includes a console utility that is named the Test Service Host that Visual Studio 2012 will open when a new debugging session is started and when testing with an on-premises SharePoint deployment. 此控制台实用工具 Microsoft.Workflow.TestServiceHost.exe 在 C：\Program Files (x86) \工作流管理器 Tools\1.0 中找到，它附加到已注册的 工作流管理器 实例，并侦听使用 WriteLine 活动写入的消息，如下图所示。
图 4. WriteLine 活动的消息
这些消息与控制台应用程序中的代码注释或调试消息类似。 与写入工作流历史记录列表不同，你无需在将工作流部署到生产中之前删除这些消息。 除非"测试服务主机"实用程序连接到 工作流管理器，否则消息是无害的。
This debugging option is not available for workflows created using SharePoint Designer 2013, because there is no action that maps to the WriteLine activity. Unfortunately, this debugging option is available only to SharePoint on-premises installations, since the port used by the Test Service Host utility is typically not publically accessible outside an on-premises network. This is also true for Office 365. The ports SharePoint uses to connect to Workflow Manager are the same ones used by the Test Service Host, and those are only accessible within the trusted network. However, this does not mean that you need to change their workflows to remove any WriteLine activities before deployment to Office 365. 这些活动可以保留在工作流中，因为它们并不可见，除非测试服务主机连接到工作流管理器。
使用 Fiddler 调试（通过监视 HTTP 流量）
最后一个 SharePoint 工作流调试选项是面向工作流开发者的新增选项，也是当前平台中工作流处理方式发生变化的产物。 回顾一下，在 SharePoint 中，所有工作流处理工作都移交给了外部产品工作流管理器 1.0。 当工作流需要与 SharePoint 进行通信（如更新工作流的当前状态、收集 SharePoint 网站中项或用户的数据），或当要处理任务时，工作流管理器的活动会利用 SharePoint REST API 执行这些操作。 SharePoint 使用客户端库与工作流管理器进行通信。此客户端库是工作流管理器公开的 REST 服务的代理。 SharePoint 和 工作流管理器 都使用标准 HTTP 和 HTTPS 协议进行彼此通信。
此体系结构为工作流作者生成了一个新调试选项。 通过使用 HTTP 调试代理工具 Fiddler，你可以监控两种产品之间的每个请求和相应响应。 此外，自定义工作流使用 Visual Studio 2008 中的 HttpSend 活动或 SharePoint Designer 2013 中的相应 Call HTTP Web Service 操作调用的任何自定义服务也可以通过 Fiddler 监控和检查。 无论使用哪种工具创建自定义工作流（SharePoint Designer 2013 或 Visual Studio 2008），此调试模型都可用。
此选项仅在使用 Office 365 部署的 SharePoint 测试工作流时不可用。 由于 SharePoint 与工作流管理器之间的所有流量都发生在服务器端，因此无法既连接到 Office 365 中的一个服务器，同时还通过控制台启动 Fiddler。
使用这一新选项，可以全透明地深入了解工作流引擎，而在旧版 SharePoint 中开发工作流时则无法实现这一点。
例如，Web 服务调用中包含从工作流管理器或 SharePoint 返回的原始响应。 有时，工作流管理器可能会在响应中返回特定的错误消息。 虽然 SharePoint 包含易记错误消息，但这些消息可能不够具体。 使用 Fiddler，可以查看返回的确切错误消息，这些消息有助于排查问题。
另一个使用案例是检查来自成功 Web 服务调用的响应。 在工作流中使用 Web 服务时，无论使用哪种创作工具，你都需要了解包含在响应中的值的确切属性名称（和路径，如果是复杂响应）。 通过使用 Fiddler，你可以查看完整的响应数据。
了解 SharePoint 和工作流管理器以使用 Fiddler 进行调试
若要通过 Fiddler 调试 SharePoint 和 工作流管理器 1.0 中的工作流，在调试之前必须在开发人员环境中执行一些配置和设置步骤。 完成这些步骤之前，了解 Fiddler 的工作原理及工作流在 SharePoint 中的工作方式会有所帮助。
Fiddler 只能检查来自本地服务器的流量
Fiddler 唯一可以拦截和检查的流量是从启动了 Fiddler 的本地服务器发出的请求。 如果将 Fiddler 用作 SharePoint 工作流调试工具，这可能会带来挑战。
如果 SharePoint 和工作流管理器 1.0 安装在不同的服务器上，且 Fiddler 是从 SharePoint Server 启动，那么 Fiddler 唯一显示的流量是从 SharePoint 发出的请求。 不会拦截来自工作流管理器 1.0 的任何流量，即使它定目标到 SharePoint Server，也不例外。
因此，开发工作流时，如果 SharePoint 和工作流管理器 1.0 安装在同一台服务器上，就可以更轻松地调试工作流。 请注意，这并不是一项硬性规定；可以在 SharePoint Server 和工作流管理器服务器上同时启动 Fiddler，只不过这会让监视同一工作流在两台服务器上的两个实例变得更加复杂。
Fiddler 只能检查来自当前登录用户的流量
Fiddler 仅可以截获和检查当前登录用户的流量。 若要查看源自 SharePoint 的流量，你必须使用 Windows 帐户登录到 SharePoint Server，该帐户配置为应用程序池（托管启动工作流的 SharePoint 网站的 Web 应用程序）的标识。
对 工作流管理器 而言也是如此。 若要截获并检查源自 工作流管理器 的流量，你必须使用 Windows 标识登录到服务器，该标识在 工作流管理器 服务器场调配过程中配置为 工作流管理器 的服务帐户。
使用 Fiddler 调试工作流时，如果工作流管理器和 SharePoint 不仅是在同一台服务器上进行安装和配置，而且还使用相同的 Windows 标识作为服务帐户，那么调试工作流将会更容易进行。 Fiddler 可以拦截和检查来自工作流管理器和 SharePoint 的所有流量。
SharePoint 必须信任 Fiddler 的证书
使用 Fiddler 调试 SharePoint 工作流前，需要先了解加密流量的处理方式。 通过 HTTP 的加密流量（亦称为“HTTPS”）的实现方式为，使用证书私钥对一些数据进行加密，再将数据发送给其他接收方。 接收方拥有与私钥配对的证书公钥。 收到请求时，接收方可以验证请求是否来自发送方，因为只有使用证书私钥加密的内容的签名才会与公钥一致。
Fiddler 可以拦截 HTTPS 流量，并配置为将加密流量解密为可读格式，以供在工具中进行检查。 显示请求后，Fiddler 便会使用自己的证书重新加密流量，并将它发送给预期的接收方。 但问题来了，因为现在接收方收到的是原始响应，但它并没有使用原始发送方的证书进行保护。 这可能会导致 SharePoint 工作流调试出现问题，因为 SharePoint 并不信任 Fiddler 的证书。 因此，为了能够使用 Fiddler 拦截并检查 SharePoint 与工作流管理器之间的 HTTPS 流量，SharePoint 必须信任 Fiddler 证书。
配置 SharePoint 和工作流管理器 1.0 以便使用 Fiddler 调试工作流
下面各部分介绍了如何为了调试工作流而配置 Fiddler 和 SharePoint。
配置 .NET Framework 默认代理配置
第一步是先定义 .NET Framework 默认代理配置。 借助这些更改，Fiddler 可以拦截来自 SharePoint 和工作流管理器的流量。 打开下面两个位置上的“machine.config”文件：
%systemdrive%\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Config\\machine.config%systemdrive%\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\Config\\machine.config
接下来，将以下标记添加到每个文件的底部，紧靠在结束 <配置> 元素之前：
<system.net>
<defaultProxy enabled="true">
<proxy bypassonlocal="false" usesystemdefault="true" />
</defaultProxy>
</system.net>
保存更改并关闭文件。
配置 Fiddler 以截获和检查 HTTPS 流量
下一步是配置 Fiddler 以截获加密流量并将其解密以进行配置。
- 启动 Fiddler。
- 如果使用本地 HOSTS 文件，请确保通过选择 “工具 -> 主机 ”菜单选项将条目包含在 Fiddler 中。
- 选中"启用将一个主机的请求重新映射到另一个主机或 IP，覆盖 DNS"。
- 单击"导入 Windows 主机文件"，然后单击"保存"按钮。
图 5. 主机重新映射
接下来，配置 Fiddler 的连接选项。
选择 “工具 -> Fiddler 选项” 菜单选项。
单击"连接"选项卡。
清除"链至上游网关代理"选择。
选择"在启动时充当系统代理"和"监控所有连接"选项，如下图所示。
选择"Fiddler 选项"对话框中的"HTTPS"选项卡。
选中"捕获 HTTPS 连接"。
选中“解密 HTTPS 流量”。
选择“...来自所有进程”。
选中“忽略服务器证书错误”。
单击"将根证书导出到桌面"按钮。
出现警告提示后，单击"是"以"信任 Fiddler 根证书"。
此过程会将 Windows 配置为信任证书，尽管 SharePoint 尚不信任该证书。
图 7. “HTTPS”选项卡
注意
如果看到提示不要信任 Fiddler 证书的安全警告消息，请单击“是”，继续安装证书。
将 SharePoint 配置为信任证书
最后一步是配置 SharePoint 以信任在前一步中导出的 Fiddler 证书。
以 SharePoint 服务器场管理员身份登录。
启动 SharePoint 命令行管理程序。
加载 SharePoint 管理单元。
Add-PSSnapIn Microsoft.SharePoint.PowerShell使用证书实用程序安装 Fiddler 证书。
$fidderCertificatePath = [full path to exported FiddlerRoot.cer certificate file] certutil.exe -addstore -enterprise -f -v root $fidderCertificatePath $fiddlerCertificate = Get-PfxCertificate -FilePath $fidderCertificatePath New-SPTrustedRootAuthority -Name "Fiddler" -Certificate $fiddlerCertificate运行 IISRESET 以确保 SharePoint 获得了证书信任更改。
演练：使用 Fiddler 调试 SharePoint 工作流
此简单演练展示了如何使用 Fiddler 调试通过 Visual Studio 2012 创作的 SharePoint 工作流。 当工作流启动时，它会从自定义列表字段中检索客户 ID。 此客户 ID 用于查询可公开访问的服务，从而检索客户的其他详细信息。 然后，使用这些值更新原始列表项。 有关此工作流，可以参阅下面的 MSDN 代码示例：SharePoint 工作流：调用外部 Web 服务。
此演练的先决条件如下：
SharePoint 和工作流管理器 1.0 安装在同一台服务器上。
Windows 标识 CONTOSO\SP_Content 是为应用程序池标识配置的，该标识托管为启动工作流的 SharePoint 网站提供服务的 Web 应用程序。
用于启动工作流的 SharePoint 网站是
http://intranet.contoso.com工作流管理器 1.0 场终结点是 w15sp.contoso.com。
SharePoint 和工作流管理器 1.0 均配置为允许通过 HTTP 使用 OAuth。
警告
除非为了进行测试和调试，否则切勿在生产服务器上执行此操作。
通过配置为 工作流管理器 1.0 服务器场帐户和 SharePoint 应用程序池标识的 Windows 标识登录到安装了工作流管理器和 SharePoint 的服务器。
启动 Fiddler。 Fiddler 现在将截获当前用户的流量，但如果有任何现有连接或运行的过程，Fiddler 可能会错过这些流量，因为最初建立连接时 Fiddler 未运行。 若要强制工作流管理器和 SharePoint Server 回收并让 Fiddler 截获彼此间的流量，请通过运行 IISRESET 回收 SharePoint 及通过停止和启动 Windows 服务“工作流管理器后端”回收工作流管理器。 该过程可通过在管理命令提示符处执行以下两个命令完成。
IISRESET net stop WorkflowServiceBackend net start WorkflowServiceBackend启动工作流。
在下图中，注意会话 18 至 36 源自 SharePoint，会话 37 至 43 源自 工作流管理器。
图 8. 启动工作流
请注意，在会话 36 中，SharePoint 请求工作流管理器启动工作流（图中 [A]），工作流管理器在响应（图中 [B]）中返回“成功”消息：
图 9. “成功”消息响应
在会话 40 中，工作流管理器 从 SharePoint 检索列表项 ID 和 GUID。
图 10. 检索项目 ID 和 GUID
在会话 43 中，工作流管理器 更新 SharePoint 中的列表项，通过作为负载传递 JavaScript 对象表示法 (JSON) 对象（图中以 [A] 表示）为公告项的"正文"字段提供新值。 SharePoint 响应 HTTP 状态 204，指示已成功处理请求，但响应中没有任何消息。
图 11. 更新列表项
结束语
SharePoint 版本中的工作流情景新引入了一个抽象层，即工作流管理器 1.0。 这一新体系结构改变了工作流的处理方式。 SharePoint 现在依赖工作流管理器 1.0 执行所有工作流处理和管理工作。
在工作流中创建自定义应用和业务流程时，需要执行的一项任务是调试工作流。 借助 SharePoint 的新工作流体系结构，可以使用旧版 SharePoint 中的调试选项。 不过，使用新体系结构创建自定义工作流时，可以利用新体系结构提供的两个新选项。 本文既介绍了旧调试选项，也介绍了新调试选项，一种是使用 WriteLine 活动，另一种是使用 Fiddler 拦截并检查 SharePoint 与工作流管理器 1.0 之间的流量。