BizTalk

在 BizTalk Server 2010 中批量处理 EDI 数据

Mark Beckner

 

ExpandedElectronic 数据交换 (EDI) capa 与­也许微软 BizTalk 服务器 2010 年可用,越来越多的公司正在看如何在其环境中利用它。 EDI 数据的配料是一些的最有价值的功能,可以提供平台,但它可以是混乱和复杂的实施。 使用本文中介绍的步骤,您将学习如何快速、 轻松地从一个源数据库中提取数据并实现映射和配料使用几种方案。 包括在讨论的是有关配置要检索使用 XML 数据的 SQL 适配器的信息。

解决方案概述

使用 BizTalk 服务器 2010 年批量数据可能非常复杂,但很多这种复杂性可以删除,如果您想通过您的体系结构,并决定处理各方面的配料的最佳地点。 为了理解的配料的主要组成部分,要通过创建和配置的每个工作。 你将开始与创建的存储的过程,通过 BizTalk 随时耗材的格式的源数据中提取 — 和允许的各种选项的如何,您可能要批量数据的格式。 下一步,您将了解创建架构和映射到目标电子数据交换格式的数据的选项。 最后,您将设置配料对 BizTalk 方协议,所以可以创建数据并将其写入到一个文件。 若要通过此解决方案的工作,你需要 BizTalk 服务器 2010年、 Visual Studio 2010 和 SQL Server 2008 R2。

从 SQL Server 使用 XML 和 XMLNAMESPACES 中提取数据

当从 SQL 服务器查询数据使用 BizTalk 中有一个功能强大的选项。 此选项是 XML,允许检索特定的 XML 格式的数据。 XML 是 BizTalk 中的所有数据所都依据的基础。 当作为 XML 中提取出来,从存储过程的数据可以立即准备的业务流程和地图,而不需要生成通过各种 SQL 适配器进行通信时,一般须的复杂构件的消费。 FOR XML 方法有一些很大的好处:

  • 它允许 SQL Server 开发人员编写集成体系结构的关键件,而无需了解 BizTalk。
  • 附加字段,可以添加到结果,并纳入 BizTalk 组件相对容易。
  • 它是处理数据的有效方法,它可以减少必须开发的组件的数量。
  • 它可以格式化,以匹配目标架构,为了简化映射。

有许多选项与在 SQL Server 中使用 XML 相关的。 处理数据为 BizTalk 创建时使用它的最适当的方法是使用 XMLNAMESPACES 的特定命名空间的声明,并设置 XML 的格式,具体所需使用的路径模式 (相对于让 SQL Server 会自动将其命名为您,使用自动模式)。 XMLNAMESPACES 是一个简单的子句,可以创建 XML 中的 SELECT 语句之前,添加和路径模式可确保您可以创建任何类型的层次结构和属性和您需要才能呈现适当格式数据的元素的组合。

图 1 显示存储过程使用的 XML 路径和 XMLNAMESPACES 的示例。 首先,它声明的命名空间的 XML 文档会,然后设置 XML 的格式。 最好的办法时建立您的 XML 结构是看此 XML 将会采取在 BizTalk 映射到。 如果你可以匹配您与您的源架构的目标架构的结构,这两个之间的映射会简单得多。 例如,如果您正在创建员工结构将映射到目标员工结构,使雇员的层次结构 (姓名、 出生日期、 地址、 电话等等) 的源匹配目标雇员的层次结构。

图 1 使用 XML 和 XMLNAMESPACES 的存储的过程

CREATE PROCEDURE [dbo].[GetData] AS
BEGIN
 -- define the namespace and prefix
 WITH XMLNAMESPACES('http://sql.claims.extract' as "ns0")
 -- top level is set to NULL
 SELECT NULL
       ,(SELECT ClaimData.ClaimType As [ns0:ClaimType]
             ,ClaimData.ClaimNo As [ns0:ClaimNo]
             ,ClaimData.DateFrom As [ns0:DateFrom]
             ,(SELECT first As [ns0:FName]
                     ,last As [ns0:LName]
                     ,birth As [ns0:BDate]
              FROM Members
              WHERE Members.ID = ClaimData.MemberID
              FOR XML PATH('ns0:Member'), TYPE)
       FROM ClaimData 
     FOR XML PATH('ns0:Claim'), TYPE)
   FOR XML PATH('ns0:ClaimExtract'), TYPE
END

