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

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

《使用 BizTalk Server 构建可靠的 EDI 解决方案.docx》由会员分享，可在线阅读，更多相关《使用 BizTalk Server 构建可靠的 EDI 解决方案.docx（16页珍藏版）》请在冰豆网上搜索。

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

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

MarkBeckner

本文将介绍以下内容：

▪开发EDI架构

▪对应EDI文档

▪透过防火墙传送文档

▪处理失败的文档

本文使用以下技术：

BizTalkServer2006R2

 目录

开发EDI架构

EDI对应

贸易合作伙伴配置

传输EDI文档

透过防火墙传送文档

处理失败的文档

EDI和SOA

电子文档交换（EDI）是一项技术标准，已经有几十年的历史了。

所以，此标准看似不能与现今面向服务的体系结构（SOA）以及最新发布的BizTalk®Server结合使用。

但在实际的企业对企业商务中，EDI所占份额最大，接近当前市场份额的90%，而且还在逐年迅速增加。

随着依赖EDI的公司的IT体系结构的不断发展，利用BizTalkServer2006R2的功能来同时满足SOA和EDI基础结构需求这一方法的可靠性、稳定性、可扩展性、可支持性和直观性已得以证实。

在BizTalkServer2006R2发布之前，BizTalk中对EDI的支持是有限的。

虽然有一些适配器和加速器可以提供实现EDI解决方案的基本基础结构，但是它们的功能存在限制，如文档的验证方式。

借助BizTalkServer2006R2，EDI功能就正常化了。

现在，它不仅允许验证大量文档，还提供了许多传输文档的方法，包括实现企业级EDI时常用的所有报告功能。

现在，BizTalkServer可以与许多增值网络（VAN）提供相同的服务级别，同时还具备对企业集成解决方案和SOA而言至关重要的基础BizTalk组件的其他优势。

这些优势包括通过业务流程开发业务工作流、访问业务规则引擎、扩展的文档跟踪功能、管理状态以及其他类似功能。

要在BizTalkServer2006R2中实现EDI，首先要开发与交易文档相关的架构。

定义了文档后，将贸易合作伙伴创建为BizTalk合作对象，然后配置合作伙伴的规范以确保正确处理和路由EDI文档。

接下来，设置通过合作对象配置和BizTalk适配器的组合，来实现如何传送文档的细节。

设置好解决方案后，即可使用EDI报告实时监控文档流。

所有这些功能都是以BizTalk基础结构为基础的，并受益于MessageBox、业务流程、端口和管道等所有标准组件。

本文旨在为您介绍BizTalkServer2006R2中的EDI功能，并演示您可以利用此功能更加轻松地将EDI流程与企业的其余部分集成。

我将介绍使用新BizTalkServerEDI组件的几个重要方面，说明架构创建、文档对应、EDI传送和传输以及异常处理的各个方面。

开发EDI架构

要了解EDI架构开发，首先需要清楚文档结构本身的详细情况。

对EDI文档最确切的描述是一个包含以下三部分的简单文本文件：

页眉、详细信息和页脚。

页眉定义文档的来源、目标受众、文档类型和一些日期信息。

详细信息包含赋予文档意义的所有业务信息。

例如，以发票为例，详细信息包含明细项目、出售产品的说明、定价、数量和总额等信息。

页脚包含关于详细信息行的摘要信息，如文档包含的总行数。

EDI文档将格式化成多个段，并且每行数据都包含许多已命名的段。

这些段的格式和组成部分遵从X12以及行政、商业和运输业电子数据交换（EDIFACT）等标准。

在X12文档中，ISA和GS段视为页眉、GE和IEA段对应于页脚、页眉和页脚之间的所有行即为详细信息（请参见图1）。

图1X12EDI文档（810—Invoice）（单击图像可查看大图）

对于EDIFACT文档，以字符UN开头的所有段都对应页眉（UNA,UNB,）或页脚（UNT,UNZ），二者之间的所有段即为详细信息。

