使用 BizTalk Server 构建可靠的 EDI 解决方案

1、使用 BizTalk Server 构建可靠的 EDI 解决方案Mark Beckner本文将介绍以下内容： 开发 EDI 架构 对应 EDI 文档 透过防火墙传送文档 处理失败的文档本文使用以下技术： BizTalk Server 2006 R2目录 开发 EDI 架构 EDI 对应 贸易合作伙伴配置 传输 EDI 文档 透过防火墙传送文档 处理失败的文档 EDI 和 SOA 电子文档交换 (EDI) 是一项技术标准，已经有几十年的历史了。所以，此标准看似不能与现今面向服务的体系结构 (SOA) 以及最新发布的 BizTalk Server 结合使用。但在实际的企业对企业商务中，EDI 所占

2、份额最大，接近当前市场份额的 90%，而且还在逐年迅速增加。随着依赖 EDI 的公司的 IT 体系结构的不断发展，利用 BizTalk Server 2006 R2 的功能来同时满足 SOA 和 EDI 基础结构需求这一方法的可靠性、稳定性、可扩展性、可支持性和直观性已得以证实。在 BizTalk Server 2006 R2 发布之前，BizTalk 中对 EDI 的支持是有限的。虽然有一些适配器和加速器可以提供实现 EDI 解决方案的基本基础结构，但是它们的功能存在限制，如文档的验证方式。借助 BizTalk Server 2006 R2，EDI 功能就正常化了。现在，它不仅允许验证大量文

3、档，还提供了许多传输文档的方法，包括实现企业级 EDI 时常用的所有报告功能。现在，BizTalk Server 可以与许多增值网络 (VAN) 提供相同的服务级别，同时还具备对企业集成解决方案和 SOA 而言至关重要的基础 BizTalk 组件的其他优势。这些优势包括通过业务流程开发业务工作流、访问业务规则引擎、扩展的文档跟踪功能、管理状态以及其他类似功能。要在 BizTalk Server 2006 R2 中实现 EDI，首先要开发与交易文档相关的架构。定义了文档后，将贸易合作伙伴创建为 BizTalk 合作对象，然后配置合作伙伴的规范以确保正确处理和路由 EDI 文档。接下来，设置通过合

4、作对象配置和 BizTalk 适配器的组合，来实现如何传送文档的细节。设置好解决方案后，即可使用 EDI 报告实时监控文档流。所有这些功能都是以 BizTalk 基础结构为基础的，并受益于 MessageBox、业务流程、端口和管道等所有标准组件。本文旨在为您介绍 BizTalk Server 2006 R2 中的 EDI 功能，并演示您可以利用此功能更加轻松地将 EDI 流程与企业的其余部分集成。我将介绍使用新 BizTalk Server EDI 组件的几个重要方面，说明架构创建、文档对应、EDI 传送和传输以及异常处理的各个方面。开发 EDI 架构要了解 EDI 架构开发，首先需要清楚文

5、档结构本身的详细情况。对 EDI 文档最确切的描述是一个包含以下三部分的简单文本文件：页眉、详细信息和页脚。页眉定义文档的来源、目标受众、文档类型和一些日期信息。详细信息包含赋予文档意义的所有业务信息。例如，以发票为例，详细信息包含明细项目、出售产品的说明、定价、数量和总额等信息。页脚包含关于详细信息行的摘要信息，如文档包含的总行数。EDI 文档将格式化成多个段，并且每行数据都包含许多已命名的段。这些段的格式和组成部分遵从 X12 以及行政、商业和运输业电子数据交换 (EDIFACT) 等标准。在 X12 文档中，ISA 和 GS 段视为页眉、GE 和 IEA 段对应于页脚、页眉和页脚之间的所

6、有行即为详细信息（请参见图 1）。图 1 X12 EDI 文档 (810 Invoice)（单击图像可查看大图）对于 EDIFACT 文档，以字符 UN 开头的所有段都对应页眉 (UNA, UNB,) 或页脚 (UNT, UNZ)，二者之间的所有段即为详细信息。段和行之间用分隔符隔开，不同的贸易合作伙伴可以使用不同的分隔符。在这两种文档格式中，分隔数据的通常是星号 (*) 字符，分隔行的是换行符、颚化符 () 或者任何其他两种文档都可以识别的字符的组合。BizTalk Server 2006 R2 提供了数千个预定义的 EDI 架构，可用作贸易合作伙伴交换的所有文档的起点。通常需要更改这些架构