在设置数据的格式,您应该考虑在存储过程中添加的业务规则。 更多的逻辑可以添加在这一级,就越容易该解决方案将保持和发展 — 无需重新编译代码或经过复杂的测试程序。 只需更新存储的过程和测试的正确的业务规则将被应用于结果集。 在许多情况下业务规则可以是内置到存储过程,而不是试图通过业务规则引擎 (BRE) BizTalk 中处理它们。 创建强 BizTalk 体系结构开始通过确保在每个阶段使用最合适的技术。

配置 SQL 适配器中提取数据

现在,您已经返回 XML 的存储的过程下, 一步是配置 BizTalk Server 来检索数据。 这可以通过使用标准的 SQL 适配器附带的产品。 开发人员可能会发现与 SQL 适配器是极为繁琐的工作。 以我的经验,它通常需要大量的用于将结果映射到目标的各种文物,并通常是既不直观与工作,也不容易维护和扩展的架构的生成。 然而,在某些情况下 — 喜欢我要去看看现在的一个 — 它令人惊讶地使用很简单,并提供极好的服务。

情况下直接从存储过程中提取的 XML 数据,有几个优秀的好处,它使用 SQL 适配器提供:它易于配置、 要求没有其他 BizTalk 架构,并可以配置为按计划运行。 虽然你提取的 XML 数据会发现它很有用,但通常应使用 Microsoft。NET 框架类与 SQL 服务器进行交互。

若要使用 SQL 适配器调用存储的过程,首先创建一个新的 BizTalk 接收位置。 接收位置应为类型"SQL,"和管道可以设置为标准的 PassThruReceive 管道。 有值得探讨的几个领域:

  • 文档根元素名称这是结果集的容器节点。 您可能已经在 XML 结果集的存储过程,从中定义的根元素,但适配器将将其包装在一个额外的节点。 这是非常有用的如果您需要拆分的结果集到单个文档使用信封架构 — 但不是每个解决方案需要执行此操作。
  • 使用文档目标 Namespace 此命名空间的架构。 您可以以什么为命名空间声明了存储过程中类似的事情干。
  • SQL 命令这是您使用调用存储的过程的 EXEC 命令。 概述了以前的存储过程,此值将会 EXEC GetData。 您可以轻松地添加参数。 例如,如果你想要调用 GetData,为特定的贸易伙伴和特定数量的记录,您可以输入 EXEC '100' GetData 'TradingPartnerName'。

一旦创建了接收位置和相关联的接收端口,您可以创建简单的发送端口指订阅接收端口和写出的 XML 文件下降。 为此,只是设置输血服务中心。ReceivePortName 在发送端口的筛选器,以你的 SQL 适配器创建的接收端口的名称。 一旦一切都已启用并运行,您应该看到类似如中所示的输出图 2

图 2 示例结果的存储过程的 SQL 适配器调用

<DataResultSet xmlns="http://SQLExtract.DataResultSet">
  <ns0:ClaimExtract xmlns:ns0="http://sql.claims.extract">
    <ns0:Claim xmlns:ns0="http://sql.claims.extract">
      <ns0:ClaimType>Institutional</ns0:ClaimType>
      <ns0:ClaimNo>ABC100</ns0:ClaimNo>
      <ns0:DateFrom>2012-01-01T00:00:00</ns0:DateFrom>
      <ns0:Member xmlns:ns0="http://sql.claims.extract">
        <ns0:FName>John</ns0:FName>
        <ns0:LName>Doe</ns0:LName>
        <ns0:BDate>1975-01-28T00:00:00</ns0:BDate>
      </ns0:Member>
    </ns0:Claim>
    <ns0:Claim xmlns:ns0="http://sql.claims.extract">
      <ns0:ClaimType>Institutional</ns0:ClaimType>
      <ns0:ClaimNo>XYZ200</ns0:ClaimNo>
      <ns0:DateFrom>2012-01-05T00:00:00</ns0:DateFrom>
      <ns0:Member xmlns:ns0="http://sql.claims.extract">
        <ns0:FName>Jane</ns0:FName>
        <ns0:LName>Doe</ns0:LName>
        <ns0:BDate>1976-10-08T00:00:00</ns0:BDate>
      </ns0:Member>
    </ns0:Claim>
  </ns0:ClaimExtract>
</DataResultSet>

在查询结果中创建架构

