基础: Windows Workflow Foundation 中的跟踪服务(转与 MSDN)

Windows Workflow Foundation 中的跟踪服务
Matt Milner
Get the sample code for this article. NEW:Explore the sample code online!
- or -
代码下载位置:Foundations2007_03.exe (178KB)
目录
跟踪体系结构
跟踪配置文件
SQL 跟踪服务
查询跟踪数据
自定义跟踪服务
Windows Workflow Foundation 中最强大的功能之一是跟踪。它使您能够监控事件、活动属性以及您的工作流中的自定义数据。在本专栏中，我将检查跟踪基础结构、向您介绍如何使用内置的基于 SQL Server™ 的跟踪服务以及如何为各种应用创建自定义跟踪服务。顺着这一思路，我将演示如何使用所跟踪的信息以及如何通过使用跟踪来满足一些常见的需求。
许多应用程序需要了解程序逻辑和处理步骤的执行。这有助于企业遵守法规，根据执行里程碑或各种其他原因来管理风险列表。Windows® Workflow Foundation 提供了灵活的基础结构，您可以在其中覆盖您的自定义实现，而不必为各应用程序创建不同的跟踪系统。这简化了开发模型，使您可以关注于跟踪的业务要求。
跟踪体系结构
当在 Windows Workflow Foundation 中承载工作流时，您既可以承载工作流运行库，也可以承载一组运行时服务。许多运行时服务（如持久性服务）必须最多有一个在运行库中注册的实例。跟踪服务是个例外，允许将多个跟踪服务添加到运行库中以支持不同的业务要求。这使您能够将若干不同的跟踪任务应用于一个应用程序，各跟踪服务负责特定的实现。
Windows Workflow Foundation 中的跟踪基于中央侦听器，侦听器可监控活动和工作流事件并将相应的数据发送到各个配置的跟踪服务。（这种体系结构如图 1 所示。）跟踪侦听器接收所有事件的通知，但多数情况下，只有这些事件中的一个子集是有用的。而且，如果您要使用多个跟踪服务，各任务有可能将只关注于唯一一个信息子集。因此，跟踪侦听器将查询各配置的跟踪服务以跟踪各类工作流的配置文件。

图 1 跟踪体系结构 (单击该图像获得较小视图)

图 1 跟踪体系结构 (单击该图像获得较大视图)
跟踪配置文件为侦听器提供关于跟踪服务要接收的事件的类型的信息。这些事件可以分为三类：工作流、活动和用户。
工作流事件使您能够跟踪工作流可能处于的各种状态，以及它们发生的时间。对于包含自定义事件参数的事件，如 WorkflowTerminated 或 WorkflowCompleted，事件参数本身可被跟踪，并随后被查询。
活动事件使您能够跟踪活动进入特定状态的时间和活动进入该状态时具体的活动属性值。例如，如果您有一个发送电子邮件的活动，当活动进入 Closed 状态时，您可以跟踪 To 地址属性。
最后，用户事件使您可以在您的工作流或活动中手动跟踪数据。

