导出 (0) 打印
全部展开

桥的用途和阶段

更新时间: 2013年11月

BizTalk 服务提供两种类型的桥 – 传递桥和 XML 桥接,而 XML 桥接又包括XML 单向桥接和 XML“请求-答复”桥接。本部分提供有关这些桥接的用途和阶段的信息。

XML 桥接可用于调解和弥补通过交换 XML 消息相互通信的两个或多个不同系统之间的不匹配情况。XML 桥接可能与消息流中的其他 Service Bus 实体结合使用,提供多种调解模式和方案,如下所述:

  • 消息验证:XML 桥接支持根据 XSD 架构验证传入的 XML 消息。通不过验证的消息将被拒绝。

  • 消息扩展和提取:XML 桥接支持通过查找其他数据源中的数据进行消息扩展。通常,当消息可能需要上下文数据出现在消息边界以外(配置存储、外部服务等组件中通常存在这种情况)时,此功能将十分有用。

    XML 桥接还允许你从 XML 消息中提取属性,而这些属性最终可用于路由。例如,在采购订单消息中,可以标记 Quantity 元素。然后,可以根据订购数量值路由该消息。

  • 消息转换:XML 桥接支持将消息正文从一种 XML 结构转换成另一种 XML 结构。在将多个消息映射成单个消息的情况下,还可以使用这项 XML 桥接功能来“规范化”消息。例如,桥接可能需要接受来自不同客户端的、采用不同架构的采购订单,但是,这些架构最终将转换成组织所需的一种采购订单架构。

  • 位置虚拟化:XML 桥接提供后端服务的基元位置虚拟化。客户端向云中公开的 XML 桥接终结点而不是实际服务(可能在云中或本地)发送消息。然后,桥将根据路由规则向后端服务路由消息。

  • 自定义处理:桥接提供了用于包含自定义代码的选项,可让你纳入现成的桥接配置中未包含的处理任务。

本部分提供有关 XML 桥接的各个阶段的信息。请注意,每个阶段是可选的,你可以将它打开关闭

XML 桥接中的第一个阶段是验证阶段。此阶段根据指定的架构对 XML 消息进行 XSD 验证。用于验证的架构是在配置桥接的过程中指定的。单个 XML 桥接可以接收和处理采用不同架构的 XML 消息。在验证阶段,将会根据传入的消息选择并使用相应的架构进行验证。根据架构验证消息后,验证阶段将升级消息中的 X_PIPELINE_MESSAGETYPE 属性。该属性的值是架构目标命名空间与根节点名称的组合,例如 http://IntegrationServices.Schema#RootNode。如果消息验证由于找不到匹配的架构或者匹配结果不确定(存在多个匹配的架构)而失败,则会引发异常。

有关如何配置验证阶段的说明,请参阅To configure the Validate stage

扩展阶段,可以通过创建属性来扩展消息。这些属性的值可从传入消息标头、系统升级的属性、传入消息正文中的元素或特性派生,或者通过对外部数据源(例如 Microsoft Azure SQL Database 表)执行查找来派生。然后,可以使用这些属性将消息路由到目标终结点和协议桥。

 

操作 说明

标头到属性的分配

在此操作中,可以使用消息标头中的值并将其分配给某个属性。例如,可以从 SOAP 标头中提取操作,将该操作分配给某个属性,然后使用该属性来完成进一步的处理和/或路由。可以根据用于向桥发送消息的消息协议使用这些属性。支持的协议为 HTTP、SOAP、FTP 和 SFTP。以下属性适用于这些协议。

  • SOAP

    • Action

    • MessageId

    • ReplyTo

    • 收件人

    • 自定义 SOAP 标头

  • HTTP - 标准 HTTP 标头

  • FTP/SFTP

    • FileName

    • ServerAddress

    • 文件夹

有关如何配置标头到属性的分配的说明,请参阅To assign message header values to properties

使用系统升级的属性

默认情况下,BizTalk 服务将会升级消息中由桥处理的某些属性。这些属性也称为系统升级的属性。这些属性的值还可用于各种处理任务,例如决定路由目标,等等。可用的系统升级属性包括:

  • RequestId - 分配给消息的唯一请求 ID。

  • MessageReceivedTime - 指示桥终结点上收到消息的时间的时间戳。

  • SourceName - 源的名称,在桥要从中接收消息的桥配置图面中定义。

  • SourceType - 源的类型,在桥要从中接收消息的桥配置图面中使用。