段和行之间用分隔符隔开，不同的贸易合作伙伴可以使用不同的分隔符。

在这两种文档格式中，分隔数据的通常是星号（*）字符，分隔行的是换行符、颚化符（~）或者任何其他两种文档都可以识别的字符的组合。

BizTalkServer2006R2提供了数千个预定义的EDI架构，可用作贸易合作伙伴交换的所有文档的起点。

通常需要更改这些架构以反映特定的预期格式。

虽然EDI包含文档标准，但事实上，交换810Invoice文档的贸易合作伙伴双方可能仍然使用两种不同的形式表示810，因此就需要两个不同的架构。

这些架构紧密相关，可能只有一两个段不同。

例如，一方可能要求街道地址的字符数不能超过50，而另一方要求不超过100。

虽然这一差别非常细微，但仍需要双方分别修改和实现默认的810XML架构定义（XSD）。

架构开发的第一步是定义要交换的电子文档，并开发相应的架构。

以发票为例，您需要首先向BizTalk解决方案添加一份默认的810Invoice架构。

架构模板位于MicrosoftEdiXSDTemplates.exe文件中的\ProgramFiles\MicrosoftBizTalkServer2006\XSD_Schema\EDI目录下。

运行可执行文件以提取模板，然后找到X12_00401_810.xsd文件并将其添加到VisualStudio®中的BizTalk解决方案中。

此XSD提供了可作为810Invoice组成部分的所有数据的超集。

假设您要定义A公司和X公司之间的发票文档交换。

下一步要创建A公司的XML文档的XSD表示法；此文档将在创建EDI实例时用作源文档。

多数情况下，都不必修改默认架构实例。

但在此示例中，假设X公司要求N401（城市名）的最大长度为10个字符，而不是默认的30个字符。

要更改长度，请单击N401节点并在属性窗口中找到“最大长度”值。

在此处输入新值。

这样可以确保当尝试通过此系统传递的文档包含10个以上的字符时引发EDI错误，指示该文档无效。

在对应过程中，需要先将该字段截断，然后再将其对应到EDI架构。

EDI对应

假设A公司拥有发票的XML表示法，需要在传送之前对应到EDI标准。

它还需要将所有发票的发票明细项目对应到IT1循环并将所对应的总数放在CTT02节点中。

对应之前，所有架构（无论是否为EDI格式）都需要进行定义并添加到解决方案中。

A公司具有XML版本的发票数据，需要在传输之前对应到810Invoice格式。

此XML数据必须具有关联的BizTalk架构，在此示例中，此架构如图2所示。

 图2发票架构摘要

复制代码

xmlversion="1.0"encoding="utf-16"?

>

schemaxmlns:

b="xmlns="http:

//schemas.MSDN.com/Common/810/v1"attributeFormDefault="unqualified"elementFormDefault="qualified"targetNamespace="http:

//schemas.MSDN.com/Common/810/v1"xmlns:

xs="http:

//www.w3.org/2001/XMLSchema">

elementname="COMMON_810">

complexType>

sequence>

elementname="TRANSACTION">

complexType>

sequence>

elementname="HEADER">

complexType>

sequenceminOccurs="1"maxOccurs="1">

elementname="GUID"type="xs:

string"/>

elementname="DOCID"type="xs:

string"/>

elementname="DESC"type="xs:

string"/>

elementname="PARTNER"type="xs:

string"/>

sequence>

complexType>

element>

elementname="ADDRESSES">

complexType>

sequenceminOccurs="0"maxOccurs="unbounded">

elementmaxOccurs="unbounded"name="ADDRESS">

complexType>

sequence>

elementname="TYPE"type="xs:

string"/>

elementname="STREET"type="xs:

string"/>

elementname="CITY"type="xs:

string"/>

elementname="STATE"type="xs:

string"/>

elementname="ZIP"type="xs:

string"/>

sequence>

complexType>

element>

sequence>