跟踪配置文件
每个跟踪服务都必须向跟踪侦听器提供跟踪配置文件。一个服务可以为所有工作流提供相同的配置文件，也可以为不同类型的工作流提供不同的配置文件。由服务编写者确定管理和生成配置文件的方式。
可使用在 System.Workflow.Runtime.Tracking 命名空间中或直接在 XML 中找到的对象模型来创建跟踪配置文件。通常使用对象模型来创建它们，但这不是表示配置文件的唯一方法，也并非最佳方法。因此，跟踪配置文件可被序列化到 XML，也可以从 XML 反序列化。您可以使用 TrackingProfileSerializer 类将 TrackingProfile 对象转换为 XML 文本，反之亦然。Windows SDK 中的 Tracking Profile Designer（跟踪配置文件设计器）示例是与此有关的一个有用示例，也是基本跟踪配置文件编辑的一个不错工具。该应用程序使您能够使用工作流设计图面可视化地定义跟踪配置文件。尽管该工具有一些局限性，如缺乏对用户跟踪点的支持，但它可使您查看序列化形式的跟踪文件。在许多情形下，它还可加快开发和部署跟踪配置文件的速度。
跟踪配置文件实质上是一组跟踪点。各跟踪点与被跟踪的事件的类型相关，为运行库提供了关于何时提取数据以及提取哪些数据的信息。例如，要指明应跟踪的工作流事件，WorkflowTrackPoint 必须被添加到跟踪配置文件中。跟踪点包含一个或多个跟踪位置，这些跟踪位置实际定义了跟踪数据的位置和时间。例如，在 WorkflowTrackPoint 中，MatchingLocation 属性可识别各种要跟踪的工作流事件。图 2 中的代码显示了要创建的跟踪配置文件。它有一个 WorkflowTrackPoint，指明了服务要跟踪失败条件（如异常、终止和工作流终止）。
ActivityTrackPoint 支持更丰富的跟踪。由于活动构成了工作流的核心，因此这是符合逻辑的。ActivityTrackPoint 包含 MatchingLocations 和 ExcludedLocations 集合，使您能够密切控制数据收集的时间。对于上述两个集合，您可以定义代表您要匹配的条件集合的 ActivityTrackingLocation。
ActivityTrackingLocation 类使您能够定义您要根据其类型进行跟踪的活动。您还可以指明您是否要匹配派生的活动。例如，如果您要匹配所有活动，则应当使用 System.ComponentModel.Activity 类型并将 MatchDerivedTypes 设置为 True。这样就能匹配所有基础活动类以及由其派生的所有活动。您还可以将此信息添加到 ActivityTrackPoint 的 MatchingLocations 集合以指明您要跟踪这些事件，或者将此信息添加到 ExcludedLocations 集合以指明该数据不应被收集。
为了进行更详细的控制，您可以指定为跟踪数据必须满足的条件（以属性等式的形式）。例如，您可能选择仅当 SendEmail 活动的优先级属性设置为 High 时才跟踪电子邮件。图 3 显示了这样一个示例。
您还能够以属性值的形式从活动或工作流提取数据。例如，当在工作流中到达您的匹配位置时，您可以跟踪 SendEmail 活动的 To 和 Subject 属性。可以通过将 ActivityDataTrackingExtract 或 WorkflowDataTrackingExtract 项添加到 ActivityTrackPoint 的 Extracts 集合来实现此跟踪。每个 ActivityDataTrackingExtract 都可识别要提取并发送到跟踪服务的成员。将数据提取添加到活动跟踪点，这样被跟踪的 To 和 Subject 属性就如下所示：actTrack.Extracts.Add(new ActivityDataTrackingExtract("To"));actTrack.Extracts.Add(new ActivityDataTrackingExtract("Subject"));
 
三种类型中最灵活的是可以识别最后跟踪点的 UserTrackPoint。有时，您需要跟踪来自工作流但不可用作活动属性的数据。或者可能需要使用 ActivityTrackingLocation 中简单条件支持以外的逻辑。在这种情况下，您可以调用 ActivityExecutionContext 或 Activity 类中的 TrackData 方法。这使您可以将数据与数据项的可选密钥或名称发送到跟踪侦听器。对于接收该数据的跟踪服务，必须定义具有正确匹配位置的 UserTrackPoint。您还可以定义工作流和活动数据提取，以便在 UserTrackPoint 匹配时跟踪工作流或当前活动的属性。

