Windows Azure BizTalk 服务 (WABS) 的 WorkflowChannel

Roman Kiss

5.00/5 (7投票s)

2014 年 1 月 25 日

CPOL

22分钟阅读

33917

188

本文描述了如何通过工作流（VETER + WORKFLOW 模式）扩展 Windows Azure BizTalk 服务桥接管道以实现消息中介。

下载源代码

特点

WABS 桥接托管
VETER + WORKFLOW = VETEW 模式
松散耦合模式
基于 WCF 自定义通道
工作流定义的封装
工作流定义 (xaml) 存储在 Azure Blob 中
使用 blob 元数据进行工作流配置
通过工作流参数进行消息交换模式
对 VETER 完全透明的模式
允许使用工作流自定义活动

微软最近发布了 Windows Azure BizTalk 服务 (WABS) 在 Windows Azure 平台上的全面可用性 (GA)。WABS 通过在多租户云环境中称为 VETER（验证-扩充-转换-扩充-路由）的预构建消息管道模式中进行声明式编程，实现业务集成。源实体接收到的消息通过 VETER 模式流向目标实体，例如 Windows Azure Service Bus Relay 端点、Service Bus 队列/主题、Azure Blob、FTP/SFTP 端点以及通过 WCF 堆栈的外部端点。

WABS 代表源和目标端点之间的桥梁，其中入站消息只能定向到众多目标端点中的一个。消息管道在内存中启动，所有状态仅持久化在内存和/或消息中，因此 WABS 桥接是无状态场景，消息生命周期过程尽可能短。换句话说，WABS 桥接的职责是在消息生命周期内以非常短的时间内中介并传递消息到目标。在桥接崩溃、错误等情况下，错误消息会连同详细原因返回给调用者。

对于这种模式，WABS 桥接通过 VETER 模式进行统一和简化。这种简单性允许隐藏桥接的复杂性和技术集成堆栈，同时更侧重于业务场景，例如消息验证和中介。WABS 内置的 VETER 模式使 WABS 桥接能够在预处理和后处理业务集成堆栈中使用，其中集中处理部分持有业务组合的状态。任何技术都可以用于业务集中部分，例如 BizTalk Server、IBM WebSphere ESB、Oracle ESB 等，或自定义构建的复合应用程序。

基本上，WABS 是一个云 Web 角色服务，具有预构建的企业应用程序集成 (EAI) 场景的样板堆栈，可在安全、自动伸缩、专用和每个租户环境中运行。除此之外，桥接样板还内置了监控和跟踪功能。VETER 桥接模式具有预构建的扩展点，例如 On Enter Inspector 和 On Exit Inspector，其中状态可以通过自定义代码进行扩展。此扩展是强制性的，必须在设计时考虑，换句话说，它必须嵌入到桥接中。

另一方面，WABS 桥接模式允许使用松散耦合、完全透明和声明式的方式（例如使用 WCF ExternalServiceEndpoint）来扩展消息管道。这是一个用于出站消息的目标（客户端）代理 WCF 通道。在桥接模式中使用此通道，出站消息被转发到目标端点，该端点可以被视为远程中介器、业务处理器等。ExternalServiceEndpoint 基于 WCF 堆栈，因此我们在 WABS 桥接模式中有一个额外的扩展点。

请注意，ExternalServiceEndpoint 仅用于出站消息。换句话说，此通道仅用于客户端（代理），因此通道堆栈中不需要有任何侦听器。从托管的角度来看，WABS 代表 Destination 代理的托管过程。这是 Windows Azure BizTalk 服务的一个强大功能。

现在，回到工作流的可扩展 WABS 桥接模式的概念点，其中 EnternalServiceEndpoint 允许为出站消息插入 WCF 自定义通道。

使用用于工作流调用器的特殊 WCF 自定义通道，出站消息可以转发到工作流骨架，由 xaml 定义声明并在 WABS 托管进程中执行。

本文描述了此过程。它向您展示了 WABS 桥接如何在消息管道（例如工作流）中轻松扩展此功能，其中消息可以通过工作流编排功能以完全透明和松散解耦的方式进行中介。在 WABS 桥接中使用 WCF 自定义 WorkflowChannel 为您提供了一种新模式，例如 VETER + WORKFLOW = VETEW 模式。