7、以反映特定的预期格式。虽然 EDI 包含文档标准，但事实上，交换 810 Invoice 文档的贸易合作伙伴双方可能仍然使用两种不同的形式表示 810，因此就需要两个不同的架构。这些架构紧密相关，可能只有一两个段不同。例如，一方可能要求街道地址的字符数不能超过 50，而另一方要求不超过 100。虽然这一差别非常细微，但仍需要双方分别修改和实现默认的 810 XML 架构定义 (XSD)。架构开发的第一步是定义要交换的电子文档，并开发相应的架构。以发票为例，您需要首先向 BizTalk 解决方案添加一份默认的 810 Invoice 架构。架构模板位于 MicrosoftEdiXSDTempla

8、tes.exe 文件中的 Program FilesMicrosoft BizTalk Server 2006XSD_SchemaEDI 目录下。运行可执行文件以提取模板，然后找到 X12_00401_810.xsd 文件并将其添加到 Visual Studio 中的 BizTalk 解决方案中。此 XSD 提供了可作为 810 Invoice 组成部分的所有数据的超集。假设您要定义 A 公司和 X 公司之间的发票文档交换。下一步要创建 A 公司的 XML 文档的 XSD 表示法；此文档将在创建 EDI 实例时用作源文档。多数情况下，都不必修改默认架构实例。但在此示例中，假设 X 公司要求 N

9、401（城市名）的最大长度为 10 个字符，而不是默认的 30 个字符。要更改长度，请单击 N401 节点并在属性窗口中找到“最大长度”值。在此处输入新值。这样可以确保当尝试通过此系统传递的文档包含 10 个以上的字符时引发 EDI 错误，指示该文档无效。在对应过程中，需要先将该字段截断，然后再将其对应到 EDI 架构。EDI 对应假设 A 公司拥有发票的 XML 表示法，需要在传送之前对应到 EDI 标准。它还需要将所有发票的发票明细项目对应到 IT1 循环并将所对应的总数放在 CTT02 节点中。对应之前，所有架构（无论是否为 EDI 格式）都需要进行定义并添加到解决方案中。A 公司具有

10、XML 版本的发票数据，需要在传输之前对应到 810 Invoice 格式。此 XML 数据必须具有关联的 BizTalk 架构，在此示例中，此架构如图 2 所示。图 2 发票架构摘要 复制代码 .定义架构后，您需要创建 BizTalk 对应。在此示例中，是通过对应将数据从 A 公司的发票信息的 XML 版本转换为标准的 EDI 810 Invoice 实例的。EDI 文档对应与任何其他类型的 BizTalk 对应类似，但 EDI 具有多个特有的复杂性。以发票为例，必须在 CTT01 节点中显示 IT1 节点中的所有明细项目的总数。仔细分析此示例，了解这种类型的对应有何独到之处。首先查看代表发

11、票上明细项目的 IT1 重复节点。如图 3 所示，出现了两种类型的对应：简单的源到目标对应（如 PRICE 到 IT104 的对应）和复杂对应（如 TYPE，需要确定是否将源中的明细项目复制到目标）。图 3 对应明细项目（单击图像可查看大图）在复杂对应中，存在由两个脚本 functoid 和一个等于 functoid 组成的组合。第一个脚本 functoid 包含的逻辑可以确定是否应该对应 TYPE 字段中的值。如果此值等于某一特定的字符串，则会添加到 IT1 循环中。不过，应该注意的逻辑是第二个 functoid，它已连接到 IT101 节点。实际上，这个 functoid 中的代码用于跟踪

12、已对应的明细项目数 不是源文档中的总数而是目标文档中的总数。这个总数既可以用来填充 IT101 的值，又可以增加最终用来填充 CTT01 节点的全局变量。图 4 中显示了 IT101 脚本 functoid 的代码，用于声明和增加可在整个对应中存取的全局参数。全局整数已创建，每发送一次需要对应的明细项目，此整数就增加 1。只要存在需要对应的每个明细项目，此值就会递增，然后生成的结果值就可以填入 IT101 节点。对应所有 IT1 明细项目后，此对应就可以使用 EDI 实例中出现的明细项目总数来填充 CTT01 节点。此值包含在全局整数中，并可使用以下代码在特定于 CTT01 节点的单独脚本 f