通过向导的使用,可以完成的实际 BizTalk 基于从 SQL 适配器中的存储过程中检索的 XML 的 XSD 创建。 若要创建架构,请执行以下步骤:

  1. 右键单击您要添加到架构,并选择添加的 BizTalk Visual Studio 项目 |生成的项目。
  2. 在打开的窗口中,单击生成的架构。
  3. 在生成架构对话,设置文档类型属性来"格式正确的 XML"。注意,默认情况下,这并不是最初可用。 错误会弹出大纲显示哪些文件需要运行以启用此功能。
  4. 设置输入文件的实例中所示的 XML 的图 3 ,然后单击确定。

The Generated XSD
生成的 XSD 图 3

这些步骤将向您的项目添加两个 XSDs。 您可以决定要如何使用它们,以及您可也将它们合并到单个的 XSD 如果您更喜欢。 顶级架构的示例所示图 3

映射和批处理选项

现在,您有您准备将映射到您的电子数据交换格式的源数据。 思想的需要是投入如何最好地格式和批处理 EDI 将要发送的文件。 一些贸易伙伴可能需要单一的 ST/SE 组内的多个记录,而其他人可能需要此分组内的单个记录。 可能有限制单个文档或单个 ST/SE 内, 记录的总数,很可能会有当一批获取创建和传送的要求。 837 (保健索赔规格) 文档格式提供了极好的例子。 2,500 索赔最多会出现在每个 ST/SE 组和 20 个人 ST/SEs 最多会出现在一个文档,可能,例如,要求贸易伙伴。 评估的各方的交换信息的要求将导致您确定如何最好地通过 BizTalk 您的数据路径的结构。

至于实际 BizTalk 地图和相关联的配料,有两种基本选择。 一是将您的数据映射到目标 EDI 架构中单个 ST/SE 组 ; 二是要映射到单个 ST/SE 组的多个源中的记录。 取决于您需要采取哪条路线,您可能要设置信封架构分裂的源数据,和你得有些差异,在你的映射和您批处理配置。

每个人 ST/SE 首先看的情形将拆分和进行批处理作为个别 ST/SE 组中的单个记录源数据的一个记录。 中所示的示例源数据图 3 中有两项索赔。 目标是采取个人索赔 (<ns0:Claim>) 和拆分出来,以便他们可以映射单独到目标 837 架构。 映射后,到达 BizTalk 中有数据,可以进行批处理。 为了将数据拆分,您需要创建信封架构:

  • 将信封属性设置的架构为"是"。
  • 您的文档包含索赔节点的节点的根段上设置正文 XPath — 在本例中,ClaimExtract 节点。
  • 部署信封架构。 具有执行,默认 XMLReceive 管道的接收位置接收到的文件的时刻它会进行拆分。 没有引用任何地方的信封架构的需要。
  • 如果您要订阅接收分裂 doc 的接收端口设置发送端口,发送端口将写出单个索赔 XML 文件中。 然后可以使用这些作为您的映射的源,您的目标 EDI 架构。 发送端口上应有 EDI 交易记录源的地图。

此时,有许多个别 EDI 文档文件目录中堆积。 您现在可以设置第二个接收位置 /­发送端口的组合,不会的配料,如下所示:

  • 在您收到的位置,请设置为 EdiReceive 的接收管道。 它将接的第一次接收/发送组合只写出个人的 EDI 文档。
  • 在您发送端口,如中所示设置过滤器图 4。 请注意,电子数据交换。BatchName 和电子数据交换。DestinationPartyName 设置中的一方将在接下来的步骤配置的信息。 此发送端口,与 EDISend 指定为管道,可以设置将写入文件放 — 输出将批量的数据。

Filters on the Batching Send Port
图 4 上配料的发送端口的筛选器

  • 创建一个新的 BizTalk 党和代表与贸易伙伴将要接收的批处理的文件的数据交换的协议。 要配置的主要内容为:
    • 在标识符选项卡上设置发送方和接收方 Id 为适当的值。 DestinationPartyName 应与您的发送端口的筛选器中的设置相匹配。
    • 在本地主机设置和信封选项卡上,设置您正在处理的特定 EDI 文档的属性。
    • 批处理配置选项卡中,设置以下属性:
      • 批处理名称设置为您设置它的发送端口的筛选器中。
      • 设置批处理筛选器具有两个属性:
        • 输血服务中心。ReceivePortName = = [的名称您接收个人 EDI 文档中都哪里来的端口]
        • 电子数据交换。ST01! = 997
      • 设置发布选项。 这很有可能根据附表上 (提供有排队最后 24 小时内的所有文件) 或对总数 (共 2,500 项时此批处理排队的发送)。 如果释放"设置中的最多的事务数"属性,到组设置下拉列表。
      • 一旦设置了属性,单击启动激活配料。 它可以完全启动批处理之前的几分钟。 继续单击刷新按钮,直到出现的"激活批处理"的消息。 应在 BizTalk (这可以在通过 BizTalk 组中心报告的运行实例可见) 中运行的批处理业务流程的实例。 此业务流程是 BizTalk EDI 安装的应用程序是用 BizTalk 中 EDI 组件的一部分 — 这不是你要写的东西。
    • 单击确定以保存所有的设置。