SQL 跟踪服务
Windows Workflow Foundation 包括 SQL Server 跟踪服务，该服务使您能够定义某个工作流类型的跟踪配置文件并将其部署到 SQL Server。在运行时，跟踪服务使用该配置文件以配置跟踪侦听器。SQL Server 跟踪服务包括几个出色的功能，如配置文件版本管理、配置文件更新通知和数据划分。
通过调用 UpdateTrackingProfile 存储过程并在系列化配置文件中进行传递，可将跟踪配置文件部署到 SQL 跟踪服务，其中包括工作流类型信息和版本号。您可以使用此存储过程来插入特定于您的工作流类型的跟踪配置文件，但每次更新配置文件时您必须使用唯一的版本号。我前面所谈到的 TrackingProfileSerializer 使您能够获得配置文件的 XML 文本，这样，您就能将其传递到存储过程。
如果您没有为您的工作流类型指定跟踪文件，SQL 跟踪服务将使用 UseDefaultProfile 设置以确定它是否应为跟踪侦听器提供默认的配置文件。默认配置文件可跟踪工作流的所有状态事件和所有活动。它还包括匹配位置，以跟踪所提交的任何用户跟踪事件。如果您不需要此默认行为，当配置 SQL 跟踪服务时，则需要将 UseDefaultProfile 属性设置为 False。只有指定了配置文件的那些工作流类型才被跟踪。
为了确保跟踪服务是最新的，跟踪侦听器会定期询问各跟踪服务所收到的配置文件。为了避免重复加载或创建跟踪配置文件，跟踪服务可以实现 IProfileNotification 接口。为此定义了两种事件：ProfileUpdated 和 ProfileRemoved。当跟踪服务实现此接口时，跟踪侦听器不会查询更新配置文件信息，除非发生这些事件之一。为了支持此模型，SQL Server 跟踪服务会定期查询数据库（默认情况下，每 60 秒查询一次）以确定工作类型的跟踪配置文件是否已被更新或删除。您可以配置服务查询更新的频率，方法是将 ProfileChangeCheckInterval 属性设置为表示轮询之间微秒数的值。
由于在运行环境中，跟踪数据可以迅速累积，SQL 跟踪服务支持数据划分。您可以通过配置来按天、周、月或年来划分数据，服务将会为各时间段创建跟踪表。另外，您可以控制是按需移动数据（这样就可以为其预定停机时间），还是自动移动数据（当工作流完成时）。为了配置此设置，您要将 SQL Server 跟踪服务的 PartitionOnCompletion 属性设置为“true”，以指明各工作流完成时应被移动到相应的跟踪分区。为了对数据进行手动分区，您可以调用跟踪数据库中的 PartitionCompletedWorkflowInstances 存储过程。

查询跟踪数据
当您使用 SQL 跟踪服务收集数据时，数据被存储在 SQL Server 中，这意味着您可以使用传统的报告工具查看数据和进行分析。但在某些情形下，您需要查询应用程序中的工作流数据。您不必编写 SQL 查询和确定数据库中的正确关系，Windows Workflow Foundation 包含了跟踪查询编程接口，使您能够为工作流实例搜索跟踪信息。该信息作为类返回，提供了对所有跟踪的事件和您的跟踪配置文件指定的数据的访问。
SqlTrackingQuery 类使您既可以使用工作流的实例 ID 来尝试加载特定工作流实例的跟踪数据，也可以使用离散参数集来查询工作流列表。当加载特定实例时，您使用 TryGetWorkflow 方法，该方法返回指明请求是否成功的布尔值。要查询多个工作流，请使用 GetWorkflows 方法，该方法需要一个 SqlTrackingQueryOptions 实例。
查询选项使您能够定义在跟踪数据库中搜索工作流时要使用的参数。最简单的选项包括最小和最大日期值以及工作流类型和状态。例如，您可以配置选项以搜索所有与您的工作流类型匹配的工作流，工作流具有 Completed 状态，日期位于当前日期和一周前的日期之间。这使您能够检索关于工作流类型和生成方式的目标信息。
我已经介绍了让您指明所关注的失败条件的跟踪配置文件。使用图 4 显示的代码，您可以在数据库中查询所有终止工作流的实例，并输出异常详细信息。请注意异常详细信息被作为跟踪的终止事件的事件参数包含在跟踪信息中。
您还可以根据提取的值进行搜索。例如，如果您配置了跟踪配置文件以提取 SendEmail 活动的 To 地址，则可以编写查询以返回工作流实例，其中 To 地址与确定的值（如特定的员工或合作伙伴）相匹配。以下代码是使用 SqlTrackingQueryOptions 中的 TrackingDataItemValue 项根据提取的值优化对特定项的搜索的示例：SqlTrackingQueryOptions options = new SqlTrackingQueryOptions();TrackingDataItemValue item = new TrackingDataItemValue("sendEmail1", "To", "highpriority@example.com");options.TrackingDataItems.Add(item);SqlTrackingQuery query = new SqlTrackingQuery(connectionString);IList workflows =query.GetWorkflows(options);
 