13、unctoid 中存取：复制代码 public int intAccessTotal()return globalCtr;图 4 忽略某些明细项目的 Functoid 复制代码 / declare global variable, accessible throughout all other components/ within current mapint globalCtr;/ declare function to increment and return the current value of the/ global countpublic int keepCount (bool

14、mapMe)/ the value of mapMe is the boolean returned by the equals/ functoid (see map)if(mapMe)globalCtr+;/ return the total value to be populated in IT101return globalCtr;贸易合作伙伴配置在 BizTalk Server 中必须设置两个贸易合作伙伴，一个作为发送方，另一个作为接收方。创建的贸易合作伙伴是 BizTalk 中的合作对象，通过 BizTalk Server 管理控制台进行配置。贸易合作伙伴的配置包括许多设置，这可以让

15、 BizTalk 判断哪些文档属于哪个合作伙伴。EDI 文档到达后，BizTalk 会将文档页眉中定义的信息（或者 Applicability Statement 2 或 AS2 信封中的信息）与针对贸易合作伙伴配置的信息进行比较，来找出匹配的文档和贸易合作伙伴。例如，我们假定文档页眉中显示以下 ISA 段：复制代码 ISA*00* *00* *01*BASECOMP12 *ZZ*TRADPART1 *1555*U*00401*0*T* 第六段 (ISA06) 的值为 BASECOMP12，第八段 (ISA08) 的值为 TRADPART1。请记住，段间使用星号 (*) 字符分隔。此处的第三段

16、和第五段均为空。贸易合作伙伴可以配置为交换发送方或接收方。在这种情况下，BizTalk 将根据合作对象的配置比较各段，并找出与设置为接收方的贸易合作伙伴 1 的配置相对应的值（请参见图 5）。由于文档已经有了匹配的合作对象，所以现在就可以针对与该贸易合作伙伴相关的架构来验证文档的其余部分了。判定为无效的文档会用一种方式处理，而有效的文档则会发送出去，交由其他 EDI 组件处理。图 5 已配置的贸易合作伙伴（单击图像可查看大图）传输 EDI 文档文档可以通过任何协议（SMTP、File、FTP、HTTP 及许多其他协议）将发送给贸易合作伙伴。但是，EDI 标准仅支持 VAN 和 AS2。VAN

17、可确保文档是有效的、将路由到合适的收件人以及会有交易的记录。AS2 是一种技术，可以让贸易合作伙伴使用允许使用 S/MIME over HTTP/HTTPS 安全地相互传送文件。BizTalk Server 的强大功能可将各种标准纳入同一个解决方案，让贸易合作伙伴无论是要使用 AS2 还是 VAN，BizTalk 都可作为单一内部 EDI 解决方案。虽然 BizTalk Server 2006 R2 可以消除对 VAN 的需求，但许多贸易合作伙伴仍然通过这些网络进行交易。BizTalk 会通过使用 FTP 和安全的 FTP 来进行来自与传送至 VAN 的文件传输。通过 BizTalk 与 VA

18、N 交互，可能需要使用第三方适配器，因为许多 VAN 都需要使用安全的 FTP。标准 FTP 适配器也存在一些限制，这可能会导致其无法在此类环境中工作。（VAN 通常需要使用 SYST FTP 命令，但标准 BizTalk 适配器则不支持此命令）。但是，无论使用哪种适配器，连接到 VAN 只是一个与 FTP 服务器交互的简单过程。即，通过 VAN 传输给贸易合作伙伴的 EDI 文档通过 FTP 上载，而从贸易合作伙伴检索到的 EDI 文档也要通过 FTP 下载。BizTalk 仅负责成功传送和接收 EDI 文档，并不负责将文档真正传送给贸易合作伙伴，这是 VAN 负责的范围。管理员必须使用特制

19、的工具检查 VAN 上文档的状态。在 BizTalk 中查看 FTP 和 VAN 与 EDI 的通信时，您会发现 VAN 提供的优秀功能（如文档验证、文档跟踪和文档传送）如今也可以在 BizTalk 中找到了。在 AS2 解决方案中，BizTalk 是一种“增值网络”，它可以提供所有功能，但不必担心与 VAN 相关的成本。AS2 允许贸易合作伙伴直接通过安全的 HTTP 相互交流。当 EDI 实现中使用了 AS2 实现时，端口就会通过已在 EDI 方设置了 AS2 属性的标准 HTTP 适配器，或通过第三方 BizTalk 适配器公开。不管采用哪种方式，核心理念都是相同的：实现安全传输并验证文