一旦一切配置、 登记、 启动并启用了,重新启动 BizTalk 主机实例。 这将确保一切都是新鲜的在内存中。 下一步,放上接收位置的个别 ST/SE 文档,并将生产批次,一旦释放机制触发 (例如,如果 2,500 指定作为交易记录集,数量然后必须删除 2,500 单个文档)。

许多记录每个人 ST/SE 的下一步的情形来看为个别 ST/SE 组映射多个记录。 再次,样本源中显示的数据图 3 中有两项索赔。 新的目标是采取个人索赔 (<ns0:Claim> 是一项单一索赔的根节点) 和它们都映射到单个目标 837 架构。 映射后,也可以传递数据,如是,单个 ST/se,单个文档中或具有多个 ST/Se,每个都有多个索赔记录的文档到像前面的示例可以成批。

从开始改变你写的存储的过程 (见图 1)。 现在,它只是使恢复数据库中记录的全部。 您需要添加一个参数,以限制回来的记录的数目。 例如,如果要能够放入单个 ST/SE 的 5,000 记录,您会需要抓住仅 5,000 记录一次从您的源数据库。 您可以添加额外的参数,例如"贸易合作伙伴 ID,",进一步限制什么回来和使存储的过程可重复使用跨多个缔约方。 添加后,您可以修改在附加参数中传递的 SQL 适配器设置。 最终你会将定期 (每个小时,例如),周期上运行 SQL 适配器设置每次提取 5,000 的记录。

下一步,改变你的映射。 无论你放入到目标 EDI 架构源的地方现在的映射需要修改使用循环。 837 的情况下,例如你要设置循环 functoid 与源被 <ns0:Claim> (从架构中图 3) 和目标是 TS837_2000A_Loop,这是顶级的目标索赔。

现在,您的映射完成后,您可以决定是否设置或不 BizTalk 党内配料。 如果您只想在单个文档中的单个 ST/SE 提供 5,000 索赔,你的工作完成 — 只是发送端口的设置和使用 EDISend 管道船数据。 如果您想设置配料,配置将什么从你工作在本文前面相同。

批处理发布选项

您有许多选项可用,释放你的批次。 如前所述,这两个最常见的释放分批对一个特定的时间表,释放时已达到特定数量的交易。 调度程序允许多种每小时、 每天、 每周的配置。 例如,如果您需要提供任何记录有排队每天午夜的计数,无论将配置在午夜的每日如期释放批处理。 轻松地配置发布基于特定数量的交易的批处理选项 — 只需指定数目的是。 配料的附加选项包括释放和外部发布触发器上指定数量的字符在交汇处。

可以使用消息框上丢弃的控制消息触发外部发布触发器。

极大简化

您构建您的配料过程中 BizTalk,您应该确保您正在构建尽可能简单的东西。 BizTalk 解决方案很多被负担过度的业务流程、 架构、 引用的 Dll 和其他工件。 开发人员通常会决定他们需要创建自定义的配料业务流程来处理他们的感觉是一个独特的情况。 始终专注于您的解决方案的长期可行性。 可以看看你在做什么现在的六个月的开发人员,并了解如何使用它? 一般情况下,您可以生成一个进程,从 BizTalk 中提取数据,并提供给各贸易伙伴与一个或没有业务流程,代表代表目标数据和地图方每个架构的源数据的一个架构。 如果您发现自己创建比这更多组件,后退一步,重新分析您的解决方案。 你可能会发现你可以做一些伟大的简化。

Mark Beckner Inotek 咨询集团有限公司的创始人是 (inotekgroup.com)。他跨 Microsoft 堆栈,包括 BizTalk、 SharePoint、 动力学 CRM 和一般工作。NET 框架的发展情况。

多亏了以下的技术专家审查这篇文章: Karthik Bharathy