如果选择直接查询 SQL Server 数据库以进行报告或执行其他操作，则应当使用在表中定义的视图而不直接使用表。通常，这是一个不错的做法，当视图要包含来自所有已创建的跟踪分区的数据时，尤为重要。通过使用视图，不再需要自己合并所有这些表中的数据。

自定义跟踪服务
跟踪数据直至其进入 SQL Server 数据库是一个重要用例，而且可能是最常见的用例，它不是使用跟踪信息的唯一情形。因为它是一项通用要求，Microsoft 决定将这项丰富的服务包含在 Windows Workflow Foundation 中。然而，这类具有广泛用途的服务必须尽可能通用。这意味着在许多情况下，它可能不适合。在这种情况下，您可以创建自定义跟踪服务。
在工作流解决方案中有许多使用自定义跟踪服务可满足的要求。在此，我将讨论创建您自己的跟踪服务的基本知识，并提供一些符合通用要求的自定义服务的示例。需要记住的重要一点是跟踪是您对工作流的监控。一旦理解了借助跟踪配置文件配置跟踪服务的方式，就可以获得所需的结果，接下来就是自定义的服务应如何使用或表示跟踪的信息。
为了创建自定义跟踪服务，您需要完成两件事情。首先，要确定如何为您的服务创建跟踪配置文件。某些情况下，在所有工作流类型中，配置文件都可能是静态的和不变的。在这种情况下，您可以在代码中创建配置文件，当需要配置文件时，只需将其返回至运行库即可。然而，如果您需要跟踪服务支持多个配置文件或不同版本的配置文件，则需要一种存储该信息和从您的跟踪服务中检索该信息的方法。
接下来，您要实现两个提供您的服务的运行时行为的类：跟踪服务和跟踪通道。该跟踪服务类作为工作流运行时服务，它是主机应用程序的直接接口和与您的跟踪服务交互的运行库。您要创建该类的实例并使用代码或配置将其添加到工作流运行库中，与任何其他服务一样。
该跟踪服务类有以下两种主要功能：为跟踪侦听器提供跟踪配置文件，并提供侦听器可向其写入数据的跟踪通道。跟踪通道是您实现的用于接收和处理跟踪数据的类。它可以在存储区域（如 SQL Server 或 Windows 事件日志）之外写入该数据；可以为操作引发事件，如 Windows Management Instrumentation (WMI) 事件；还可以将数据发送回跟踪服务以将其保存在内存中并使其可供主机应用程序使用。当然，还有其他一些选项，您使用数据的方式将取决于您的需求和要求。您的自定义跟踪服务将按它们所使用的跟踪配置文件以及它们处理所接收的数据的方式加以区分。
因为具有以下两种简单方法，所以跟踪通道是最方便的起点：Send 和 InstanceCompletedOrTerminated。您的跟踪服务应为各工作流实例提供跟踪通道，为各请求提供跟踪通道的唯一实例是一种通用做法。通常，您要提供将 TrackingParameters 作为参数的构造函数，在实现其他方法时您可能需要此信息。TrackingParameters 类有关于要被跟踪的工作流实例（如实例 ID）、对根活动定义的访问的信息，以及关于父活动和工作流调用（如果该工作流不是从其他工作流中调用的）的信息。
InstanceCompletedOrTerminated 方法使您能够在活动完成时跟踪服务以获得通知，这样它就能清除与跟踪工作流相关的所有资源。通常，这需要按照 TrackingParameters 提供的内容访问工作流实例 ID，因为 InstanceCompletedOrTerminated 方法不带任何参数。
可为跟踪配置文件中所请求的每一跟踪记录调用您的跟踪通道的 Send 方法。与配置文件类似，也存在工作流、活动和由基类 TrackingRecord 派生的用户跟踪记录。在 Send 方法中，您要检查已提交了哪种类型的跟踪记录，然后进行相应地处理。例如，如果您知道您的跟踪配置文件没有指明所关注的用户跟踪事件，您就无需在您的跟踪通道中处理用户跟踪记录。
跟踪服务类本身负责管理跟踪配置文件。跟踪服务基类提供了几种检索配置文件的方法，使您能够根据工作流类型和工作流实例管理配置文件。这意味着您的服务可以返回相应的配置文件，范围从对所有工作流都相同的配置文件到对各工作流实例是唯一的配置文件。
对于 GetProfile 方法，存在两种重载。一种重载需要实例 ID，另一种重载需要类型和配置文件版本号。另外，TryGetProfile 也需要类型信息。在所有这些情况下，您的自定义跟踪服务的工作就是返回与类型或实例相适应的跟踪配置文件。
此外，还存在一种称为 TryReloadProfile 的方法，如果存在更新的配置文件，该方法将进行运行时调用以获得该文件。为了确保及时更新，跟踪侦听器要定期向您的跟踪服务询问以确定是否使用更新的配置文件。无需在每次需要时创建新的配置文件或查找配置文件，您可以在您的自定义跟踪服务中实现 IProfileNotification 接口。IProfileNotifcation 接口包括以下两种事件：ProfileUpdated 和 ProfileRemoved。当您在您的跟踪服务中实现此接口时，跟踪侦听器不再进行更新轮询。取而代之的是，在该接口的事件发生过程中它要等待所有更新的通知。
在本专栏的代码下载中包含了几个示例跟踪服务。当前状态示例使用跟踪以获得状态机工作流的当前状态，并使其可供主机应用程序使用。该服务的跟踪配置文件包含针对 State 活动执行状态的活动跟踪点。当收到活动跟踪记录时，跟踪通道会使用当前状态名更新跟踪服务类中的词典。该示例是一个服务示例，对于所有工作流都有相同配置文件，并将数据写回服务以便由主机应用程序查询。
包含在代码下载中的另一个示例跟踪服务旨在解决 Windows Workflow Foundation 中开发人员常见的一种问题。考虑到工作流执行以及与主机应用程序分离方式的性质，获得对运行工作流的引用和提取属性值不是一个简单过程。这是一个常见要求，特别是在 ASP.NET 情形中。一旦 ManualWorkflowScheduler 完成在工作流中执行相应步骤，可能需要使用工作流的属性值更新用户接口。
使用 CallExternalMethod 活动可传递工作流中的信息，但这并不总是一种理想的解决方案，而且在大型项目中被证明是难以承受的。工作流属性跟踪服务示例使用跟踪来解决此问题。在此跟踪服务中，对于每种工作流类型，返回的配置文件是不同的，以便反映工作流中的不同属性。使用反射构建工作流数据跟踪提取集合，并将它们添加到活动跟踪点。跟踪的位置位于各活动的 Closed 事件中。因此，当各活动结束后，来自工作流实例的属性值将被提取，并发送到跟踪通道。通道将更新服务中的词典，使这些值可供主机应用程序使用。
这是两个相当简单的自定义跟踪服务的示例，但二者均是针对开发人员常见情形，提供了简单、可重复使用的实现，并充分利用了现有跟踪基础结构。如果缺乏构建基础，这些挑战将会更大，需要更多的自定义代码，而解决方案也可能不一致。
正如您所看到的，Windows Workflow Foundation 中的跟踪服务非常灵活，有助于应对大量不同的业务要求。跟踪对于工作流的可视性至关重要，自定义跟踪服务是您在应用程序中充分发挥这种可视性的“利器”。

将您想询问的问题和提出的意见发送至：mmnet30@microsoft.com mmnet30@microsoft.com.
NEW:Explore the sample code online! - or - 代码下载位置:Foundations2007_03.exe (178KB)
Matt Milner是一位独立的软件顾问和 PluralSigh 的教师，专门从事 关于 Microsoft 技术（包括 .NET、Web 服务、Windows Workflow Foundation、Windows Communication Foundation 和 BizTalk Server）的讲授。Matt 与其妻子 Kristen 和两个孩子居住在明尼苏达。您可通过 Matt 在pluralsight.com/blogs/matt 开设的博客与他联系。
 摘自 March 2007 期刊 MSDN Magazine.