有关如何使用系统升级的属性的说明,请参阅To use system-promoted properties

提取

扩展阶段的“提取”操作用于提取消息正文本身的特定元素或特性的值,以便在消息路由或执行进一步处理的过程中使用。

有关如何配置提取操作的说明,请参阅To extract values from a message body using xpath

查找

扩展阶段的“查找”操作用于通过查找和包含源中超出消息边界的数据来扩展消息。例如,某个网上零售店允许用户使用其本币下单,而处理订单的后端服务只使用一种货币(比如“美元”)来进行任何订单处理。在这种情况下,在将消息发送到后端服务之前,必须将订单价值的币种从本币转换为“美元”。这可以通过查找能够提供最新兑换率的其他服务来实现。

本发行版的扩展阶段仅支持从 Microsoft Azure SQL Database 中查找数据。换而言之,Microsoft Azure SQL Database 是当前发行版支持的唯一查找“提供程序”。有关查找提供程序的信息存储在 LookupProviderConfigurations.xml 中,该文件将添加到 BizTalk 服务项目中。可以在一个 .xml 文件中定义多个提供程序,这样,便可以在一个扩展阶段中,从多个 Microsoft Azure SQL Database 数据源查找数据。LookupProviderConfigurations.xml 文件中典型的提供程序定义如下所示:

<ArrayOfLookupProviderConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/WindowsAzureServiceBus/Bridge">
  <LookupProviderConfiguration i:type="SqlTableLookupProviderConfiguration">
    <ProviderName>...</ProviderName>
    <ConnectionString>...</ConnectionString>
    <QueryInColumnName>...</QueryInColumnName>
    <QueryOutColumnName>...</QueryOutColumnName>
    <TableName>...</TableName>
  </LookupProviderConfiguration>
</ArrayOfLookupProviderConfiguration>

在上述摘录中,可以看到 LookupProviderConfiguration 元素的 type 特性固定为 SqlTableLookupProviderConfiguration。这是因为,目前你只能在 Microsoft Azure SQL Database 中查找表。

在从 Microsoft Azure SQL Database 中查找数据时,还要注意几个问题。

  • 只能查找 Microsoft Azure SQL Database 表。

  • 应该使用键值对执行查找。

  • 查找必须只能生成一个值,该值将分配到消息中的属性。如果查找生成了多个值,则会将其中的第一个值分配给属性。

  • 可以从多个数据源中查找某个值,也就是说,可以从多个 Microsoft Azure SQL Database 表或多个 Microsoft Azure SQL Database 执行查找。

有关如何配置查找操作的说明,请参阅To lookup an external data source

有关提供程序的信息存储在 LookupProviderConfigurations.xml 中,而有关要从标头分配到消息属性的值、要提取的值及要查找的值的信息存储在桥配置文件中。当你构建 BizTalk 服务项目时,LookupProviderConfigurations.xml 也会在桥配置文件中滚动更新。当你部署 BizTalk 服务项目时,正是将此桥配置文件部署到 Service Bus 上。

在扩展阶段,可以创建属性并向其分配值。但是,用户可能会提出这样的问题:这些属性有什么作用?这些属性如何简化我的任务?你可以通过两种方式利用这些属性:

  • 可以使用这些属性来设置筛选条件,以便将消息路由到不同的目标。有关如何实现此目的的说明,请参阅The Routing Condition

  • 可以使用这些属性来弥补消息发送方与消息接收方之间的协议不匹配情况。例如,某个传入 SOAP 消息包含自定义标头值。你想要以 HTTP 消息自定义标头的形式传递此值,因为消息接收方希望接收 REST 消息,并且无法识别 SOAP 消息格式。此时,你可以使用属性来实现此目的。首先,你可以将传入消息标头中的值分配到某个属性(比如 P1),然后,在向接收方发送该消息时,将 P1 的值分配给传出消息的消息标头。有关详细信息,请参阅Route and Reply Actions: Bridging Protocol Mismatch

