专利名称：：用于电子数据交换(edi)的xml规范的利记博彩app用于电子数据交换(EDI)的XML规范背景商业实体经常以严格的格式通过普通通信网络发送商业交易数据以便于处理交易。例如，电子数据交换(EDI)是企业利用范围不断扩展的自动化计算系统的方式之一。在EDI中，商业数据是根据诸如ANSIX12或EDIFACT等一种或多种已知且核准的标准来格式化的。例如，表示各种交易的EDI数据是作为一批描绘文档来发送的，并且每一描绘文档是根据严格的格式化规则来编码的，以确保接收这些文档的目的地应用程序能够成功地解析并使用该信息来进行下游的处理。在解析和处理EDI消息时，现有系统发送EDI数据，并且在交换期间在每一描绘文档中包括格式化规则或模式。例如，表示采购定单交易的的EDI数据包括用于釆购定单交易的模式。由此，每一EDI交易文档既包括EDI数据，又包括用于该交易的特定模式。尽管这一安排或配置便于解析EDI数据，但是它是静态的，并且使得每一交易文档的文档大小很大。另外，所包括的模式不是可共享的。换言之，如果有两个釆购定单交易文档A和B，则每一采购定单交易文档需要包括一采购定单模式，即使每一文档中的模式是相同的。并且，特别地，EDI交易是根据行或文档的数量以及发送EDI数据所需的带宽来收费的。由于商业实体使用EDI每天都发送数百万的交易，这些包括重复模式信息的大型EDI交易文档造成了对具有冗余模式信息的不必要的成本。一旦接收到EDI交易文档，目的地应用程序通常将该EDI交易文档储存在存储器区域中。目的地应用程序接着向源发送指示该交易已被接收的接收肯定应答。所储存的EDI交易随后由应用程序确认来确定包括在该交易文档中的EDI数据是否符合用于该交易类型的模式的格式化规则。在此确认期间，要求源(例如，商家或客户)等待指示该交易数据符合该格式的确认肯定应答。如果确定一个或多个交易没有被正确地格式化，则需要重新发送替换的EDI交易文档以便处理。这一等待确认延迟进一步降低了处理EDI交易的效率。概述本发明的各实施例通过将各EDI交易文件变换成具有标识各种EDI交易类型的嵌套结构或子文档的一个EDI文档来克服现有系统在处理EDI交易时的缺点。另外，本发明的各方面通过使得模式实例在运行时处理EDI交易时可用来使得EDI文档能引用模式。有利的是，本发明的各实施例自动识别与交易类型相关联的模式，并在接收到EDI交易时处理该EDI交易。根据本发明的其它实施例，在接收到EDI交易时处理该EDI交易。在本发明的又一实施例中，定义一单一元模式来表示多个模式。该单一元模式被提供给最终用户以修改该模式的特性。提供本概述以便用简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在确定所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。其它特征将部分变得清楚，部分在以下指出。附图简述图1是示出处理EDI交易的一个实现的框图。图2A到2C是示出根据本发明的一个实施例的使用电子数据交换(EDI)的交易数据的结构。图3是示出根据本发明的一个实施例的用于变换EDI交易的系统的示例性框图。图4A和4B是示出根据本发明的一个实施例的EDI交易的变换的流程图。图5A是示出根据本发明的一个实施例的EDI交易的嵌套的框图。图5B和5C是示出根据本发明的一个实施例的串行化EDI交易的框图。图6A和6B是示出根据本发明的一个实施例的包括在合并的可扩展标记语言(XML)文档格式的EDI文档中的经变换的EDI交易的屏幕截图。图7A到7D是示出根据本发明的一个实施例的自动标识EDI模式的屏幕截图。图8A是示出根据本发明的一个实施例的确认EDI交易的流程图。图8B是示出根据本发明的一个实施例的检测EDI交易中的错误的图示。图9A和9B是示出根据本发明的一个实施例的EDI确认肯定应答结构的图示。图10是示出根据本发明的一个实施例的用于修改多个EDI模式的单一元模式的屏幕截图。明的一个实施例的用于使用单一元模式来修改多个EDI模式的方法的流程图。图IIA到IID是示出其上可储存本发明的各方面的示例性计算机可读介质的框图。图12是示出其中可实现本发明的合适的计算系统环境的一个实例的框图。附录A完整描述了图IOA所示的XML模式。附录B示出了表示采购定单模式的XML格式的示例性单一元模式。在全部附图中，相应的参考标号指示相应的部分。详细描述图1是示出处理EDI交易的一个实现的框图。最初，如图1所示，源(例如，商业合伙人)102通过普通通信网络108向目的地(例如，商业客户)104发送EDI消息106，该消息可包括发票202。源102经由普通通信网络108向目的地104发送包括模式和EDI交易数据的EDI消息106。在一个实例中，EDI消息106包括批量的多个EDI交易数据，以便节省传输或带宽成本。在另一示例中，普通通信网络106可以是诸如内联网等私有的专用网络，或诸如因特网等公共网络。在另一示例中，普通通信网络108包括一个或多个网络协议，诸如FTP、HTTP、Kermit、Xmodem、帧延迟、EDIINT、3780Bisync⑧等，以便于在合伙人之间传送EDI消息。源102通过打开经由普通通信网络108与目的地104的连接会话(例如，安全套接字连接会话)来发起EDI消息106的传输。一旦打开了连接会话，源102就向目的地104发送EDI消息106。目的地104上的一组EDI转换器系统110接收EDI消息106，并且该EDI转换器系统110经由普通通信网络108向源102发送指示该EDI消息已被接收到的接收肯定应答112。常见的是接收确认应答在源102关闭会话连接之前被发送会返回给源102。一旦接收到EDI消息106，EDI转换器系统110就解析并处理与EDI交易相关联的EDI数据。如本领域的技术人员已知的，对EDI交易的解析和/或解码涉及标识各种EDI标准、模式规范等的一个或多个步骤。在此期间，EDI转换器系统IIO将经解析或解码的EDI数据发送给下游应用程序114以处理该经解析或解码的EDI数据。例如，下游应用程序114可以是处理发票的会计应用程序，或者是用于处理采购定单数据的软件。由此，下游应用程序114能够确认所接收到的EDI数据在解析和解码之后是否符合在模式中指定的格式化规则。如果所接收到的EDI数据符合模式规则，则下游应用程序114向源102发送一确认肯定应答116。另一方面，如果该接收到的EDI数据包括错误或是无效的，则下游应用程序114可以向源发送指示所接收到的EDI数据的错误的错误通知。确认肯定应答116通常以接收肯定应答的发送之后的延迟来发送给源102。在其它实现中，经解析的EDI数据被储存在一数据库或数据存储(未示出)中以等待确认。由此，源102经常被要求等待确认肯定应答116来查明该EDI数据能够被目的地104正确地处理。图2A到2C是示出根据本发明的一个实施例的使用电子数据交换(EDI)的交易数据的结构的图示。图2A示出了使用ANSIX12格式的发票EDI交易文档的表示的示例。在此示例中，发票202包括多个段或部分(见图2C中的X12EDI交换结构218的概观)，诸如功能组204部分，它可包括发票202的附加信息。例如，在供应链部门中，本领域的技术人员已知功能组204中的信息或值与交换部分(例如，交换控制头)中的信息或值是相同的，如图2C所示。在另一示例中，功能组204中的信息或值包括标识大企业内的商业或营业单元的值或标识符。发票202还包括头部分206，它包括诸如商业客户信息等信息。在此示例中，头部分206包括商业客户名称"ABC公司"以及地址"密苏里州，圣路易市，第六大街0887号，63101"。在一个实施例中，头部分206包括用于接收确认肯定应答的目的地信息，参见以下对图8、9A和9B的讨论。发票202还包括示出以循环210组织的一个或多个数据段212的细节表部分208。例如，循环210包括一组语义上相关的数据段，并且对本领域的技术人员而言，这些段可以根据ANSIX12.6是有界或无界的。根据ANSIX12或EDIFACT格式，在EDI交易文档中可包括其它段类型和部分以及相应的信息，而不背离本发明的范围。例如，图2B示出了包括在要在目的地104处处理的同一EDI消息106中的一个或多个交易类型。发票214和采购定单216EDI交易文档被包括在EDI消息106中，因为发票214和采购定单216与同一客户，即"ABC公司"相关。其它各组相关交易文档可以作为EDI消息106被包括在交换中。在一个实施例中，用于一个目的地或客户的EDI文档可以批量发送。还可以理解，要求每一EDI交易类型都符合与该交易类型相关联的模式。例如，特别地，发票交易模式可要求关于用于商家或买家的名称的最大或最小字符长度的限制。采购定单交易模式可要求小数点之后的最大位数。在另一示例中，用于各种交易类型的模式可以指定一特定字段是强制的，而其它字段是可任选的。现有的实现在向诸如目的地104等客户发送EDI交易时在EDI交易文档中包括交易模式。尽管这些实现便于对EDI交易的解码，但是它们要求模式设计者在向商业合伙人发送EDI交易之前花费大量时间来设计或配置该模式。并且，由于合伙人之间的商业协定的修改，需要对这些模式的后续修改来重新设计该模式。由此，本发明的实施例通过将EDI消息变换成具有根据交易类型来组织一个或多个EDI交易的嵌套结构或子文档的一个合并的EDI文档克服了现有实现的缺陷。EDI文档还包括用于表示与交易类型相关联的多个模式的乳模式(uber-schema)。在另一实施例中，一运行时模式映射变换多个模式以便在目的地104处在运行时处理。现在参考图3，一框图示出了用于根据本发明的一个实施例来变换EDI交易的系统302的框图。系统302包括源304，源可以是与目的地306或客户交易商业的商家。例如，源304可以是诸如向购买计算设备的公司客户销售大量商品的电子消费品零售商店等商家。在另一示例中，源304可以是健康护理提供者，诸如医院或药店，并且向健康护理保险公司或交换所发送EDI数据以便提交主张或符合健康保险便利及责任法案(HIPAA)。在一个实施例中，源304和目的地306包括诸如图12中的计算机130等一个或多个计算设备，用于批量发送EDI文档。最初，源304发送包括多个EDI文档的EDI消息310。每一EDI文档包括对应于一交易类型(例如，发票、采购定单、应付款等)的至少一个EDI交易。还参考图4A，一流程图示出了根据本发明的一个实施例的变换EDI交易。在源304打开通信网络308上的连接会话以与目的地306通信之后，源304向目的地306的EDI引擎312发送EDI消息310。在一个实施例中，EDI引擎312包括执行计算机可执行指令、例程或函数的一个或多个计算设备(例如，计算机130)。在402处，EDI引擎312接收包括多个EDI文档的EDI消息310。在404处，EDI弓|擎312标识包括在多个EDI文档中的EDI交易。使用以上的ANSIX12示例，EDI引擎312通过标识图2C所示的各种数据头和数据段(例如，ISA、GS等)来解码或解析X12发票，以确定交易中的EDI数据。在另一实施例中，EDI引擎312还标识包括在多个EDI文档中的各种模式来确定用于该交易类型的特定格式化规则。在406处，EDI引擎312从该批多个EDI文档中生成合并的EDI文档314。在一个示例中，EDI引擎312在410处生成合并的EDI文档314作为具有XML结构标记标签的XML文档。例如，不像其中每一交易被组织为一文档的现有的实现，本发明的各实施例将多个EDI文档中的EDI交易组织成一个XML文档，该XML文档不仅定义了个别的交易集，而且还通过捕捉EDI数据的所有方面，包括段、循环、字段、定界符等，定义了交换。在一个示例中，图6A示出了包括一个或多个EDI交易(诸如"PO(采购定单)")的示例性合并的XMl文档。在又一实施例中，该合并的EDI文档314包括表示由EDI交易引用的多个模式的乳模式。例如，该乳模式被包括在EDI交易集中，并且被嵌入或缝合在每一EDI交易的功能组和信封段(envel叩esegment)内，使得最终用户无需为期望被包括在EDI消息310中的每一交易集创建一特定模式。作为一个示例，图6B示出了一屏幕截图，其示出了根据本发明的一个实施例的合并的EDI文档314中的XML格式的乳模式。采用这一设计，合并的EDI文档的交换减少了在EDI文档314中包括对应于一交易类型的一个或多个模式的需求。本发明的各实施例还减少了传输之前的模式设计和开发时间。在另一实施例中，在图4B的412处，EDI引擎312用运行时模式映射或净荷模式来变换合并的EDI文档。在414处，EDI引擎312为合并的EDI文档314中的EDI交易创建子文档或嵌套结构(见表1和2中的附加描述)。在一个替换实施例中，该合并的EDI文档314是用净荷模式(例如，运行时模式映射)来变换的，并且还可在416处在结构上进行变换。或者，合并的EDI文档314可被发送到下游应用程序316以便在418处在没有结构变换的情况下进行处理。在420处，具有子文档或嵌套结构的合并的EDI文档314也被发送到下游应用程序316以供处理。可以理解，可以使用除用于合并的EDI文档314的XML之外的、带有以可标识结构来定义并组织EDI交易的标记标签的其它格式，而不背离本发明的范围。在另一实施例中，描述了其上可储存上述本发明的各方面的计算机可读介质1102(在图11A中)。例如，接口组件1104、标识组件1106以及变换组件1108可被包括在执行以上讨论的一个或多个操作的EDI引擎312中。还可以理解，图4A所示的方法可以由源304来执行，使得源304可以在传输之前减小交换的大小。由此，合并的EDI文档314的嵌套结构或子文档减少了行数，这还可以减少当根据行数来收费时的发送EDI数据的成本。例如，表1示出了合并的EDI文档中的嵌套结构中的三个EDI交易，以及各自包括这三个EDI交易中的一个的相应的三个原始EDI文档。嵌套结构中的EDI交易用于下游处理的展平的EDI事务交易#1的开始PO头段PO行1PO进度表1PO进度表2PO行1总和PO行2PO进度表2.1PO行2总和PO总和交易#1的结束交易Wa的开始PO头段PO行1PO进度表l.lPO行1总和PO总和交易Wa的结束交易Wb的开始PO头段PO行1PO进度表1.2PO行1总和PO总和交易Wb的结束交易Wc的开始PO头段PO行2PO进度表2.1PO行2总和PO总和交易Wc的结束表l:嵌套结构(左列)和三个EDI文档(右列)中的三个EDI交易在操作中，假设诸如雇主A等健康护理发起者需要向诸如健康护理提供者B等付款人发送诸如HIPAA834文档等EDI消息。用于这一交换的模式要求雇主A提供健康护理受益人/接收者(例如，雇员及其家属)的福利的细节。由此，雇主A通常包括发起者和付款人的详细信息。发起者和付款人的该详细信息对于所有受人都是共同的，并且对正在接收由雇主A发起的福利的每一雇员或家属重复。本发明的各实施例创建一嵌套结构，使得每一成员可连同发起者和付款人的详细信息的副本一起以一个EDI文档中的类似循环的逻辑来创建，而非如在现有的EDI实现中那样对数千个雇员和家属重复相同的发起者和付款人信息。图5A是示出根据本发明的一个实施例的EDI交易的嵌套的框图。例如，在502处，在目的地(例如，目的地306)处从源(例如，源304)接收EDI消息(例如，EDI消息310)。在504处，生成一合并的EDI文档，其中各EDI交易被包括在一嵌套结构中或作为子文档来包括。在一个示例中，剥去信封/控制段(例如，ANSIX12格式中的ISA/GS/GE/IEA段)，并通过接收管线解析交易集(ST/SE)来对每一交易集生成多个XML子文档。在一个实施例中，多个XML子文档被存放在一消息箱中。在506处，目的地处的接收管线执行对传入交换的确认，并生成适当的确认肯定应答(将在图8、9A和9B中详细讨论)。在一个实施例中，接收管线还更新校验和和商业总和。如上所述，合并的EDI文档314可以由下游应用程序316来处理。由此，该合并的EDI文档被发送给一发送端口，并且在508处，该发送端口发送EDI子文档中的EDI交易。在一个实施例中，与发送端口相关联的发送管线串行化XML子文档，并传送个交换，其中在发送管线处更新段的计数。在一个实施例中，当接收到一EDI交换时，确认该交换。如果没有任何确认错误，则根据其模式将每一交易集转换成XML格式。由此，一个EDI交换可包含采购定单和发票文档。采购定单可以被转换成符合采购定单模式的XML。同样，发票将被转换成发票XML。图5B示出了XML格式的来自EDI交换的示例性采购定单。当该采购定单文档由图5A中的发送侧处理时，它在处理了信封段之后被转换成EDI格式514。图5C示出了由发送端口从图5B中的XML格式产生的示例性文档。在一个实施例中，EDI格式514包括两个信封段(例如，以ISA和GS开头的行)。类似地，EDI格式514在该文档的末尾包括两个信封段，GE和正A。如图所示，包括在ST和SE段之间的数据是用于原始交易集的数据。在如图5B和5C所示的以上示例中，SE01的值(见箭头512)是"14"，并且是由发送端口动态计算的。尽管串行化一EDI文档，但是EDI引擎(例如，EDI引擎312)的发送侧跟踪一交易集中存在的段数。基于该值，确定SE01的值。在源304生成合并的EDI文档314以包括来自多个EDI文档的EDI交易的情况下，本发明的各实施例包括将所包括的EDI交易组织在一嵌套结构中。在另一示例中，本发明的各实施例允许从源接收合并的EDI文档314的目的地306为了后向兼容性或为了适应只能处理每一文档仅包含一个交易的EDI文档的下游应用程序316而从合并的EDI文档314中还原多个EDI文档。本发明的替换实施例允许具有嵌套结构中的EDI交易的合并的EDI文档跟踪原始的多个EDI文档或与这些原始文档相关。例如，表2示出了将EDI交易从合并的EDI文档314转换成多个EDI文档。<table>tableseeoriginaldocumentpage13</column></row><table>表2:合并的EDI文档转换在表2所示的示例中，对嵌套结构中的EDI交易的处理通过标识预定的子文档创建断点(SubDocumentCreationBreakPoint)(例如，描述一子文档在父文档中的何处开始的"\"标记)以生成多个子文档来开始。根据表2，在列A1中所示的合并的EDI文档可根据在模式中的BB循环处定义的子文档创建断点而被拆分成三个交易BB1*1-BB2*1、BB1*2以及BB1*3-BB2*3。在列A2中，交易集BB1*1-BB2*1被组织或拆分(由粗体文本表示)成一单独的文档，而在列A3中，交易BB1*2被组织在第二文档中(由下划线文本表示)。类似地，交易集BBP3-BB2—3被组织成要由下游应用程序316处理的第三EDI文档(由斜体文本表示)。通过将包括在多个EDI文档中的EDI交易变换成合并的EDI文档314，本发明的各实施例使得目的地306或源304能够在变换期间有效地标识包括在每一EDI文档中的多个模式。另外，本发明的至少一方面使得目的地306在变换了合并的EDI文档之后在连接会话仍然被打开的时间段内生成要在返回给源304的确认肯定应答。换言之，本发明的各方面将目的地306配置成在接收EDI交易的同时自动标识多个模式并确认EDI交易。现在参考图7A-7D，示出了根据本发明的一个实施例的自动标识EDI模式的一系列屏幕截图。图7A示出了典型的ANSIX12采购定单模式。模式是由与其相关联的DocType(文档类型)来标识的。DocType是诸如名称空间和根节点名称等配置项的组合。如图7A所示，该屏幕截图的左列702示出了一模式的分层结构。在此示例中，左列702示出了一模式结构。中列704指示了该模式的XML代码。右列706指示了包括在该模式中的特性或目标名称空间。在一个实施例中，DocType具有以下格式X12格式的"DocType=TargetNamespace'#，RootNodeName"，这将在以下详细描述。可以理解，尽管在图7A中描述了X12模式，但是可以使用诸如EDIFACT模式等其它模式格式而不背离本发明的范围。DocType的根节点具有以下X12格式之一"X12_{Version}_{Tsld}"。在此示例中，配置项"rootnode"(根节点)的值是"X12_00401—850"，如由框708所示。换言之，"00401"是文档的版本，并且它是在运行时处理期间确定配置或实例的一条动态信息。类似地，"850"是TsId，它是所处理的模式的交易标识(ID)，并且是从输入实例中确定的。在此示例中，交易ID"850"表示采购定单，如由框710所指示的。并且，目标名称空间由右列706中的框712来指示。在另一示例中，为解码或标识EDIFACT格式的模式，EDIFACT模式当前具有以下格式"Efact_{Version}」Tsid}"。换言之，所有EDIFACT模式都具有以"Efact"开头的根节点名称，并且Version和Tsid的定义与X12格式的相同。使用图3作为一个示例，当目的地306从源304接收到EDI文档时，EDI交易可随文档一起包括交易ID"850"。然而，版本信息或目标名称空间信息是在运行时确定的，并且这些配置项的值可以在不同的级别下配置。由此，在应用了根据EDI标准(X12或EDIFACT)的规则以根据相应的交易类型(例如，采购定单、发票等)来解码EDI交易之后，EDI引擎312标识经解码的EDI交易中的配置项。在一个实施例中，EDI引擎312从一个或多个配置级别标识配置项，诸如合伙人级别和发送应用程序级别、全局级别、管线级别或默认级别。例如，图7B示出了显示参与者级别配置中的配置项的屏幕截图。在此示例中，用于以上图7A所示的合伙人的交易ID850被配置成使用如上所示的目标名称空间和版本信息。对于所有其它文档类型，可使用默认值，因为如由框714所指示的，默认标志或参数被打开。在另一示例中，另一贸易合伙人可基于在商业贸易合伙人之间建立的商业协定在合伙人级别配置中设置其它特定配置项。本发明的各实施例在自动标识模式时通过确定由贸易合伙人从一个或多个配置级别设置的特定值来标识配置项的值，而非静态地确定配置项的值。在一个实施例中，由于发送者Id和交易Id的特定组合，参与者级别配置中的配置项的值可以被配置为与图7A中的DocType所示的不同的值。例如，在X12中，每一发送者Id可以表示企业内的一特定部门。由此，一个企业中的发送者ID可以指"硬件商品"部门，而另一发送者ID可以指同一企业内的"软件商品"部门。由此，本发明的各实施例识别这些不同的配置，并相应地标识模式。结果，来自一个企业的相同的采购定单可以经历不同的模式标识过程，使得例如根据配置项的值在合并的EDI文档314中以XML生成适当且不同的EDI数据。还可以理解，一个或多个附加配置项可由特定的商业合伙人配置或设置而不背离本发明的范围。例如，一个合伙人可设置最少量的配置，而另一合伙人可在其参与者级别配置中定义详细的配置项。现在参考图7C，示出了具有其参与者级别配置的EDIFACT模式的屏幕截图。在此示例中，与X12模式不同，目标名称空间可以基于发送者应用程序ID(可任选)(诸如716中的UNG1.2和718中的UNG2.2)、版本720(UNG8)、以及交易集ID722的特定组合来配置。换言之，有可能对一发票EDI文档有多个配置，每一配置都具有唯一的应用程序id。在此情况下，可在运行时使用匹配特定应用程序的目标名称空间。在其中没有配置发送者应用程序ID的情形中，发送者应用程序ID值可以与来自携带相同的交易ID的现有记录(例如，日志文件)的任何值进行匹配。在找到多个匹配的情况下，使用默认目标名称空间来确保当存在歧义时使用适当的默认值。图7D是示出用于X12模式的全局级别配置的屏幕截图。在此示例中，在诸如目标名称空间或版本等配置项未由交易合伙人指定的情况下，使用全局级别配置中的配置项的值。在此示例中，框724指示对版本和目标名称空间没有配置任何值。由此，在运行时不修改配置项的值。在其中未配置全局级别下的某些缺少的配置项的情况下，使用管线级别或运行时级别配置中的配置项的值。由此，如果在全局级别没有配置目标名称空间，则使用来自管线级别配置的值。在一个实施例中，管线级别配置中的值可由用户设置。在另一实施例中，图11B示出了其上可储存本发明的各方面的计算机可读介质lllO。例如，接口组件1112从源批量接收EDI文档，其中每个有EDI文档具有对应于一交易类型的至少一个EDI交易。交易组件1114通过应用依照EDI标准(例如，X12或EDIFACT)的规则，根据相应的交易类型来解码EDI交易。配置组件1116对解码的EDI交易中的每一EDI交易标识一个或多个配置项中的值。模式组件1118基于配置项的值来确定一个或多个模式类型。在一替换实施例中，可在运行时修改在以上各节中描述的配置项的值。由此，对于交易类型、目标名称空间、版本的值可以在EDI引擎312处理EDI文档(即，自动标识模式)之后修改。在这一实施例中，改变将在尚待处理的后续文档上反映。本发明的这一动态实现使得目的地306处的用户能够在运行时期间而非在EDI文档从源304发送之前的模式设计/配置期间配置值。在操作中，自动模式标识使得EDI合伙人能够流线化对EDI文档的处理。不像其中需要对每一合伙人并对每一文档类型配置接收连接和发送连接的现有的实现，EDI引擎312启用了自动模式标识，使得配置项的值在运行时期间标识和确定，从而使得EDI商业合伙人在处理EDI数据时能够更灵活。可以回想，本发明的至少另一方面包括在接收到EDI数据时生成确认肯定应答，图8A是示出这一特征的流程图。在802处，从源(例如，源304)向目的地(例如，目的地306)发送EDI消息(例如，EDI消息310)。在804处，在目的地处接收包括EDI交易的EDI消息。接着，在806处，通过确定该EDI消息是否预期送往正确的接收方，来确定EDI消息的传输是否有效。如果确定EDI消息的传输无效，则延缓对EDI消息的处理，并且在808处生成一交换失败肯定应答。如果确定EDI消息的交换是有效的，则接着在810处确定EDI交易组是否包括错误。如果组包括错误，则延缓对EDI交易组的处理，并且在812处生成一功能失败肯定应答。例如，EDI规范可定义可在组和交易集级别处找到的多个错误。表3提供了适用于X12EDI交换的常见错误的列表。<table>tableseeoriginaldocumentpage16</column></row><table>4功能组头和尾中的组控制号不一致5包括的交易集的数量不匹配实际计数表3:功能组错误一与GS/GE段有关的错误例如，EDI引擎312通过标识EDI消息中的行/段GS的第六个值来确定一错误，诸如错误代码4，"功能组头和尾中的组控制号不一致"。在图8B中，行GS532的第六个值具有值"9"(如由框528所指示的)。在确认EDi交易时，本发明的各实施例确定在行GE534的第二个值中是否也存在相同的值。如图8B所示，行GE534的第二个值是"10"(如由框530所指示的)。有了这一差异，确定在该EDI消息中存在错误。在另一示例中，通过标识GS-GE段之间的交易集来检测错误代码5，"所包括的交易集的数量不匹配实际计数"。如图8B所示，有一个GS-GE段，而GE行的第一个值是"02"，指示有两个交易集。由此，该功能组有错误。然而，如果确定组中没有错误，则接着在814处通过评估依照X12或EDIFACT格式的格式化规则和依照包括在EDI交易中的模式的规则来确定每一EDI交易是否有效。如果确定EDI交易无效，则延缓对EDI交易的处理，并在16处生成功能失败肯定应答。例如，表4提供了常见的交易错误的列表。代码描述一来自AK502代码列表1交易集不支持2缺少交易集尾头和尾中的交易集控制号不匹配4所包括的段的数量不匹配实际计数5一个或多个段有错误6缺少或无效的交易集标识符7缺少或无效的交易集控制号表4:交易集错误一与ST和SE内的数据有关的错误使用图8B作为一个示例，EDI引擎(例如，EDI引擎312)通过评估ST和SE之间的段(行)数来标识错误代码4，"所包括的段的数量不匹配实际计数"。在此示例中，该数量是"12"，而SE行中的第一个值是14。由此，在该交易集中有错误，并且这一错误代码可被包括在功能失败肯定应答中。在一个实施例中，EDI引擎(例如，EDI引擎312)可参考或了解各种错误条件或EDI交易规则。在处理EDI文档时，EDI引擎312确保没有一个EDI格式化规则被违反。在任何违反的时候，EDI引擎312以交换或功能级别肯定应答的形式适当地报告。或者，如果EDI交易有效，则目的地处的EDI引擎312在818处继续处理EDI交易。在820处，生成指示EDI交易有效的确认肯定应答。在一个实施例中，当接收并确认EDI消息、EDI组禾P/或EDI交易时，EDI引擎312可比较并生成合并的确认肯定应答。在另一实施例中，EDI引擎与接收EDI消息、EDI组和/或EDI交易基本同时地生成合并的确认肯定应答。在824处，将所生成的确认肯定应答返回给源，源在826处接收该确认肯定应答。在一个实施例中，源打开用于发送EDI消息的连接会话并在关闭该同一连接会话之前接收确认肯定应答。由此，在文档确认期间没有数据库或数据存储访问或盘1/0，因为该确认过程是在运行时期间或在EDI交易的接收期间处理的，如由图3的箭头318所示。在又一实施例中，该确认过程可以通过在运行时插入处理程序来扩展。在一个替换实施例中，可以在接收EDI消息/交易的同时生成并向单独的位置(这一位置信息可以在头部分106中找到)发送不同的确认肯定应答类型。由此，本发明的各实施例在一个或多个阶段中(例如，在确认了交换的一方面之后)生成并发送确认肯定应答，或在单个阶段中生成并发送合并的肯定应答。在又一实施例中，这些肯定应答可以被配置成在同一或新的套接字连接会话上传送到不同的目的地，如由图3中的箭头320所指示的。例如，假设模式或格式化规则指示针对采购定单的确认肯定应答被配置成发送给企业的客户服务部门，而发票确认肯定应答被配置为发送给同一企业的会计部门。本发明的各方面允许通过打开新的连接会话来向正确的目的地发送相应的肯定应答。图9A示出了用于X12格式化EDI交易的确认肯定应答，而图9B示出了用于EDIFACT格式化EDI交易的确认肯定应答。在另一实施例中，图IIC示出了其上可储存本发明的各方面的计算机可读介质。例如，接口组件1122、肯定应答组件1124、以及确认组件1126可被结合并集成到EDI引擎312中用于执行如图8A所描述的一个或多个步骤。本发明的其它方面允许修改EDI模式而无需最终用户有EDI模式开发者那样多的知识。例如，假设在企业内建立一新的部门，但是对该新部门没有采用定制EDI模式或规则。代替请求EDI模式开发者为该新部门设计一特定的EDI模式，本发明的各实施例定义一元模式来表示所有模式，使得各模式的特性被呈现给最终用户以供修改。图10A是示出根据本发明的一个实施例的用于修改多个EDI模式的单一元模式的屏幕截图。在窗格1002中，单一元模式的结构被呈现给最终用户。一旦最终用户加亮了一特性(由包围"MaxOccurs(最大出现次数)"的虚线框指示)，就在窗格1004中加亮一相应的特性代码段，从而允许最终用户修改该特性的值。在一个实施例中，向最终用户提供实施如图10A所示的本发明的方面的用户界面(UI)。附录A完整地描述了图IOA所示的XML模式。图10B是示出根据本发明的一个实施例的用于使用单一元模式来修改多个EDI模式的方法的流程图。在1006处，通过对多个EDI模式中的数据进行解码来标识表示这多个EDI模式的单一结构。在一个示例中，诸如图11D中的数据结构1128等单一结构通过捕捉以下数据中的一个或多个来表示多个EDI模式1.每一EDI模式包括具有名称的根元素；2.根元素包括可以或者是Lo叩(循环)或者是Segment(段)的重复数据块；3.每一Loop具有以下结构a.Name—循环的名称b.Block—数据元素集合c.MinOccurs—最小出现次数d.MaxOccurs—最大出现次数4.每一Segment具有各种特性a.Name—段的名称b.Tagld—段的标签IDc.MinOccurs—最小出现次数d.MaxOccurs—最大出现次数e.数据元素列表5.每一数据元素包括元素集合，每一元素可以或者是Composite(复合)元素或者是Simple(简单)元素6.每一SimpleElement(简单元素)具有各种特性a.Name—元素的名称b.MinOccurs—最小出现次数c.MaxOccurs—最大出现次数d.MinLength—最小数据长度e.MaxLength—最大数据长度f.DataType—数据类型，允许的值是A、AN、ID、R、N、Date(日期)、Time(时间)一对每一EDI数据类型有一个g.AllowedValues—允许的值集，仅在元素为类型ID时才适用例如，数据结构1128包括第一数据字段1130，该字段包括与多个EDI模式中的每一个的根元素相关联的根数据。该数据结构还包括一个或多个第二数据字段1132，该字段包括表示多个EDI模式中的每一个的一个或多个数据块的数据。一个或多个第二数据字段中的数据是根据第一数据字段1130中的根数据来定义的。在1008处，确定要包括在单一结构中的特性。该特性定义了多个EDI模式的特征。例如，具有特性值"purchaseorder"(采购定单)的根元素指示该单一结构的特征对应于诸如图7A所示的采购定单模式。使用具有特性值的单一结构，在1010处，根据所定义的特征和单一结构为用户定义单一元模式。所定义的元模式对应于多个EDI模式。在1012处，将所定义的元模式中所确定的特性提供给最终用户，使得最终用户能够如图10A所示修改多个EDI模式中的每一个的特征。附录B示出了表示具有以下结构的采购定单模式的XML格式的示例性单一元模式1.PurchaseOrderDetail(采购定单细节)段；2.由Lindtem(行项)和ShippingAddress(发货地址)段构成的Loop3.Notes(注解)段图12示出了计算机130形式的通用计算设备的一个示例。在本发明的一个实施例中，诸如计算机130等计算机适用于此处所示并描述的其它附图。计算机130具有一个或多个处理器或处理单元132以及系统存储器134。在所示的实施例中，系统总线136将包括系统存储器134的各种系统组件耦合到处理器132。总线136表示任意几种总线结构中的一种或多种，包括存储器总线或存储器控制器、外围总线、加速图形端口、以及使用各种总线体系结构中的任一种的处理器或局部总线。作为示例而非局限，这类体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子技术标准协会(VESA)局部总线以及外围部件互连(PCI)总线(也称为小背板(Mezzanine)总线)。计算机130通常具有至少某种形式的计算机可读介质。计算机可读介质可包括易失性和非易失性、可移动和不可移动介质，并且可以是可由计算机130访问的任何可用介质。作为示例而非局限，计算机可读介质包括计算机存储介质和通信介质。计算机存储介质包括以用于储存诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任一方法或技术实现的易失性和非易失性，可移动和不可移动介质。例如，计算机存储介质包括RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储设备、或可以用来储存所期望的信息并可由计算机130访问的任一其它介质。通信介质通常以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并包括任一信息传送介质。本领域的技术人员熟悉已调制数据信号，它以对信号中的信息进行编码的方式设置或改变其一个或多个特征。诸如有线网络或直接连线连接等有线介质，以及诸如声学、RF、红外和其它无线介质等无线介质都是通信介质的示例。上述任一的组合也应当包括在计算机可读介质的范围之内。系统存储器134包括可移动和/或不可移动、易失性和/或非易失性存储器形式的计算机存储介质。在所示的实施例中，系统存储器134包括只读存储器(ROM)138和随机存取存储器(RAM)140。基本输入/输出系统142(BIOS)包括如在启动时帮助在计算机130内的元件之间传输信息的基本例程，它通常储存在ROM138中。RAM140通常包含处理单元132立即可访问和/或当前正在操作的数据和/或程序模块。作为示例而非局限，图12示出了操作系统144、应用程序146、其它程序模块148和程序数据150。计算机130也可包括其它可移动/不可移动、易失性/非易失性计算机存储介质。例如，图12示出了对不可移动、非易失性磁介质进行读写的硬盘驱动器154。图12还示出了对可移动、非易失性磁盘158进行读写的磁盘驱动器156,以及对可移动、非易失性光盘162，如CDROM或其它光介质等可移动、非易失性光盘162进行读写的光盘驱动器160。可以在示例性操作环境中使用的其它可移动/不可移动、易失性/非易失性计算机存储介质包括但不限于，磁带盒、闪存卡、数字多功能盘、数字录像带、固态RAM、固态ROM等等。硬盘驱动器154以及磁盘驱动器156和光盘驱动器160通常通过非易失性存储器接口，如接口166连接到系统总线136。上文讨论并在图12中示出的驱动器或其它大容量存储设备及其关联的计算机存储介质为计算机130提供了计算机可读指令、数据结构、程序模块和其它数据的存储。例如，在图12中，示出硬盘驱动器154储存操作系统170、应用程序172、其它程序模块174和程序数据176。注意，这些组件可以与操作系统144、应用程序146、其它程序模块148和程序数据150相同，也可以与它们不同。这里对操作系统170、应用程序172、其它程序模块174和程序数据176给予不同的标号来说明至少它们是不同的副本。用户可以通过输入设备或用户界面选择设备，如键盘180和定位设备182(通常指鼠标、跟踪球或触摸垫)向计算机130输入命令和信息。其它输入设备(未示出)可包括话筒、操纵杆、游戏手柄、圆盘式卫星天线、扫描仪等等。这些和其它输入设备通常通过耦合至系统总线136的用户输入接口184连接至处理单元132，但是也可以通过其它接口和总线结构连接，如并行端口、游戏端口或通用串行总线(USB)。监视器188或其它类型的显示设备也通过接口，如视频接口190连接至系统总线136。除监视器188之外，计算机通常包括其它外围输出设备(未示出)，如扬声器和打印机，它们可通过输出外围接口(未示出)连接。计算机130可以使用到一个或多个远程计算机，如远程计算机194的逻辑连接在网络化环境中操作。远程计算机194可以是个人计算机、服务器、路由器、网络PC、对等设备或其它常见的网络节点，并通常包括许多或所有相对于计算机130所描述的许多或所有元件。图12描述的逻辑连接包括局域网(LAN)196和广域网(WAN)198，但也可包括其它网络。LAN136和/或WAN138可以是有线网络、无线网络或其组合等等。这类网络环境常见于办公室、企业范围计算机网络、内联网以及全球计算机网络(例如，因特网)。当在局域网环境中使用时，计算机130通过网络接口或适配器186连接至LAN196。当在广域网环境中使用时，计算机130通常包括调制解调器178或用于通过WAN198，如因特网建立通信的其它装置。调制解调器178可以是内置或外置的，它通过用户输入接口184或其它适当的机制连接至系统总线136。在网络化环境中，相对于计算机130所描述的程序模块或其部分可储存在远程存储器存储设备(未示出)中。作为示例而非局限，图12示出远程应用程序192驻留在存储器设备上。示出的网络连接是示例性的，也可以使用在计算机之间建立通信链路的其它手段。一般而言，计算机130的数据处理器借助在不同时刻储存在计算机的各种计算机可读存储介质中的指令来编程。程序和操作系统通常例如在软盘或CD-ROM上分发。从这些盘上，它们被安装或加载到计算机的次级存储器中。在执行时，它们被至少部分地加载到计算机的主电子存储器中。当这些和其它各种类型的计算机可读存储介质包括用于实现在下文中结合微处理器或其它数据处理器描述的步骤的指令或程序时，此处所描述的本发明的各方面包括这种介质。此外，当依照此处所描述的方法和技术来编程时，本发明的各方面包括计算机本身。出于图示的目的，诸如操作系统等程序和其它可执行程序组件此处被示为离散的框。然而，可以认识到，这些程序和组件在各种时刻驻留在计算机的不同存储组件中，并且由计算机的数据处理器来执行。尽管结合包括计算机130的示例性计算系统环境描述，但本发明的各实施例可以使用众多其它通用或专用计算系统环境或配置来操作。该计算系统环境并不旨在对本发明的任何方面的使用范围或功能提出任何局限。此外，也不应将该计算系统环境解释为对该示例性操作环境中示出的任一组件或其组合具有任何依赖或需求。适用于本发明的各方面的众所周知的计算系统、环境和/或配置的示例包括但不限于，个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、移动电话、网络PC、小型机、大型计算机机、包括任一上述系统或设备的分布式计算环境等等。本发明可在诸如程序模块等由一个或多个计算机或其它设备执行的计算机可执行指令的一般上下文环境中描述。一般而言，程序模块包括但不限于，执行特定的任务或实现特定的抽象数据类型的例程、程序、对象、组件、数据结构等等。本发明的各方面也可以在其中任务由通过通信网络链接的远程处理设备来执行的分布式计算环境中实践。在分布式计算环境中，程序模块可以位于包括存储器存储设备的本地和远程计算机存储介质中。接口可以是诸如Java2平台企业版本(J2EE)、COM或分布式COM(DCOM)示例中的紧耦合的同步实现。作为替代或除此之外，接口可以是诸如web服务(例如，使用简单对象访问协议)中的松耦合的异步实现。一般而言，接口包括以下特征的任一组合紧耦合的、松耦合的、同步和异步。此外，接口可符合标准协议、专有协议、或标准和专有协议的任何组合。此处所描述的接口可以都是单个接口的一部分，或者可以被实现为单独的接口或其中的任何组合。接口可以本地或远程地执行以提供功能。此外，接口可包括比此处所示或所描述的更多或更少的功能。在操作中，计算机130执行诸如在图中所示的计算机可执行指令来实现本发明的各方面。此处所示且描述的本发明的各实施例中的操作的执行或实现顺序不是必要的，除非另外指定。即，操作可以用任何顺序来执行，除非另外指定，且本发明的各实施例可包括比此处所公开的更多或更少的操作。例如，可以构想，在另一操作之前、与其同时或之后执行或实现特定操作是在本发明的各方面的范围之内。本发明的各实施例可以用计算机可执行指令来实现。计算机可执行指令可被组织成一个或多个计算机可执行组件或模块。本发明的各方面可以用任意数量或组织的这些组件或模块来实现。例如，本发明的各方面不限于在图中所示并在此处所描述的具体计算机可执行指令或具体组件或模块。本发明的其它实施例可包括具有比此处所示并描述的更多或更少功能的不同的计算机可执行指令或组件。当介绍本发明或其实施例的各方面的元素时，冠词"一"、"一个"、"该"和"所述"意指存在一个或多个元素。术语"包括"、"包含"和"具有"旨在是包含性的，且意味着除所列出的元素之外还可以有其它元素。由于可在以上构造、产品和方法中作出各种改变而不背离本发明的各方面的范围，因此包含在以上描述中并在附图中所示的所有主题都旨在被解释为说明性的而非限制的意义。附录A节1:以XML格式表示EDI模式的元模式<xmlversion="1.0"encoding="utf-16"><xs:schemaxmlns:b="http:〃schemas.company.com/BizApp/2003"xmlns="http:〃schema.company.com/EdiClient/MetaSCHEMA"targetNamespaee="http:〃schema.company.com/EdiClient/MetaSCHEMA"xmlns:xs="http:〃www.w3.org/2001/XMLSchema">〈xs:elementname="EdiSchemaRoot"><xs:complexType><xs:scqucncs〉<xs:elementname="RootElementName"type="xs:string"/><xs:elementref="Block"/></xs:ssqucncx></xs:complexType></xs:element>〈xs:elementname="Block"type="BlockType"/><xs:elementname="Segment"><xs:complexType><xs:ssqucncc>〈xs:elementname="Name"type="xs:string"/><xs:elementname="TagId"type="xs:string"/>〈xs:elementname="MinOccurs"type="xs:integer"/><xs:elementname="MaxOccurs"type="xs:integer"/>〈xs:elementname="DataElementList"><xs:complexType><xs:S6qucncc><xs:choiceminOccurs="l"maxOccurs="unbounded">〈xs:elementname="CompositeElement"><xs:complexType><xs:sequcnce>〈xs:elementname="Name"type="xs:string"/><xs:elementmaxOccurs="unboundedref="SimpleElement"/></xs:sequcncc></xs:complexType></xs:element〉<xs:elementref="SimpleElement"/></xs:choice></xs:sequence></xs:complexType></xs:element></xs:sequence></xs:complexType></xs:element>〈xs:elementname="SimpleElement"><xs:complexType><xs:scquence>〈xs:elementname="Name"type="xs:string"/>〈xs:elementname="MinOccurs"type="xs:string"/>〈xs:elementname="MaxOccurs"type="xs:string"/>〈xs:elementname-"MinLength"type="xs:string"/>〈xs:elementname="MaxLength"type-"xs:string"/>〈xs:elementname="DataType"><xs:simpleType><xs:restrictionbase="xs:string"><xs:enumerationvalue="A"/><xs:enumerationvalue="N"/><xs:enumerationvalue="ID"/><xs:enumerationvalue="R"/><xs:enumerationvalue="AN"/><xs:enumerationvalue="Date"/><xs:enumerationvalue="Time"/></xs:restriction></xs:simpleType></xs:element>〈xs:elementminOccurs="0"maxOccurs="unbounded"name="AllowedValues"type="xs:string"/></xs:scqusncs></xs:complexType></xs:element><xs:complexTypename="BlockType"><xs:scquencc><xs:choiceminOccurs="0"maxOccurs="unbounded">〈xs:elementname="Loop"><xs:complexType><xs:scquence>〈xs:elementname="Name"type="xs:string"/>〈xs:elementref="Block"/>〈xs:elementname="MinOccurs"type="xs:int"/>〈xs:elementname="MaxOccurs"type="xs:int"/></xs:ssqu6ncc></xs:complexType></xs:element>〈xs:elementref="Segment"/></xs:choice></xs:scqucncc></xs:complexType></xs:schema>附录B节2:使用元模式单一结构的示例采购定单模式<nsO:EdiSchemaRootxmlns:nsO="http:〃schema.company.com/EdiClient/MetaSCHEMA"><RootEIementName>X1200501—850</RootElementName><Block><Segment><Name>PurchaseOrderDetail</Name><TagId>PUR</TagId〉<MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><DataElementList><Simp1eE1ement><Name>OriginatorId</Name><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>4</MinLength><MaxLength>10</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Name>FirstName</Name><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength><MaxLength>10</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Name>LastName</Name〉<MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength><MaxLength>10</MaxLength><DataType>AN</DataType></SimpleElement></DataElementList></Segment><Loop><Name〉LineItemLoop></Name><MinOccurs>1</MinOccurs><MaxOccurs>unbounded</MaxOccurs><Block><Segment><Name>LineItem</Name><TagId>LIN</TagId><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><DataElementList><Simp1eE1ement><Name>ltemld</Name><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>4</MinLength><MaxLength>10</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Name>Quantity</Name><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength〉<MaxLength>5</MaxLength><DataType>N</DataType></SimpleElement></DataElementList></Segment><Segment><Name>ShipTo</Name><TagId>SHP</TagId><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><DataElementList><SimpleElement><Name>FirstName</Name><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength><MaxLength>10</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Namc>LastNamc</N3m6><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength><MaxLength>10</MaxLength><DataType>AN</DataType></SimpIeElement><CompositeElement><Name>Address</Name><SimpleElement><Name>StreetInfo</Name><MinOccurs>1</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength><MaxLength>100</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Name〉City</Name><MinOccurs>l</MinOccurs><MaxOccurs>1</Max0ccurs><MinLength>1</MinLength><MaxLength>100</MaxLength><DataType>AN</DataType></SimpleElement〉<SimpleElement><Name>State</Name><MinOccurs>1</MinOceurs><MaxOccurs>1</MaxOccurs><MinLength>2</MinLength><MaxLength>2</MaxLength><DataType>ID</DataType></SimpleElement><SimpleElement><Name>Zip</Name><MinOccurs>1</MinQccurs><MaxOccurs>1</MaxOccurs><MinLength>5</MinLength><MaxLength>10</MaxLength><DataType>N</DataType></SimpleElement></CompositeElement〉</DataE1ementList></Segment></Block></Loop><Segment><Name〉Notes</Name><TagId>NTE</TagId><MinOccurs>0</MinOccurs〉<MaxOccurs>1</MaxOccurs〉<DataElementList><SimpleElement><Name>NoteLine1</Name><MinOccurs>0</MinOccurs><MaxOccurs>1</MaxOccurs〉<MinLength>1</MinLength><MaxLength>80</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Name>NoteLine2</Name><MinOccurs>0</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength>1</MinLength><MaxLength>80</MaxLength><DataType>AN</DataType></SimpleElement><SimpleElement><Name>NoteLine3</Name><MinOccurs>0</MinOccurs><MaxOccurs>1</MaxOccurs><MinLength〉1</MinLength><MaxLength〉80</MaxLength><DataType>AN</DataType></SimpleElement></DataElementList></Segment〉</Block></nsO:EdiSchemaRoot>权利要求1.一种至少部分地由计算设备实现的、用于变换电子数据交换(EDI)交易的方法，所述方法包括批量接收EDI数据，所述批量EDI数据包括多个EDI文档，每一EDI文档具有对应于一交易类型的至少一个EDI交易；通过根据EDI标准对所接收的EDI数据进行解码来标识包括在所述EDI文档中的EDI交易；以及从所述批量的多个EDI文档中生成一合并的EDI文档，所述合并的EDI文档包括根据所述交易类型组织的所标识的EDI交易的EDI数据。2.如权利要求l所述的方法，其特征在于，所述合并的EDI文档是可扩展标记语言(XML)文档。3.如权利要求2所述的方法，其特征在于，还包括按照XML标签来组织包括在所述合并的EDI文档中的EDI交易，其中所述XML标签指示所述EDI交易的交易类型。4.如权利要求l所述的方法，其特征在于，所述合并的EDI文档包括一乳模式，所述乳模式表示被所述EDI交易参考的多个模式。5.如权利要求4所述的方法，其特征在于，还包括定义用于变换所述多个模式以便在运行时期间处理的运行时模式映射。6.如权利要求l所述的方法，其特征在于，还包括根据包括在所述EDI交易中的一个或多个信息将所述合并的EDI文档中的EDI交易组织为子文档，并且其中所述子文档中的EDI交易与所述多个EDI文档中的EDI交易相关。7.如权利要求1所述的方法，其特征在于，一个或多个计算机可读介质具有用于执行如权利要求1所述的方法的计算机可执行指令。8.—种用于在发送源和接收设备之间变换电子数据交换(EDI)交易的系统，所述系统包括用于批量发送EDI数据的发送源，所述批量EDI数据包括多个EDI文档，每一EDI文档具有对应于一交易类型的至少一个EDI交易；用于接收所述批量EDI数据的接口；用于执行计算机可执行指令的处理器，所述指令用于通过根据EDI标准对所接收的EDI数据进行解码来标识包括在所述多个EDI文档中的EDI交易；以及从所述批量EDI数据的多个EDI文档中定义一合并的EDI文档，所述合并的EDI文档包括根据所述交易类型组织的所标识的EDI交易。9.如权利要求8所述的系统，其特征在于，所述合并的EDI文档是可扩展标记语言(XML)文档。10.如权利要求9所述的系统，其特征在于，所述处理器还被配置成按照XML标签来组织包括在所述合并的EDI文档中的EDI交易，其中所述XML标签指示所述EDI交易的交易类型。11.如权利要求8所述的系统，其特征在于，所述合并的EDI文档包括一乳模式，所述乳模式表示被所述EDI交易参考的多个模式。12.如权利要求ll所述的系统，其特征在于，所述接口还接收用于变换所述多个模式以便在运行时期间由所述的处理器处理的运行时模式映射。13.如权利要求12所述的系统，其特征在于，所述处理器被配置成应用所述运行时模式映射以在运行时期间匹配所述多个模式。14.如权利要求8所述的系统，其特征在于，所述处理器还被配置成根据包括在所述EDI交易中的一个或多个信息将所述合并的EDI文档中的EDI交易组织为子文档，并且其中所述子文档中的EDI交易与所述多个EDI文档中的EDI交易相关。15.—种或多种具有用于变换电子数据交换(EDI)交易的计算机可执行组件的计算机可读介质，所述计算机可执行组件包括用于从一发送源批量接收EDI数据并将所接收的EDI数据发送给一接收方的接口组件，所述批量EDI数据包括多个EDI文档，每一EDI文档具有对应于一交易类型的至少一个EDI交易；用于通过根据EDI标准对所接收的EDI数据进行解码来标识包括在所述多个EDI文档中的EDI交易的标识组件；以及用于从所述批量EDI数据的多个EDI文档中定义一合并的EDI文档的变换组件，所述合并的EDI文档包括根据所述交易类型组织的所标识的EDI交易。16.如权利要求15所述的计算机可读介质，其特征在于，所述合并的EDI文档是可扩展标记语言(XML)文档。17.如权利要求16所述的计算机可读介质，其特征在于，还包括用于按照XML标签来组织包括在所述合并的EDI文档中的EDI交易的文档组件，其中所述XML标签指示所述EDI交易的交易类型。18.如权利要求17所述的计算机可读介质，其特征在于，所述文档组件还根据包括在所述EDI交易中的一个或多个信息将所述合并的EDI文档中的EDI交易组织为子文档，并且其中所述子文档中的EDI交易与所述多个EDI文档中的EDI交易相关。19.如权利要求15所述的计算机可读介质，其特征在于，所述合并的EDI文档包括一乳模式，所述乳模式表示被所述EDI交易参考的多个模式。20.如权利要求15所述的计算机可读介质，其特征在于，所述接口组件还接收用于变换所述多个模式以便在运行时期间由所述的处理器处理的运行时模式映射。全文摘要用于变换电子数据交换(EDI)交易的可扩展标记语言(XML)规范。批量接收EDI数据的集合。该批量EDI数据包括多个EDI文档，并且这多个EDI文档中的每一个具有对应于一交易类型的至少一个EDI交易。包括在EDI文档中的EDI交易通过根据EDI标准对所接收的EDI数据进行解码来标识。从批量EDI数据中EDI文档生成一合并的EDI文档。该合并的EDI文档包括根据交易类型组织的所标识的EDI交易。文档编号H04L12/56GK101331511SQ200680047362公开日2008年12月24日申请日期2006年11月17日优先权日2005年12月16日发明者S·玛什拉洙,S·高拉夫申请人:微软公司