我强烈建议阅读我以前的文章，例如用于路由服务的 WorkflowChannel（详细的 WorkflowChannel 描述）、 Azure 上的 RoutingService 和 Azure 虚拟桥接。最后一篇文章在概念上与 WABS 桥接非常接近，其中 WCF Routing Service 托管在 Azure Web 角色中。

在 Visual Studio Bridge Designer 中，没有变化，正如您稍后将看到的，只需要为特定目标配置配置文件以使用自定义 WorkflowChannel。

下图显示了 3 个不同桥接的消息行程示例，其中出站消息被路由到 wcf 自定义 WorkflowChannel。

上图（消息行程）显示出站消息已发送到外部服务终结点，因此消息应流向外部服务，并在 WABS 运行时域之外执行。

但是，请等一下。在我们没有看到特定外部服务终结点的每个目标配置文件之前，这不一定是真的，因为插入了 WCF 自定义 WorkflowChannel。出站消息不会退出 WABS 运行时域，因此出站消息将在 WABS 托管进程中执行，但在工作流编排下，而不是在 VETER 模式下。

这是一个概念性扩展，从抽象的角度来看，我可以将此模式称为 VETEW，其中 R-outer 被 W-orkflow 替换。请注意，W 代表内存中的工作流，其生命周期由 WABS 生命周期完成。换句话说，这是一个在 WABS 桥接中运行的非持久化工作流。

太棒了。让我们继续。下图显示了一个简单的直通桥接到 WorkflowChannel 的示例，其中出站消息用于发布者中介，例如将消息有效负载写入 Azure Blob 并通知 Service Bus Topic