complexType>

element>

elementname="ITEMS">

...

定义架构后，您需要创建BizTalk对应。

在此示例中，是通过对应将数据从A公司的发票信息的XML版本转换为标准的EDI810Invoice实例的。

EDI文档对应与任何其他类型的BizTalk对应类似，但EDI具有多个特有的复杂性。

以发票为例，必须在CTT01节点中显示IT1节点中的所有明细项目的总数。

仔细分析此示例，了解这种类型的对应有何独到之处。

首先查看代表发票上明细项目的IT1重复节点。

如图3所示，出现了两种类型的对应：

简单的源到目标对应（如PRICE到IT104的对应）和复杂对应（如TYPE，需要确定是否将源中的明细项目复制到目标）。

图3对应明细项目（单击图像可查看大图）

在复杂对应中，存在由两个脚本functoid和一个等于functoid组成的组合。

第一个脚本functoid包含的逻辑可以确定是否应该对应TYPE字段中的值。

如果此值等于某一特定的字符串，则会添加到IT1循环中。

不过，应该注意的逻辑是第二个functoid，它已连接到IT101节点。

实际上，这个functoid中的代码用于跟踪已对应的明细项目数—不是源文档中的总数而是目标文档中的总数。

这个总数既可以用来填充IT101的值，又可以增加最终用来填充CTT01节点的全局变量。

图4中显示了IT101脚本functoid的代码，用于声明和增加可在整个对应中存取的全局参数。

全局整数已创建，每发送一次需要对应的明细项目，此整数就增加1。

只要存在需要对应的每个明细项目，此值就会递增，然后生成的结果值就可以填入IT101节点。

对应所有IT1明细项目后，此对应就可以使用EDI实例中出现的明细项目总数来填充CTT01节点。

此值包含在全局整数中，并可使用以下代码在特定于CTT01节点的单独脚本functoid中存取：

复制代码

publicintintAccessTotal（）

{

returnglobalCtr;

}

 图4忽略某些明细项目的Functoid

复制代码

//declareglobalvariable,accessiblethroughoutallothercomponents

//withincurrentmap

intglobalCtr;

//declarefunctiontoincrementandreturnthecurrentvalueofthe

//globalcount

publicintkeepCount（boolmapMe）

{

//thevalueofmapMeisthebooleanreturnedbytheequals

//functoid（seemap）

if（mapMe）

globalCtr++;

//returnthetotalvaluetobepopulatedinIT101

returnglobalCtr;

}

贸易合作伙伴配置

在BizTalkServer中必须设置两个贸易合作伙伴，一个作为发送方，另一个作为接收方。

创建的贸易合作伙伴是BizTalk中的合作对象，通过BizTalkServer管理控制台进行配置。

贸易合作伙伴的配置包括许多设置，这可以让BizTalk判断哪些文档属于哪个合作伙伴。

EDI文档到达后，BizTalk会将文档页眉中定义的信息（或者ApplicabilityStatement2或AS2信封中的信息）与针对贸易合作伙伴配置的信息进行比较，来找出匹配的文档和贸易合作伙伴。

例如，我们假定文档页眉中显示以下ISA段：

复制代码

ISA*00**00**01*

BASECOMP12*ZZ*TRADPART1*

070407*1555*U*00401*000000025*0*T*>~

第六段（ISA06）的值为BASECOMP12，第八段（ISA08）的值为TRADPART1。

请记住，段间使用星号（*）字符分隔。

此处的第三段和第五段均为空。

贸易合作伙伴可以配置为交换发送方或接收方。

在这种情况下，BizTalk将根据合作对象的配置比较各段，并找出与设置为接收方的贸易合作伙伴1的配置相对应的值（请参见图5）。

由于文档已经有了匹配的合作对象，所以现在就可以针对与该贸易合作伙伴相关的架构来验证文档的其余部分了。

判定为无效的文档会用一种方式处理，而有效的文档则会发送出去，交由其他EDI组件处理。