在桥接配置中,你在扩展阶段定义的属性可在整个消息流中提供给桥接配置的每个阶段使用。换而言之,如果你在扩展阶段定义了一个属性,则你可以在转换阶段使用该属性,并且可将它用于任何映射操作。还可以在桥接配置边界以外使用扩展阶段定义的属性,不过需要注意几个问题。在深入了解属性生存期的详细信息之前,我们必须知道,属性值将存储为 Service Bus BrokeredMessage 类的属性。了解这个事实以后,让我们讨论属性在桥接配置外部的生存期。

  • 由于只有一个 Service Bus 队列或一个主题可以使用 BrokeredMessage 类型的消息,因此,队列和主题可以直接使用属性及其值(以键值对的形式提供)。此后,主题(举例而言)有可能会使用属性来执行进一步的处理和路由

  • 不能将属性及其值传递给单向/双向中继终结点或单向/双向外部服务终结点等其他桥接配置组件。如果你确实想要向这些实体传递属性值,则必须将属性值分配到传出消息的标头。有关详细信息,请参阅Route and Reply Actions: Bridging Protocol Mismatch

  • 在将一个桥接中的消息路由到另一个桥接,最后将该消息路由到 Service Bus 队列(举例而言)的“链式”方案中,只能使用链中最后一个桥内的属性来执行进一步的路由或处理。另外,若要将属性值传递给后续桥,必须将属性值分配到传出消息的标头。然后,必须在第二个桥中提取这些属性。

顾名思义,转换阶段提供相应的功能让你对消息执行结构转换。像管道中的其他阶段一样,转换阶段可以处理多种消息类型,因此,你可以在转换阶段进行多种转换。在运行时将会根据传入消息类型自动查找要执行的适当转换,但前提是在配置桥时配置并上载了相应的转换。将会根据传入消息的消息类型发生转换解析。

  • 转换阶段会将消息的消息类型与映射中源架构的消息类型进行匹配。

  • 如果关闭了验证阶段,转换阶段会将传入消息与源消息架构进行匹配。如果发生了解析,转换阶段将升级消息中的 MessageType 属性。

当前的发行版仅支持单一源到单一目标的转换。有关详细信息,请参阅Azure BizTalk 服务中的消息转换。有关如何配置转换阶段的说明,请参阅To configure the Transform stage

转换后的扩展阶段类似于转换前的扩展阶段。两者的唯一差别在于,在转换后的扩展阶段,你可以扩展已转换的消息。配置扩展阶段的方式与转换前扩展阶段相同。有关如何配置扩展阶段的说明,请参阅 XML One-Way Bridge : Configuring the Enrich Stage (post- Transform) for the Request Message

note备注
在转换阶段之前提取或查找的所有属性也可以在已转换的消息中使用。如果以前提取或扩展的属性在转换后扩展阶段被修改,则会覆盖该属性。

在前一部分中,我们已了解到,在验证阶段,将会根据架构执行验证;在转换阶段,将使用转换机制来转换消息。因此,可用作 XML 桥接的一部分的项目包括:

  • 架构。其扩展名为 .XSD

  • 转换。其扩展名为 .TRFM,一个转换阶段可以包含多个转换。

  • 程序集。其中包括可在桥的特定阶段合并的自定义处理逻辑。

  • 证书。用于实现安全的消息传输。

note备注
桥配置文件并不是项目,因为它无法在不同的桥之间共享。桥配置文件特定于桥。

BizTalk 服务应用程序可以包含多个桥接,每个桥接可以使用多个转换和架构。因此,一个典型的 BizTalk 服务应用程序将有大量的转换和架构。但同时,每个 XML 桥接可能并不需要其中的每个转换和架构。这样,就必须通过某种方法将转换和架构关联到某个桥。你可以在配置桥时进行这种关联。

如果你想要通过桥处理任一消息类型,可以使用传递桥。因此,传递桥不包括验证或转换阶段,因为这两个阶段都与消息类型相绑定。传递桥只包括扩展阶段,该阶段的用途与 XML 桥接中相同。有关如何配置传递桥的详细信息,请参阅配置传递桥

另请参阅

显示:
© 2014 Microsoft