20、档。安全传输通过证书进行处理，文档验证通过 AS2、合作对象和 BizTalk 中的架构配置进行处理。图 6 显示的示例就是一个已配置为允许通过标准 BizTalk HTTP 适配器进行 AS2 传输的合作对象。在本例中，合作对象已设定 AS2 属性，并将用作 HTTP 适配器的一个扩展。当文档通过 HTTP 送达时，BizTalk 会先比较信息与 AS2 设置，然后再打开 EDI 文档。接着会路由此 EDI 文档，就像通过其他任一方法传送一样。AS2 只是提供一种安全的方式，来传输数据以及任何相关的信封信息。图 6 配置基础 AS2 属性（单击图像可查看大图）透过防火墙传送文档这里需要说明一

21、个重要的概念，即如何将文档传送到位于防火墙后面的 BizTalk Server，即 BizTalk 无法在网络上公开存取。当 SOAP 或 HTTP 接收端口增至 BizTalk 时，该端口就会在本机 IIS 服务器上工作，并且所有已发布数据都需要发送到该本机 Web 服务器。例如，在使用 BizTalk Web 服务发布向导时，只能在安装了 BizTalk Server 的本机 IIS 服务器上创建 Web 服务。在无法从网络外部存取此 IIS 服务器的环境中，必须建立某种解决方案来路由通信（请参见图 7）。有多种解决方案可以解决此问题，如将 BizTalk Server 置于网络的公共部分

22、，或创建一个反向代理来通过防火墙路由要求，让 BizTalk 位于私人网络中。图 7 透过防火墙传送文档（单击图像可查看大图）透过防火墙的通信可以通过编程方式实现，因为将 BizTalk Server 放在网络中的公共存取部分通常都不可接受，此时安全性风险太高。在公用网络的公用 IIS 服务器上开发 Web 服务时，可以采用多种方法。其中一种是创建网关 Web 服务。另一种是创建代理 Web 服务。网关 Web 服务的建立，需要使用自定义编码（与所有 Microsoft .NET Framework Web 服务一样），还需要进行复杂的界面转换，以符合 BizTalk 预期的界面。网关会接受来

23、自公共网络的请求，并将其对应到向防火墙后面的 Web 服务发出的请求。另一方面，代理 Web 服务的建立，需要修改使用 BizTalk Web Services 发布向导生成的内容，然后将其副本置于公共 Web 服务器上。从其简单性来看，修改代理 Web 服务似乎是最理想的选择。要创建代理 Web 服务，需要启动 BizTalk Web Services 发布向导。单击该向导中相应的选项，然后定义 Web 服务的发布位置（请注意，虚拟目录创建位置的唯一选项就是在本地 IIS 服务器上）。当向导创建 Web 服务时，实际上是创建了一个代理，该代理可以将来自 IIS 的传入呼叫重定向至 BizTa

24、lk MessageBox 中，以便将其路由到相应的业务流程。此代理 Web 服务会自动编码，并且已经进行了预配置，只要传入发布直接进入此 Web 服务器即可正常运行，无需用户进行任何更改。要使发布进入网络的公共部分并路由到此 Web 服务中，需要执行三个基本步骤。第一步，创建代理到代理 Web 服务。当 Web 服务通过向导导出后，BizTalk 会将其称为代理 Web 服务。若要从外部客户端调用此 Web 服务，就必须在可将请求路由到的公共服务器上创建代理 Web 服务。此操作通过在公共 IIS 服务器上创建虚拟目录即可实现，其中的名称和界面要与生成的代理完全相同。创建虚拟目录后，将原始

25、BizTalk IIS 目录下所有生成的文件复制到公用服务器上的虚拟目录中。第二步，修改面向公用网络的 Web 服务，将传入的 SOAP 信息重新路由到承载 BizTalk Server 的 IIS 服务器上的内部代理 Web 服务中，而不是发布到 BizTalk 引擎。要修改的代码会放在一个文件中，该文件位于发布 Web 服务的虚拟目录的 App_Code 子目录下。此文件名称取决于正在发布的实体的名称，但始终以 asmx.cs 结尾。打开此文件将显示类和 Web 方法声明，这就为调用实体提供了一个公共接口，并使这些请求能够直接推入 BizTalk MessageBox 中。要查看这些生成的