图5已配置的贸易合作伙伴（单击图像可查看大图）

传输EDI文档

文档可以通过任何协议（SMTP、File、FTP、HTTP及许多其他协议）将发送给贸易合作伙伴。

但是，EDI标准仅支持VAN和AS2。

VAN可确保文档是有效的、将路由到合适的收件人以及会有交易的记录。

AS2是一种技术，可以让贸易合作伙伴使用允许使用S/MIMEoverHTTP/HTTPS安全地相互传送文件。

BizTalkServer的强大功能可将各种标准纳入同一个解决方案，让贸易合作伙伴无论是要使用AS2还是VAN，BizTalk都可作为单一内部EDI解决方案。

虽然BizTalkServer2006R2可以消除对VAN的需求，但许多贸易合作伙伴仍然通过这些网络进行交易。

BizTalk会通过使用FTP和安全的FTP来进行来自与传送至VAN的文件传输。

通过BizTalk与VAN交互，可能需要使用第三方适配器，因为许多VAN都需要使用安全的FTP。

标准FTP适配器也存在一些限制，这可能会导致其无法在此类环境中工作。

（VAN通常需要使用SYSTFTP命令，但标准BizTalk适配器则不支持此命令）。

但是，无论使用哪种适配器，连接到VAN只是一个与FTP服务器交互的简单过程。

即，通过VAN传输给贸易合作伙伴的EDI文档通过FTP上载，而从贸易合作伙伴检索到的EDI文档也要通过FTP下载。

BizTalk仅负责成功传送和接收EDI文档，并不负责将文档真正传送给贸易合作伙伴，这是VAN负责的范围。

管理员必须使用特制的工具检查VAN上文档的状态。

在BizTalk中查看FTP和VAN与EDI的通信时，您会发现VAN提供的优秀功能（如文档验证、文档跟踪和文档传送）如今也可以在BizTalk中找到了。

在AS2解决方案中，BizTalk是一种“增值网络”，它可以提供所有功能，但不必担心与VAN相关的成本。

AS2允许贸易合作伙伴直接通过安全的HTTP相互交流。

当EDI实现中使用了AS2实现时，端口就会通过已在EDI方设置了AS2属性的标准HTTP适配器，或通过第三方BizTalk适配器公开。

不管采用哪种方式，核心理念都是相同的：

实现安全传输并验证文档。

安全传输通过证书进行处理，文档验证通过AS2、合作对象和BizTalk中的架构配置进行处理。

图6显示的示例就是一个已配置为允许通过标准BizTalkHTTP适配器进行AS2传输的合作对象。

在本例中，合作对象已设定AS2属性，并将用作HTTP适配器的一个扩展。

当文档通过HTTP送达时，BizTalk会先比较信息与AS2设置，然后再打开EDI文档。

接着会路由此EDI文档，就像通过其他任一方法传送一样。

AS2只是提供一种安全的方式，来传输数据以及任何相关的信封信息。

图6配置基础AS2属性（单击图像可查看大图）

透过防火墙传送文档

这里需要说明一个重要的概念，即如何将文档传送到位于防火墙后面的BizTalkServer，即BizTalk无法在网络上公开存取。

当SOAP或HTTP接收端口增至BizTalk时，该端口就会在本机IIS服务器上工作，并且所有已发布数据都需要发送到该本机Web服务器。

例如，在使用BizTalkWeb服务发布向导时，只能在安装了BizTalkServer的本机IIS服务器上创建Web服务。

在无法从网络外部存取此IIS服务器的环境中，必须建立某种解决方案来路由通信（请参见图7）。

有多种解决方案可以解决此问题，如将BizTalkServer置于网络的公共部分，或创建一个反向代理来通过防火墙路由要求，让BizTalk位于私人网络中。

图7透过防火墙传送文档（单击图像可查看大图）

透过防火墙的通信可以通过编程方式实现，因为将BizTalkServer放在网络中的公共存取部分通常都不可接受，此时安全性风险太高。