上图显示了额外的注释，表明目标连接正在调用单向外部服务终结点上的自定义通道 (net.wf://repository/bridges)。因此，此桥接 (Fire) 接收到的任何入站消息都会转发到自定义 WorkflowChannel (Publisher)。基本上，上图显示了一个没有完整 VETER 消息中介的基本模式，它是一个直通工作流桥接。

下图显示了 WABS Xml Request-Reply Bridge 中更强大的消息中介。入站消息可以在路由器实体（例如 Xml Request-Replay Bridge）中完全中介，然后其出站消息转发到自定义 WorkflowChannel。

在上述消息行程中，目标实体被命名为 WorkflowInvoker。原因在于，Router 收到的任何入站消息都可以调用特定的 xaml 工作流定义，正如您稍后将看到的。

现在是时候展示 WorkflowChannel 的自定义配置文件了：

如您所见，客户端终结点与自定义绑定的配置非常简单。客户端地址 net.wf:://repository/bridges 声明了一个自定义绑定，其中包含 net.wf 方案和存储在存储库（Azure Blob）中 bridges 容器下的 xaml 资源。对存储库帐户的授权访问在绑定部分中声明。

实际上，这非常简单，只需 1-2-3 步，例如将自定义 WorkflowChannel 程序集添加到 bindingElementExtension，然后添加 customBinding，最后为 WorkflowChannel 配置客户端终结点。基本上，此配置可用于您的桥接中所有 xaml 工作流定义存储在同一位置的任何 WorkflowChannels。

WorkflowChannel 背后是存储在存储库中的 xaml 工作流定义，WorkflowChannel 负责从存储中加载和执行特定的 xaml 定义。

下图显示了一个非常简单的工作流示例，例如消息 LoopBack，其中传入消息被传回给调用者。

LoopBack 工作流存储在 bridges 容器中，并且只有一个用于消息回环的 Assign 活动。请注意，_inMessage 和 _outMessage 是用于与桥接进行消息集成的 Workflow 强制参数，您稍后将更详细地看到。请注意，此 LoopBack 工作流对于在 VETER 模式中创建自定义消息中介原语非常有用，其中转换是提供复杂消息中介以封装业务模型的地方。此外，LoopBack 工作流也可以参与业务中介。

让我们看看下图以显示 VETER 桥接和工作流定义之间的位置

上图是 VETEW 模式的绝佳概念图。VETER 桥接部分代表工作流定义的预/后消息处理。xaml 工作流资源，称为工作流桥接定义，存储在 Azure Blob 存储 (repository) 中。我们可以一次部署 WABS 桥接，用于面向业务的工作流定义库，并调用它们以根据某些规则序列组合业务模型。

当然，WABS 桥接可以构建得更复杂，例如使用过滤，如下图所示

上述桥接显示了将消息路由到两个自定义目标，例如 WorkflowChannels。根据路由操作，消息可以路由到 Weather 或 LoopBack 工作流定义。

等一下；自定义 WorkflowChannel 如何知道要使用哪个工作流定义？

嗯，正如您可能从我以前的文章中了解到的，xaml 工作流定义的名称已通过地址 uri 查询字符串传递，例如：

不幸的是，当前版本的 WABS 不允许通过地址 Uri 传递查询字符串，因此有必要修改用于路由服务的原始 WorkflowChannel 的实现，以在地址 Uri 没有查询字符串的情况下接受消息中的自定义标头。我希望微软 WABS 团队在下一版本中允许此功能。

无论如何，目前，消息转发到 WorkflowChannel 必须具有简单的字符串类型自定义标头查询，请参阅桥接消息发送器程序的以下屏幕截图

上面的示例显示了如何在路由器桥接的后面调用任何工作流定义。请求消息具有用于调用 xaml 工作流的直接自定义标头查询，在此示例中它是 LoopBack 工作流。正如您稍后将看到的，查询标头还可以指定容器的名称等。

太棒了，那么在运行时根据消息有效负载等从存储库调用工作流定义呢？

基本上，我们可以使用相同的原理来添加和修改消息中的标头。以下示例显示了如何将自定义标头添加到出站消息中

在上面的示例中，标头值在 Expression TextBox 中显式创建。请注意，现有标头的值将被覆盖。

我希望到目前为止您已经了解了桥接 VETEW 模式中 W 的含义。

正如我前面提到的，WABS 桥接是一个无状态桥接，用于为中介原语、转换、扩充等进行预处理和/或后处理消息。将 W 添加到 VETER 模式中，我们可以使 WABS 桥接能够分解业务模型，这将需要消息拆分器、消息加速器、业务上下文流等，而无需为中小型解决方案使用更复杂（且昂贵）的业务服务器。

下图显示了我以前的文章使用 Azure 租约 Blob 中的一个示例，其中业务组合是使用基于租约 Blob 的 EventStream 完成的。

如您所见，上图显示了基于 EventStream 的业务模型组合，其中每个 WABS 桥接都专门将 Event 发布到 EventStream，因此每个发布者都可以看到用于消息加速、触发事件等的业务上下文状态。

在上述介绍部分，我提到了我以前的一些文章。请允许我再添加一篇文章（ WF4 用于消息中介的自定义活动），它将帮助您在工作流中进行消息中介。本文将帮助您以序列和/或流程图方式构建基于契约优先、拆分器、分析器等自定义消息中介器、调用器。

好的，让我们继续概念和设计。我假设您对 Windows Azure 平台（BizTalk 服务、Azure Blob、服务总线等）有实际操作知识。

概念与设计

将工作流添加到 WABS 桥接的概念基于消息行程中用于通用目标 WCF 外部服务终结点的出站 WCF 自定义通道。将 WCF 自定义工作流通道插入到目标代理中，可以实现 VETER 和工作流模式之间的消息交换模式 - MEP（单向或双向），以同步或异步方式。

下图显示了简单的单向消息模式示例

来自 VETER 的出站消息被转发到为自定义 WorkflowChannel 配置的 One-Way External Service Endpoint，请参阅以下配置

消息流入工作流编排。如您在上述消息行程中看到的，工作流中的消息可以在自定义“第二个”VETER 模式中处理，该模式由序列和/或流程图骨架中的工作流活动编排。

WorkflowChannel 负责根据位于地址 Uri 或消息标头中的查询字符串加载和调用 xaml 工作流定义。源存储库可以配置为默认位置，例如 Azure Blob 中的容器（本文仅支持此功能）或项目中的文件夹，例如：Artifacts。

查询字符串至少包含一个名称-值对，例如 xaml 工作流定义的名称。此外，这是配置 xaml 工作流定义加载的位置，特别是通过请求。以下是查询字符串的几个示例

xaml=LoopBack
xaml=LoopBack&repository=bridges
xaml=LoopBack&repository=bridges&settings=bridges/Settings/MySettings 
xaml=LoopBack&repository=bridges&ns=mynamespace&
     st=2014-01-18T20%3A00%3A51Z&se=2014-01-18T21%3A00%3A51Z&sr=c&sp=r&sig=yFriLn2xiJ...

请注意，查询字符串的最后一个示例显示了带有 SAS 参数的 blob 定址示例。

将 xaml 工作流定义存储在 Azure Blob 中是默认和首选方式。主要原因是 blob 元数据，可以在其中存储工作流配置。下图显示了 VETER 和工作流之间的数据集成

如您所见，出站 VETER 消息通过 _inMessage 流向工作流，并通过 _outMessage 参数返回。还有第三个强制工作流参数，即 _metadata。WorkflowChannel 填充了输入参数，例如 _inMessage 和 _metadata 参数，并根据 MEP 方式，它使用 _outMessage 参数作为回复消息。此外，如果 xaml 工作流资源是 Azure Blob 资源，则所有 blob 的元数据都将复制到 _metadata 参数。使用 blob 元数据进行工作流配置是一个很棒的功能，它使我们能够分解业务模型中的工作流变量，并在多个工作流（称为企业变量）之间共享它们。这是自定义 WorkflowChannel 的高级功能，请参阅我的文章 Azure 虚拟桥接中有关此场景的更多详细信息。

本文包含了 WCF 自定义 WorkflowChannel 的完整源代码，并且根据需求（例如，来自特定文件夹/数据库/blob 等的 xaml 定义及其来自其他可共享（集中式）数据库/blob/文件夹等元数据）修改 xaml 资源的加载非常容易。

自定义消息头 - 查询

自定义消息头 query 是一个字符串类型的限定头，用于声明 xaml 工作流定义，例如名称、位置等。每个转发到 WorkflowChannel Endpoint 的出站消息都必须在消息中包含此头。

以下代码片段显示了限定头 query 的示例

 <query xmlns="urn:rkiss/2014/wf">xaml=Weather</query>

头部也可以在运行时在 VETER 模式或 Route Action 中声明性地创建。

以下屏幕截图显示了在邮政编码 > 90000 的情况下将消息路由到 Weather 工作流定义的示例

实现

WCF 自定义工作流通道具有非常简单的模型，仅支持 IOutputChannel 和 IRequestChannel 接口

所有与工作流目标相关的自定义逻辑都封装在自定义 WfHelper 静态类中，请参阅以下代码片段

public IAsyncResult BeginRequest(Message message, TimeSpan timeout, AsyncCallback callback, object state)
{
  base.ThrowIfDisposedOrNotOpen();
  base.RemoteAddress.ApplyTo(message);

  // load and create instance of workflow
  WorkflowApplication wfa = 
        WfHelper.CreateWorkflowApplication(message, repositorySettingName, trackingParticipent);

  // run workflow asynchronously
  return wfa.BeginRun(timeout, callback, state);
}   
public Message EndRequest(IAsyncResult result)
{
  return WfHelper.EndRun(result);
}

此时，我想向您推荐我之前的文章，其中详细描述了 WorkflowChannel 的设计和实现。对 WABS 桥接的原始 WorkflowChannel 进行了一些更改，例如对程序集进行签名并在 GetQuery 方法中添加查询头逻辑

// query from header
if (string.IsNullOrEmpty(query))
{
    int index = message.Headers.FindHeader("query", "urn:rkiss/2014/wf");
    if (index >= 0)
        query = message.Headers.GetHeader<string>(index);
}

让我们花更多时间讨论 WorfklowChannel 在 WABS 桥接中的使用和测试。

用法与测试

首先，以下是先决条件（基于我的开发环境）

Visual Studio 2012 Update 4
安装适用于 .NET 2.2 的 Windows Azure SDK (Visual Studio 2012)
Windows Azure Platform 账户
WABS 命名空间
Http/s Internet 连接
下载本文的软件包
Azure 存储浏览器
安装 Windows Azure BizTalk Service Explorer
了解和使用 Windows Azure 平台（Blobs、WABS、服务总线等）的经验

在本节中，我将逐步向您展示 WorkflowChannel 在 WABS 桥接中的使用。

步骤 1. 从本文下载包

以下屏幕截图显示了本文中包含的 BizTalkServiceVirtualBridge 解决方案包

如您所见，上述解决方案包含 2 个项目，例如 WABS 项目 - BizTalkServiceVirtualBridge 和 WokflowChannel 库项目。基本上，要在您的下一个 WABS 解决方案中使用 WorkflowChannel，只需要 WorkflowChannel.dll 程序集。因此，上述 WABS 包仅用于我们测试 WCF 自定义 WorkflowChannel 的目的。如您所见，有一个 Tools 文件夹，其中包含用于我们测试的一些程序集。还有一件事，Artifacts 文件夹有两个 xamlx 资源用于我们的测试，例如 LoopBack 和 Weather。这些工作流仅用于测试目的。

在步骤 2 之前不要编译此解决方案，您必须使用您的帐户更新解决方案。

步骤 2. 修改您的帐户的解决方案。

必须修改解决方案以适应您的帐户，例如 BizTalk Service URL 属性以及所有以下目标终结点的配置文件

如我之前提到的，WorkflowChannel 使用 Azure Blob 存储作为 xaml 工作流定义的存储库。为了测试目的，此解决方案使用（如上图配置所示）两个容器，一个用于 assemblies，另一个用于 bridges，用于 xaml 资源。请在您的 blob 存储中创建这些私有容器。

完成这些更改后，解决方案即可部署到您的 WABS 端点。

再提供一些帮助，如果您在构建此解决方案时遇到问题，请关闭 Visual Studio 并再次重新打开，但只使用构建功能。我相信 Visual Studio 2012 在持有程序集引用时存在一个 bug。这是我的经验，我希望即将发布的适用于 Visual Studio 2013 的 WABS 能够解决此问题。

步骤 3. 部署

要从 VS2012 部署 WABS 解决方案，屏幕上将显示以下对话框提示

部署终结点将显示您的 WABS 命名空间，您必须填写 AcsNamespace 和 SharedSecret 属性。之后，您可以在 Output 面板中查看部署过程，我希望没有任何错误。

如果部署成功，您应该在服务器资源管理器中看到此解决方案在您的 WABS 命名空间中

Windows Azure BizTalk Service Explorer 是一个很棒的工具。它允许刷新、重新启动、更新等您的 WABS。此外，您还可以看到上传的程序集列表。上图显示了我们下一步测试所需的这些程序集。请注意，缺少的程序集可以手动上传或添加到解决方案引用中，并将 Copy Local 属性设置为 True。顺便说一句，此标志对于控制程序集上传很有用，当桥接行程发生变化时，它将加快重新部署过程。

现在我们可以专注于工作流部分。

在我们继续之前，让我们对我们部署的 WABS 进行预测试，这将表明我们是否走在通往工作流的正确道路上。

让我们调用一些工作流，此时我们可以调用任何名称，因为我们的 blob 存储是空的。

步骤 4. 调用不存在的工作流

为了方便向 WABS 发送消息，我们可以使用解决方案文件夹 Tool 中包含的我的“脏工具”。

请启动 MessageSender 程序并为您的 WABS 命名空间填充您的帐户值。将查询字符串值设置为 xaml=ABCD。之后，按下发送按钮。您应该从您的 WABS 收到一条响应消息，指示以下内容

这是一个好兆头，表明您的 WABS 应该在以下步骤中正常工作。

步骤 5. 调用现有工作流

在此步骤中，我们将向您的 Azure 存储上传 blob。请注意，您需要为 WABS 和 Blob 存储使用您自己的信用额度。

任何第三方 Azure 存储资源管理器都可以，但在此步骤中，让我们使用我的朋友 David Pallmann 的非常流行且免费的 Azure 存储资源管理器。

请将以下 xaml 资源上传到您的 Blob 存储容器 bridges

Artifacts/LoopBack.xamlx
Artifacts/Weather.xamlx

进行以下更改

删除 blob 名称中的扩展名 .xamlx（这是一个选项，但在这种情况下，我们必须在查询字符串中使用 xaml 资源的完整名称）
使用内容类型 application/xaml+xm（这是与 text/plain 类型相反的选项，我们可以将资源重定向到另一个 blob）
为 Weather blob 添加以下元数据

请将以下程序集上传到您的 Blob 存储容器 assemblies

工具/MessageMediationActivityLibrary.dll

进行以下更改

删除 blob 名称中的扩展名 .dll

如果您的工作流中使用了自定义活动，则必须将其程序集上传到此容器并重新启动 WABS，以确保此程序集将加载到 WABS 桥接进程（web 角色）中。

就这样。现在是时候进行一些测试了。让我们从一些非常简单的开始，只使用 .Net 4.5 中的 Microsoft Workflow Activities，一些简单的工作流，例如 LoopBack。

步骤 6. 测试 LoopBack 工作流（路由器）

此测试使用路由器 WABS 桥接。其地址是 https://your_namespace.biztalk.windows.net/default/Router

任何查询字符串都将转发到具有 WCF 自定义 WorkflowChannel 的 WorkflowInvoker 目标。

使用 MessageSender 程序发送带有查询头的请求消息

<query xmlns="urn:rkiss/2014/wf">xaml=LoopBack</query>

以下屏幕截图显示了来自 LoopBack WABS 桥接的响应

您可以在请求消息有效负载中使用不同的邮政编码来查看响应消息中的更改。响应面板显示了 TrackingID。此 id 可用于通过 WABS Explorer 或 Azure 门户跟踪通过路由器桥接的消息。

请注意，此路由器桥接可用于调用存储在 bridges 容器中的任何 xaml 工作流定义。我相信您也会使用它来调用您的工作流。

步骤 6. 测试 Weather 工作流 (WeatherBridge)

此测试将演示 VETER 桥接从 Azure Blob 存储中选择两个不同 xaml 工作流定义的能力。Weather 工作流是一个非常直接的工作流，它使用自定义活动 CreateMessage（来自我推荐的文章 WF4 消息中介自定义活动）来创建请求和响应消息，用于/来自对 Weather 公共服务的调用。在此测试中，我们正在测试从 assemblies 容器加载自定义程序集的能力。

下图显示了具有为 WorkflowChannel 配置的两个目标的 WeatherBridge

请注意，入站消息不需要查询头，因为此头是根据过滤器添加到出站消息中的。

如您所见，根据有效负载值 ZIP，消息会路由到正确的目标。过滤器有 3 组。第三组是当 ZIP = 90000 时。在这种情况下，调用者将收到错误消息。

以下屏幕截图显示了这些情况

LoopBack 工作流

Weather 工作流

如您所见，最后一个响应消息中有一个在天气元数据中配置的自定义头。您可以在测试期间使用此配置，而无需重新部署桥接或更新 blob 内容。

测试到此结束。我希望这两个测试在您的 WABS 部署中都成功了。此外，演示向您展示了使用 WorkflowChannel 的 VETEW 模式的功能。

高级工具

我的文章 Azure 上的 RoutingService 描述了对 Azure 存储资源管理器的一个小修改，该修改将程序与 blob 内容关联起来。下图显示了此用户界面扩展

单击 Edit 链接，将启动重新托管的 WorkflowDesignerTester 以编辑 xaml 定义。xaml 中的更改可以保存到 blob 中。请注意，最新版本的 WorkflowDesignerTester 程序可以在解决方案 Tools 文件夹中找到。

结论

本文描述了我们如何轻松地通过工作流 (WF) 功能扩展 Windows Azure BizTalk 服务 (WABS) 中预构建的 VETER 模式。在目标终结点中使用 WCF 自定义 WorkflowChannel，出站 VETER 消息管道在工作流的序列和/或流程图骨架中继续。本文描述了一种新的概念模式，例如 VETER + WORKFLOW = VETEW。希望您喜欢它。