26、代码，需要使用 Web Services 发布向导导出具有双向 SOAP 端口的业务流程。此向导完成后，打开 App_Code 目录中的 asmx.cs 文件查看代码。Web 方法的名称基于业务流程中在端口上定义的操作的名称。此 Web 方法中，代码将接收传入发布并将其转换为可发布到 MessageBox 中的格式。Web 服务将传入发布推入 MessageBox 后，会等待一个响应，该响应对应于业务流程的双向端口中的出站请求，并将其回发给调用实体。将此代码复制并粘贴到公用网络中的新 IIS 服务器后，必须对其进行修改，使其能够将传入发布转发到 BizTalk Server 上的 Web 服务

27、中。可以使用图 8 中显示的代码来修改原始的代理 Web 服务代码。此代码首先覆盖原始 Web 服务中的 Web 方法，接着并不是将其发布到 MessageBox 中，而是加载 web.config 文件中的一些可配置字段，并将传入请求发布到 BizTalk IIS 服务器上的 Web 服务中。路由到 BizTalk 引擎的任务，仍然由原始的代理 Web 服务处理。图 8 代理对代理 Web 服务。 复制代码 public BTSRedirect.SyncTransResponse Operation_SyncTrans( System.Xml.Serialization.XmlElement

28、Attribute( Namespace=http:/GuardianProStar.BizTalk.Schemas.SyncTrans.SyncTransRequest, ElementName=SyncTransRequest) BTSRedirect.SyncTransRequest part) BTSRedirect.SyncTransRequest objSyncTransReq = part; BTSRedirect.SyncTransResponse objSyncTransRes = new BTSRedirect.SyncTransResponse(); BTSRedirec

29、t.GuardianProStar_BizTalk_Orchestrations_SyncTrans_SyncTransactions_Port_SyncTrans objWebServiceMethodCall = new BTSRedirect.GuardianProStar_BizTalk_Orchestrations_SyncTrans_SyncTransactions_Port_SyncTrans(); / authentication/credentials string strWSUser = System.Configuration.ConfigurationManager.A

30、ppSettingsWSUser; string strWSPassword = System.Configuration.ConfigurationManager.AppSettingsWSPassword; string strWSDomain = System.Configuration.ConfigurationManager.AppSettingsWSDomain; string strWSAuthenticationType = System.Configuration.ConfigurationManager.AppSettingsWSAuthenticationType; ob

31、jWebServiceMethodCall.Url = System.Configuration.ConfigurationManager.AppSettingsRedirectURL; System.Net.CredentialCache cache = new System.Net.CredentialCache(); cache.Add(new System.Uri(objWebServiceMethodCall.Url), strWSAuthenticationType, new System.Net.NetworkCredential(strWSUser, strWSPassword

32、, strWSDomain); objWebServiceMethodCall.Credentials = cache; / set the response equal to the return value of the call to the web service objSyncTransRes = objWebServiceMethodCall.Operation_SyncTrans(objSyncTransReq); return objSyncTransRes;由于这两种 Web 服务具有相同的 Web 界面，所以可以使用相同的客户端代码调用任一服务。因此，在开发过程中，您可以使

33、用由向导发布的原始 Web 服务代码来验证是否所有元件都在按预期工作。代理对代理可以在测试和开发的最后阶段创建，也不会影响任何客户端代码。使用代理对代理 Web 服务的最后一步，是修改公用 IIS 服务器上的 web.config 文件，以便使用可配置字段。新 Web 服务所需的字段如下所示：复制代码 这些设置是针对身份验证值和重定向 URL 提供的。可配置字段的实际列表（以及它们实际存储在 web.config 文件中还是其他位置）由开发人员确定，此处显示的列表仅供说明使用。通过防火墙的最复杂的发布路由就是 Web 服务的发布路由。HTTP 发布（和 AS2）可以使用相似的方式处理，但不需要复制和修改 BizTalk 中生成的代码。对于 HTTP 发布，可以使用非常简单的重定向模式进行路由，具体取决于发布的性质。许多组织在确定正确的 BizTalk 服务器路由方式时，可能会感到很困扰，重点是，这些类型的会话不应过于复杂，因为有很多简单的解决方案都可以解决这个常见问题。处理传送失败的文档EDI 实现需要使用大量架构。每个传入或传出 BizTalk 的文档都要根据相应的架构进行验证。如果文档通过验证，则会路由到 BizTalk 引擎，然后由 EDI 组件处理。但是，如果文档未通过验证就会失败，而且默认情况下，BizTalk 将不再进行处理，而是将