在公用网络的公用IIS服务器上开发Web服务时，可以采用多种方法。

其中一种是创建网关Web服务。

另一种是创建代理Web服务。

网关Web服务的建立，需要使用自定义编码（与所有Microsoft®.NETFrameworkWeb服务一样），还需要进行复杂的界面转换，以符合BizTalk预期的界面。

网关会接受来自公共网络的请求，并将其对应到向防火墙后面的Web服务发出的请求。

另一方面，代理Web服务的建立，需要修改使用BizTalkWebServices发布向导生成的内容，然后将其副本置于公共Web服务器上。

从其简单性来看，修改代理Web服务似乎是最理想的选择。

要创建代理Web服务，需要启动BizTalkWebServices发布向导。

单击该向导中相应的选项，然后定义Web服务的发布位置（请注意，虚拟目录创建位置的唯一选项就是在本地IIS服务器上）。

当向导创建Web服务时，实际上是创建了一个代理，该代理可以将来自IIS的传入呼叫重定向至BizTalkMessageBox中，以便将其路由到相应的业务流程。

此代理Web服务会自动编码，并且已经进行了预配置，只要传入发布直接进入此Web服务器即可正常运行，无需用户进行任何更改。

要使发布进入网络的公共部分并路由到此Web服务中，需要执行三个基本步骤。

第一步，创建代理到代理Web服务。

当Web服务通过向导导出后，BizTalk会将其称为代理Web服务。

若要从外部客户端调用此Web服务，就必须在可将请求路由到的公共服务器上创建代理Web服务。

此操作通过在公共IIS服务器上创建虚拟目录即可实现，其中的名称和界面要与生成的代理完全相同。

创建虚拟目录后，将原始BizTalkIIS目录下所有生成的文件复制到公用服务器上的虚拟目录中。

第二步，修改面向公用网络的Web服务，将传入的SOAP信息重新路由到承载BizTalkServer的IIS服务器上的内部代理Web服务中，而不是发布到BizTalk引擎。

要修改的代码会放在一个文件中，该文件位于发布Web服务的虚拟目录的App_Code子目录下。

此文件名称取决于正在发布的实体的名称，但始终以asmx.cs结尾。

打开此文件将显示类和Web方法声明，这就为调用实体提供了一个公共接口，并使这些请求能够直接推入BizTalkMessageBox中。

要查看这些生成的代码，需要使用WebServices发布向导导出具有双向SOAP端口的业务流程。

此向导完成后，打开App_Code目录中的asmx.cs文件查看代码。

Web方法的名称基于业务流程中在端口上定义的操作的名称。

此Web方法中，代码将接收传入发布并将其转换为可发布到MessageBox中的格式。

Web服务将传入发布推入MessageBox后，会等待一个响应，该响应对应于业务流程的双向端口中的出站请求，并将其回发给调用实体。

将此代码复制并粘贴到公用网络中的新IIS服务器后，必须对其进行修改，使其能够将传入发布转发到BizTalkServer上的Web服务中。

可以使用图8中显示的代码来修改原始的代理Web服务代码。

此代码首先覆盖原始Web服务中的Web方法，接着并不是将其发布到MessageBox中，而是加载web.config文件中的一些可配置字段，并将传入请求发布到BizTalkIIS服务器上的Web服务中。

路由到BizTalk引擎的任务，仍然由原始的代理Web服务处理。

 图8代理对代理Web服务。

复制代码

publicBTSRedirect.SyncTransResponseOperation_SyncTrans（

[System.Xml.Serialization.XmlElementAttribute（

Namespace="http:

//GuardianProStar.BizTalk.Schemas.SyncTrans.SyncTransRequest",

ElementName="SyncTransRequest"）]BTSRedirect.SyncTransRequestpart）

{

BTSRedirect.SyncTransRequestobjSyncTransReq=part;

BTSRedirect.SyncTrans