專利名稱：：用于電子數(shù)據(jù)交換(edi)的xml規(guī)范的制作方法用于電子數(shù)據(jù)交換(EDI)的XML規(guī)范背景商業(yè)實體經(jīng)常以嚴(yán)格的格式通過普通通信網(wǎng)絡(luò)發(fā)送商業(yè)交易數(shù)據(jù)以便于處理交易。例如，電子數(shù)據(jù)交換(EDI)是企業(yè)利用范圍不斷擴展的自動化計算系統(tǒng)的方式之一。在EDI中，商業(yè)數(shù)據(jù)是根據(jù)諸如ANSIX12或EDIFACT等一種或多種已知且核準(zhǔn)的標(biāo)準(zhǔn)來格式化的。例如，表示各種交易的EDI數(shù)據(jù)是作為一批描繪文檔來發(fā)送的，并且每一描繪文檔是根據(jù)嚴(yán)格的格式化規(guī)則來編碼的，以確保接收這些文檔的目的地應(yīng)用程序能夠成功地解析并使用該信息來進行下游的處理。在解析和處理EDI消息時，現(xiàn)有系統(tǒng)發(fā)送EDI數(shù)據(jù)，并且在交換期間在每一描繪文檔中包括格式化規(guī)則或模式。例如，表示采購定單交易的的EDI數(shù)據(jù)包括用于釆購定單交易的模式。由此，每一EDI交易文檔既包括EDI數(shù)據(jù)，又包括用于該交易的特定模式。盡管這一安排或配置便于解析EDI數(shù)據(jù)，但是它是靜態(tài)的，并且使得每一交易文檔的文檔大小很大。另外，所包括的模式不是可共享的。換言之，如果有兩個釆購定單交易文檔A和B，則每一采購定單交易文檔需要包括一采購定單模式，即使每一文檔中的模式是相同的。并且，特別地，EDI交易是根據(jù)行或文檔的數(shù)量以及發(fā)送EDI數(shù)據(jù)所需的帶寬來收費的。由于商業(yè)實體使用EDI每天都發(fā)送數(shù)百萬的交易，這些包括重復(fù)模式信息的大型EDI交易文檔造成了對具有冗余模式信息的不必要的成本。一旦接收到EDI交易文檔，目的地應(yīng)用程序通常將該EDI交易文檔儲存在存儲器區(qū)域中。目的地應(yīng)用程序接著向源發(fā)送指示該交易已被接收的接收肯定應(yīng)答。所儲存的EDI交易隨后由應(yīng)用程序確認來確定包括在該交易文檔中的EDI數(shù)據(jù)是否符合用于該交易類型的模式的格式化規(guī)則。在此確認期間，要求源(例如，商家或客戶)等待指示該交易數(shù)據(jù)符合該格式的確認肯定應(yīng)答。如果確定一個或多個交易沒有被正確地格式化，則需要重新發(fā)送替換的EDI交易文檔以便處理。這一等待確認延遲進一步降低了處理EDI交易的效率。概述本發(fā)明的各實施例通過將各EDI交易文件變換成具有標(biāo)識各種EDI交易類型的嵌套結(jié)構(gòu)或子文檔的一個EDI文檔來克服現(xiàn)有系統(tǒng)在處理EDI交易時的缺點。另外，本發(fā)明的各方面通過使得模式實例在運行時處理EDI交易時可用來使得EDI文檔能引用模式。有利的是，本發(fā)明的各實施例自動識別與交易類型相關(guān)聯(lián)的模式，并在接收到EDI交易時處理該EDI交易。根據(jù)本發(fā)明的其它實施例，在接收到EDI交易時處理該EDI交易。在本發(fā)明的又一實施例中，定義一單一元模式來表示多個模式。該單一元模式被提供給最終用戶以修改該模式的特性。提供本概述以便用簡化的形式介紹將在以下詳細描述中進一步描述的一些概念。本概述并不旨在確定所要求保護的主題的關(guān)鍵特征或必要特征，也不旨在用于幫助確定所要求保護的主題的范圍。其它特征將部分變得清楚，部分在以下指出。附圖簡述圖1是示出處理EDI交易的一個實現(xiàn)的框圖。圖2A到2C是示出根據(jù)本發(fā)明的一個實施例的使用電子數(shù)據(jù)交換(EDI)的交易數(shù)據(jù)的結(jié)構(gòu)。圖3是示出根據(jù)本發(fā)明的一個實施例的用于變換EDI交易的系統(tǒng)的示例性框圖。圖4A和4B是示出根據(jù)本發(fā)明的一個實施例的EDI交易的變換的流程圖。圖5A是示出根據(jù)本發(fā)明的一個實施例的EDI交易的嵌套的框圖。圖5B和5C是示出根據(jù)本發(fā)明的一個實施例的串行化EDI交易的框圖。圖6A和6B是示出根據(jù)本發(fā)明的一個實施例的包括在合并的可擴展標(biāo)記語言(XML)文檔格式的EDI文檔中的經(jīng)變換的EDI交易的屏幕截圖。圖7A到7D是示出根據(jù)本發(fā)明的一個實施例的自動標(biāo)識EDI模式的屏幕截圖。圖8A是示出根據(jù)本發(fā)明的一個實施例的確認EDI交易的流程圖。圖8B是示出根據(jù)本發(fā)明的一個實施例的檢測EDI交易中的錯誤的圖示。圖9A和9B是示出根據(jù)本發(fā)明的一個實施例的EDI確認肯定應(yīng)答結(jié)構(gòu)的圖示。圖10是示出根據(jù)本發(fā)明的一個實施例的用于修改多個EDI模式的單一元模式的屏幕截圖。明的一個實施例的用于使用單一元模式來修改多個EDI模式的方法的流程圖。圖IIA到IID是示出其上可儲存本發(fā)明的各方面的示例性計算機可讀介質(zhì)的框圖。圖12是示出其中可實現(xiàn)本發(fā)明的合適的計算系統(tǒng)環(huán)境的一個實例的框圖。附錄A完整描述了圖IOA所示的XML模式。附錄B示出了表示采購定單模式的XML格式的示例性單一元模式。在全部附圖中，相應(yīng)的參考標(biāo)號指示相應(yīng)的部分。詳細描述圖1是示出處理EDI交易的一個實現(xiàn)的框圖。最初，如圖1所示，源(例如，商業(yè)合伙人)102通過普通通信網(wǎng)絡(luò)108向目的地(例如，商業(yè)客戶)104發(fā)送EDI消息106，該消息可包括發(fā)票202。源102經(jīng)由普通通信網(wǎng)絡(luò)108向目的地104發(fā)送包括模式和EDI交易數(shù)據(jù)的EDI消息106。在一個實例中，EDI消息106包括批量的多個EDI交易數(shù)據(jù)，以便節(jié)省傳輸或帶寬成本。在另一示例中，普通通信網(wǎng)絡(luò)106可以是諸如內(nèi)聯(lián)網(wǎng)等私有的專用網(wǎng)絡(luò)，或諸如因特網(wǎng)等公共網(wǎng)絡(luò)。在另一示例中，普通通信網(wǎng)絡(luò)108包括一個或多個網(wǎng)絡(luò)協(xié)議，諸如FTP、HTTP、Kermit、Xmodem、幀延遲、EDIINT、3780Bisync⑧等，以便于在合伙人之間傳送EDI消息。源102通過打開經(jīng)由普通通信網(wǎng)絡(luò)108與目的地104的連接會話(例如，安全套接字連接會話)來發(fā)起EDI消息106的傳輸。一旦打開了連接會話，源102就向目的地104發(fā)送EDI消息106。目的地104上的一組EDI轉(zhuǎn)換器系統(tǒng)110接收EDI消息106，并且該EDI轉(zhuǎn)換器系統(tǒng)110經(jīng)由普通通信網(wǎng)絡(luò)108向源102發(fā)送指示該EDI消息已被接收到的接收肯定應(yīng)答112。常見的是接收確認應(yīng)答在源102關(guān)閉會話連接之前被發(fā)送會返回給源102。一旦接收到EDI消息106，EDI轉(zhuǎn)換器系統(tǒng)110就解析并處理與EDI交易相關(guān)聯(lián)的EDI數(shù)據(jù)。如本領(lǐng)域的技術(shù)人員已知的，對EDI交易的解析和/或解碼涉及標(biāo)識各種EDI標(biāo)準(zhǔn)、模式規(guī)范等的一個或多個步驟。在此期間，EDI轉(zhuǎn)換器系統(tǒng)IIO將經(jīng)解析或解碼的EDI數(shù)據(jù)發(fā)送給下游應(yīng)用程序114以處理該經(jīng)解析或解碼的EDI數(shù)據(jù)。例如，下游應(yīng)用程序114可以是處理發(fā)票的會計應(yīng)用程序，或者是用于處理采購定單數(shù)據(jù)的軟件。由此，下游應(yīng)用程序114能夠確認所接收到的EDI數(shù)據(jù)在解析和解碼之后是否符合在模式中指定的格式化規(guī)則。如果所接收到的EDI數(shù)據(jù)符合模式規(guī)則，則下游應(yīng)用程序114向源102發(fā)送一確認肯定應(yīng)答116。另一方面，如果該接收到的EDI數(shù)據(jù)包括錯誤或是無效的，則下游應(yīng)用程序114可以向源發(fā)送指示所接收到的EDI數(shù)據(jù)的錯誤的錯誤通知。確認肯定應(yīng)答116通常以接收肯定應(yīng)答的發(fā)送之后的延遲來發(fā)送給源102。在其它實現(xiàn)中，經(jīng)解析的EDI數(shù)據(jù)被儲存在一數(shù)據(jù)庫或數(shù)據(jù)存儲(未示出)中以等待確認。由此，源102經(jīng)常被要求等待確認肯定應(yīng)答116來查明該EDI數(shù)據(jù)能夠被目的地104正確地處理。圖2A到2C是示出根據(jù)本發(fā)明的一個實施例的使用電子數(shù)據(jù)交換(EDI)的交易數(shù)據(jù)的結(jié)構(gòu)的圖示。圖2A示出了使用ANSIX12格式的發(fā)票EDI交易文檔的表示的示例。在此示例中，發(fā)票202包括多個段或部分(見圖2C中的X12EDI交換結(jié)構(gòu)218的概觀)，諸如功能組204部分，它可包括發(fā)票202的附加信息。例如，在供應(yīng)鏈部門中，本領(lǐng)域的技術(shù)人員已知功能組204中的信息或值與交換部分(例如，交換控制頭)中的信息或值是相同的，如圖2C所示。在另一示例中，功能組204中的信息或值包括標(biāo)識大企業(yè)內(nèi)的商業(yè)或營業(yè)單元的值或標(biāo)識符。發(fā)票202還包括頭部分206，它包括諸如商業(yè)客戶信息等信息。在此示例中，頭部分206包括商業(yè)客戶名稱"ABC公司"以及地址"密蘇里州，圣路易市，第六大街0887號，63101"。在一個實施例中，頭部分206包括用于接收確認肯定應(yīng)答的目的地信息，參見以下對圖8、9A和9B的討論。發(fā)票202還包括示出以循環(huán)210組織的一個或多個數(shù)據(jù)段212的細節(jié)表部分208。例如，循環(huán)210包括一組語義上相關(guān)的數(shù)據(jù)段，并且對本領(lǐng)域的技術(shù)人員而言，這些段可以根據(jù)ANSIX12.6是有界或無界的。根據(jù)ANSIX12或EDIFACT格式，在EDI交易文檔中可包括其它段類型和部分以及相應(yīng)的信息，而不背離本發(fā)明的范圍。例如，圖2B示出了包括在要在目的地104處處理的同一EDI消息106中的一個或多個交易類型。發(fā)票214和采購定單216EDI交易文檔被包括在EDI消息106中，因為發(fā)票214和采購定單216與同一客戶，即"ABC公司"相關(guān)。其它各組相關(guān)交易文檔可以作為EDI消息106被包括在交換中。在一個實施例中，用于一個目的地或客戶的EDI文檔可以批量發(fā)送。還可以理解，要求每一EDI交易類型都符合與該交易類型相關(guān)聯(lián)的模式。例如，特別地，發(fā)票交易模式可要求關(guān)于用于商家或買家的名稱的最大或最小字符長度的限制。采購定單交易模式可要求小數(shù)點之后的最大位數(shù)。在另一示例中，用于各種交易類型的模式可以指定一特定字段是強制的，而其它字段是可任選的?，F(xiàn)有的實現(xiàn)在向諸如目的地104等客戶發(fā)送EDI交易時在EDI交易文檔中包括交易模式。盡管這些實現(xiàn)便于對EDI交易的解碼，但是它們要求模式設(shè)計者在向商業(yè)合伙人發(fā)送EDI交易之前花費大量時間來設(shè)計或配置該模式。并且，由于合伙人之間的商業(yè)協(xié)定的修改，需要對這些模式的后續(xù)修改來重新設(shè)計該模式。由此，本發(fā)明的實施例通過將EDI消息變換成具有根據(jù)交易類型來組織一個或多個EDI交易的嵌套結(jié)構(gòu)或子文檔的一個合并的EDI文檔克服了現(xiàn)有實現(xiàn)的缺陷。EDI文檔還包括用于表示與交易類型相關(guān)聯(lián)的多個模式的乳模式(uber-schema)。在另一實施例中，一運行時模式映射變換多個模式以便在目的地104處在運行時處理?，F(xiàn)在參考圖3，一框圖示出了用于根據(jù)本發(fā)明的一個實施例來變換EDI交易的系統(tǒng)302的框圖。系統(tǒng)302包括源304，源可以是與目的地306或客戶交易商業(yè)的商家。例如，源304可以是諸如向購買計算設(shè)備的公司客戶銷售大量商品的電子消費品零售商店等商家。在另一示例中，源304可以是健康護理提供者，諸如醫(yī)院或藥店，并且向健康護理保險公司或交換所發(fā)送EDI數(shù)據(jù)以便提交主張或符合健康保險便利及責(zé)任法案(HIPAA)。在一個實施例中，源304和目的地306包括諸如圖12中的計算機130等一個或多個計算設(shè)備，用于批量發(fā)送EDI文檔。最初，源304發(fā)送包括多個EDI文檔的EDI消息310。每一EDI文檔包括對應(yīng)于一交易類型(例如，發(fā)票、采購定單、應(yīng)付款等)的至少一個EDI交易。還參考圖4A，一流程圖示出了根據(jù)本發(fā)明的一個實施例的變換EDI交易。在源304打開通信網(wǎng)絡(luò)308上的連接會話以與目的地306通信之后，源304向目的地306的EDI引擎312發(fā)送EDI消息310。在一個實施例中，EDI引擎312包括執(zhí)行計算機可執(zhí)行指令、例程或函數(shù)的一個或多個計算設(shè)備(例如，計算機130)。在402處，EDI引擎312接收包括多個EDI文檔的EDI消息310。在404處，EDI弓|擎312標(biāo)識包括在多個EDI文檔中的EDI交易。使用以上的ANSIX12示例，EDI引擎312通過標(biāo)識圖2C所示的各種數(shù)據(jù)頭和數(shù)據(jù)段(例如，ISA、GS等)來解碼或解析X12發(fā)票，以確定交易中的EDI數(shù)據(jù)。在另一實施例中，EDI引擎312還標(biāo)識包括在多個EDI文檔中的各種模式來確定用于該交易類型的特定格式化規(guī)則。在406處，EDI引擎312從該批多個EDI文檔中生成合并的EDI文檔314。在一個示例中，EDI引擎312在410處生成合并的EDI文檔314作為具有XML結(jié)構(gòu)標(biāo)記標(biāo)簽的XML文檔。例如，不像其中每一交易被組織為一文檔的現(xiàn)有的實現(xiàn)，本發(fā)明的各實施例將多個EDI文檔中的EDI交易組織成一個XML文檔，該XML文檔不僅定義了個別的交易集，而且還通過捕捉EDI數(shù)據(jù)的所有方面，包括段、循環(huán)、字段、定界符等，定義了交換。在一個示例中，圖6A示出了包括一個或多個EDI交易(諸如"PO(采購定單)")的示例性合并的XMl文檔。在又一實施例中，該合并的EDI文檔314包括表示由EDI交易引用的多個模式的乳模式。例如，該乳模式被包括在EDI交易集中，并且被嵌入或縫合在每一EDI交易的功能組和信封段(envel叩esegment)內(nèi)，使得最終用戶無需為期望被包括在EDI消息310中的每一交易集創(chuàng)建一特定模式。作為一個示例，圖6B示出了一屏幕截圖，其示出了根據(jù)本發(fā)明的一個實施例的合并的EDI文檔314中的XML格式的乳模式。采用這一設(shè)計，合并的EDI文檔的交換減少了在EDI文檔314中包括對應(yīng)于一交易類型的一個或多個模式的需求。本發(fā)明的各實施例還減少了傳輸之前的模式設(shè)計和開發(fā)時間。在另一實施例中，在圖4B的412處，EDI引擎312用運行時模式映射或凈荷模式來變換合并的EDI文檔。在414處，EDI引擎312為合并的EDI文檔314中的EDI交易創(chuàng)建子文檔或嵌套結(jié)構(gòu)(見表1和2中的附加描述)。在一個替換實施例中，該合并的EDI文檔314是用凈荷模式(例如，運行時模式映射)來變換的，并且還可在416處在結(jié)構(gòu)上進行變換?；蛘?，合并的EDI文檔314可被發(fā)送到下游應(yīng)用程序316以便在418處在沒有結(jié)構(gòu)變換的情況下進行處理。在420處，具有子文檔或嵌套結(jié)構(gòu)的合并的EDI文檔314也被發(fā)送到下游應(yīng)用程序316以供處理。可以理解，可以使用除用于合并的EDI文檔314的XML之外的、帶有以可標(biāo)識結(jié)構(gòu)來定義并組織EDI交易的標(biāo)記標(biāo)簽的其它格式，而不背離本發(fā)明的范圍。在另一實施例中，描述了其上可儲存上述本發(fā)明的各方面的計算機可讀介質(zhì)1102(在圖11A中)。例如，接口組件1104、標(biāo)識組件1106以及變換組件1108可被包括在執(zhí)行以上討論的一個或多個操作的EDI引擎312中。還可以理解，圖4A所示的方法可以由源304來執(zhí)行，使得源304可以在傳輸之前減小交換的大小。由此，合并的EDI文檔314的嵌套結(jié)構(gòu)或子文檔減少了行數(shù)，這還可以減少當(dāng)根據(jù)行數(shù)來收費時的發(fā)送EDI數(shù)據(jù)的成本。例如，表1示出了合并的EDI文檔中的嵌套結(jié)構(gòu)中的三個EDI交易，以及各自包括這三個EDI交易中的一個的相應(yīng)的三個原始EDI文檔。嵌套結(jié)構(gòu)中的EDI交易用于下游處理的展平的EDI事務(wù)交易#1的開始PO頭段PO行1PO進度表1PO進度表2PO行1總和PO行2PO進度表2.1PO行2總和PO總和交易#1的結(jié)束交易Wa的開始PO頭段PO行1PO進度表l.lPO行1總和PO總和交易Wa的結(jié)束交易Wb的開始PO頭段PO行1PO進度表1.2PO行1總和PO總和交易Wb的結(jié)束交易Wc的開始PO頭段PO行2PO進度表2.1PO行2總和PO總和交易Wc的結(jié)束表l:嵌套結(jié)構(gòu)(左列)和三個EDI文檔(右列)中的三個EDI交易在操作中，假設(shè)諸如雇主A等健康護理發(fā)起者需要向諸如健康護理提供者B等付款人發(fā)送諸如HIPAA834文檔等EDI消息。用于這一交換的模式要求雇主A提供健康護理受益人/接收者(例如，雇員及其家屬)的福利的細節(jié)。由此，雇主A通常包括發(fā)起者和付款人的詳細信息。發(fā)起者和付款人的該詳細信息對于所有受人都是共同的，并且對正在接收由雇主A發(fā)起的福利的每一雇員或家屬重復(fù)。本發(fā)明的各實施例創(chuàng)建一嵌套結(jié)構(gòu)，使得每一成員可連同發(fā)起者和付款人的詳細信息的副本一起以一個EDI文檔中的類似循環(huán)的邏輯來創(chuàng)建，而非如在現(xiàn)有的EDI實現(xiàn)中那樣對數(shù)千個雇員和家屬重復(fù)相同的發(fā)起者和付款人信息。圖5A是示出根據(jù)本發(fā)明的一個實施例的EDI交易的嵌套的框圖。例如，在502處，在目的地(例如，目的地306)處從源(例如，源304)接收EDI消息(例如，EDI消息310)。在504處，生成一合并的EDI文檔，其中各EDI交易被包括在一嵌套結(jié)構(gòu)中或作為子文檔來包括。在一個示例中，剝?nèi)バ欧?控制段(例如，ANSIX12格式中的ISA/GS/GE/IEA段)，并通過接收管線解析交易集(ST/SE)來對每一交易集生成多個XML子文檔。在一個實施例中，多個XML子文檔被存放在一消息箱中。在506處，目的地處的接收管線執(zhí)行對傳入交換的確認，并生成適當(dāng)?shù)拇_認肯定應(yīng)答(將在圖8、9A和9B中詳細討論)。在一個實施例中，接收管線還更新校驗和和商業(yè)總和。如上所述，合并的EDI文檔314可以由下游應(yīng)用程序316來處理。由此，該合并的EDI文檔被發(fā)送給一發(fā)送端口，并且在508處，該發(fā)送端口發(fā)送EDI子文檔中的EDI交易。在一個實施例中，與發(fā)送端口相關(guān)聯(lián)的發(fā)送管線串行化XML子文檔，并傳送個交換，其中在發(fā)送管線處更新段的計數(shù)。在一個實施例中，當(dāng)接收到一EDI交換時，確認該交換。如果沒有任何確認錯誤，則根據(jù)其模式將每一交易集轉(zhuǎn)換成XML格式。由此，一個EDI交換可包含采購定單和發(fā)票文檔。采購定單可以被轉(zhuǎn)換成符合采購定單模式的XML。同樣，發(fā)票將被轉(zhuǎn)換成發(fā)票XML。圖5B示出了XML格式的來自EDI交換的示例性采購定單。當(dāng)該采購定單文檔由圖5A中的發(fā)送側(cè)處理時，它在處理了信封段之后被轉(zhuǎn)換成EDI格式514。圖5C示出了由發(fā)送端口從圖5B中的XML格式產(chǎn)生的示例性文檔。在一個實施例中，EDI格式514包括兩個信封段(例如，以ISA和GS開頭的行)。類似地，EDI格式514在該文檔的末尾包括兩個信封段，GE和正A。如圖所示，包括在ST和SE段之間的數(shù)據(jù)是用于原始交易集的數(shù)據(jù)。在如圖5B和5C所示的以上示例中，SE01的值(見箭頭512)是"14"，并且是由發(fā)送端口動態(tài)計算的。盡管串行化一EDI文檔，但是EDI引擎(例如，EDI引擎312)的發(fā)送側(cè)跟蹤一交易集中存在的段數(shù)?；谠撝担_定SE01的值。在源304生成合并的EDI文檔314以包括來自多個EDI文檔的EDI交易的情況下，本發(fā)明的各實施例包括將所包括的EDI交易組織在一嵌套結(jié)構(gòu)中。在另一示例中，本發(fā)明的各實施例允許從源接收合并的EDI文檔314的目的地306為了后向兼容性或為了適應(yīng)只能處理每一文檔僅包含一個交易的EDI文檔的下游應(yīng)用程序316而從合并的EDI文檔314中還原多個EDI文檔。本發(fā)明的替換實施例允許具有嵌套結(jié)構(gòu)中的EDI交易的合并的EDI文檔跟蹤原始的多個EDI文檔或與這些原始文檔相關(guān)。例如，表2示出了將EDI交易從合并的EDI文檔314轉(zhuǎn)換成多個EDI文檔。<table>tableseeoriginaldocumentpage13</column></row><table>表2:合并的EDI文檔轉(zhuǎn)換在表2所示的示例中，對嵌套結(jié)構(gòu)中的EDI交易的處理通過標(biāo)識預(yù)定的子文檔創(chuàng)建斷點(SubDocumentCreationBreakPoint)(例如，描述一子文檔在父文檔中的何處開始的"\"標(biāo)記)以生成多個子文檔來開始。根據(jù)表2，在列A1中所示的合并的EDI文檔可根據(jù)在模式中的BB循環(huán)處定義的子文檔創(chuàng)建斷點而被拆分成三個交易BB1*1-BB2*1、BB1*2以及BB1*3-BB2*3。在列A2中，交易集BB1*1-BB2*1被組織或拆分(由粗體文本表示)成一單獨的文檔，而在列A3中，交易BB1*2被組織在第二文檔中(由下劃線文本表示)。類似地，交易集BBP3-BB2—3被組織成要由下游應(yīng)用程序316處理的第三EDI文檔(由斜體文本表示)。通過將包括在多個EDI文檔中的EDI交易變換成合并的EDI文檔314，本發(fā)明的各實施例使得目的地306或源304能夠在變換期間有效地標(biāo)識包括在每一EDI文檔中的多個模式。另外，本發(fā)明的至少一方面使得目的地306在變換了合并的EDI文檔之后在連接會話仍然被打開的時間段內(nèi)生成要在返回給源304的確認肯定應(yīng)答。換言之，本發(fā)明的各方面將目的地306配置成在接收EDI交易的同時自動標(biāo)識多個模式并確認EDI交易?，F(xiàn)在參考圖7A-7D，示出了根據(jù)本發(fā)明的一個實施例的自動標(biāo)識EDI模式的一系列屏幕截圖。圖7A示出了典型的ANSIX12采購定單模式。模式是由與其相關(guān)聯(lián)的DocType(文檔類型)來標(biāo)識的。DocType是諸如名稱空間和根節(jié)點名稱等配置項的組合。如圖7A所示，該屏幕截圖的左列702示出了一模式的分層結(jié)構(gòu)。在此示例中，左列702示出了一模式結(jié)構(gòu)。中列704指示了該模式的XML代碼。右列706指示了包括在該模式中的特性或目標(biāo)名稱空間。在一個實施例中，DocType具有以下格式X12格式的"DocType=TargetNamespace'#，RootNodeName"，這將在以下詳細描述?？梢岳斫?，盡管在圖7A中描述了X12模式，但是可以使用諸如EDIFACT模式等其它模式格式而不背離本發(fā)明的范圍。DocType的根節(jié)點具有以下X12格式之一"X12_{Version}_{Tsld}"。在此示例中，配置項"rootnode"(根節(jié)點)的值是"X12_00401—850"，如由框708所示。換言之，"00401"是文檔的版本，并且它是在運行時處理期間確定配置或?qū)嵗囊粭l動態(tài)信息。類似地，"850"是TsId，它是所處理的模式的交易標(biāo)識(ID)，并且是從輸入實例中確定的。在此示例中，交易ID"850"表示采購定單，如由框710所指示的。并且，目標(biāo)名稱空間由右列706中的框712來指示。在另一示例中，為解碼或標(biāo)識EDIFACT格式的模式，EDIFACT模式當(dāng)前具有以下格式"Efact_{Version}」Tsid}"。換言之，所有EDIFACT模式都具有以"Efact"開頭的根節(jié)點名稱，并且Version和Tsid的定義與X12格式的相同。使用圖3作為一個示例，當(dāng)目的地306從源304接收到EDI文檔時，EDI交易可隨文檔一起包括交易ID"850"。然而，版本信息或目標(biāo)名稱空間信息是在運行時確定的，并且這些配置項的值可以在不同的級別下配置。由此，在應(yīng)用了根據(jù)EDI標(biāo)準(zhǔn)(X12或EDIFACT)的規(guī)則以根據(jù)相應(yīng)的交易類型(例如，采購定單、發(fā)票等)來解碼EDI交易之后，EDI引擎312標(biāo)識經(jīng)解碼的EDI交易中的配置項。在一個實施例中，EDI引擎312從一個或多個配置級別標(biāo)識配置項，諸如合伙人級別和發(fā)送應(yīng)用程序級別、全局級別、管線級別或默認級別。例如，圖7B示出了顯示參與者級別配置中的配置項的屏幕截圖。在此示例中，用于以上圖7A所示的合伙人的交易ID850被配置成使用如上所示的目標(biāo)名稱空間和版本信息。對于所有其它文檔類型，可使用默認值，因為如由框714所指示的，默認標(biāo)志或參數(shù)被打開。在另一示例中，另一貿(mào)易合伙人可基于在商業(yè)貿(mào)易合伙人之間建立的商業(yè)協(xié)定在合伙人級別配置中設(shè)置其它特定配置項。本發(fā)明的各實施例在自動標(biāo)識模式時通過確定由貿(mào)易合伙人從一個或多個配置級別設(shè)置的特定值來標(biāo)識配置項的值，而非靜態(tài)地確定配置項的值。在一個實施例中，由于發(fā)送者Id和交易Id的特定組合，參與者級別配置中的配置項的值可以被配置為與圖7A中的DocType所示的不同的值。例如，在X12中，每一發(fā)送者Id可以表示企業(yè)內(nèi)的一特定部門。由此，一個企業(yè)中的發(fā)送者ID可以指"硬件商品"部門，而另一發(fā)送者ID可以指同一企業(yè)內(nèi)的"軟件商品"部門。由此，本發(fā)明的各實施例識別這些不同的配置，并相應(yīng)地標(biāo)識模式。結(jié)果，來自一個企業(yè)的相同的采購定單可以經(jīng)歷不同的模式標(biāo)識過程，使得例如根據(jù)配置項的值在合并的EDI文檔314中以XML生成適當(dāng)且不同的EDI數(shù)據(jù)。還可以理解，一個或多個附加配置項可由特定的商業(yè)合伙人配置或設(shè)置而不背離本發(fā)明的范圍。例如，一個合伙人可設(shè)置最少量的配置，而另一合伙人可在其參與者級別配置中定義詳細的配置項。現(xiàn)在參考圖7C，示出了具有其參與者級別配置的EDIFACT模式的屏幕截圖。在此示例中，與X12模式不同，目標(biāo)名稱空間可以基于發(fā)送者應(yīng)用程序ID(可任選)(諸如716中的UNG1.2和718中的UNG2.2)、版本720(UNG8)、以及交易集ID722的特定組合來配置。換言之，有可能對一發(fā)票EDI文檔有多個配置，每一配置都具有唯一的應(yīng)用程序id。在此情況下，可在運行時使用匹配特定應(yīng)用程序的目標(biāo)名稱空間。在其中沒有配置發(fā)送者應(yīng)用程序ID的情形中，發(fā)送者應(yīng)用程序ID值可以與來自攜帶相同的交易ID的現(xiàn)有記錄(例如，日志文件)的任何值進行匹配。在找到多個匹配的情況下，使用默認目標(biāo)名稱空間來確保當(dāng)存在歧義時使用適當(dāng)?shù)哪J值。圖7D是示出用于X12模式的全局級別配置的屏幕截圖。在此示例中，在諸如目標(biāo)名稱空間或版本等配置項未由交易合伙人指定的情況下，使用全局級別配置中的配置項的值。在此示例中，框724指示對版本和目標(biāo)名稱空間沒有配置任何值。由此，在運行時不修改配置項的值。在其中未配置全局級別下的某些缺少的配置項的情況下，使用管線級別或運行時級別配置中的配置項的值。由此，如果在全局級別沒有配置目標(biāo)名稱空間，則使用來自管線級別配置的值。在一個實施例中，管線級別配置中的值可由用戶設(shè)置。在另一實施例中，圖11B示出了其上可儲存本發(fā)明的各方面的計算機可讀介質(zhì)lllO。例如，接口組件1112從源批量接收EDI文檔，其中每個有EDI文檔具有對應(yīng)于一交易類型的至少一個EDI交易。交易組件1114通過應(yīng)用依照EDI標(biāo)準(zhǔn)(例如，X12或EDIFACT)的規(guī)則，根據(jù)相應(yīng)的交易類型來解碼EDI交易。配置組件1116對解碼的EDI交易中的每一EDI交易標(biāo)識一個或多個配置項中的值。模式組件1118基于配置項的值來確定一個或多個模式類型。在一替換實施例中，可在運行時修改在以上各節(jié)中描述的配置項的值。由此，對于交易類型、目標(biāo)名稱空間、版本的值可以在EDI引擎312處理EDI文檔(即，自動標(biāo)識模式)之后修改。在這一實施例中，改變將在尚待處理的后續(xù)文檔上反映。本發(fā)明的這一動態(tài)實現(xiàn)使得目的地306處的用戶能夠在運行時期間而非在EDI文檔從源304發(fā)送之前的模式設(shè)計/配置期間配置值。在操作中，自動模式標(biāo)識使得EDI合伙人能夠流線化對EDI文檔的處理。不像其中需要對每一合伙人并對每一文檔類型配置接收連接和發(fā)送連接的現(xiàn)有的實現(xiàn)，EDI引擎312啟用了自動模式標(biāo)識，使得配置項的值在運行時期間標(biāo)識和確定，從而使得EDI商業(yè)合伙人在處理EDI數(shù)據(jù)時能夠更靈活?？梢曰叵?，本發(fā)明的至少另一方面包括在接收到EDI數(shù)據(jù)時生成確認肯定應(yīng)答，圖8A是示出這一特征的流程圖。在802處，從源(例如，源304)向目的地(例如，目的地306)發(fā)送EDI消息(例如，EDI消息310)。在804處，在目的地處接收包括EDI交易的EDI消息。接著，在806處，通過確定該EDI消息是否預(yù)期送往正確的接收方，來確定EDI消息的傳輸是否有效。如果確定EDI消息的傳輸無效，則延緩對EDI消息的處理，并且在808處生成一交換失敗肯定應(yīng)答。如果確定EDI消息的交換是有效的，則接著在810處確定EDI交易組是否包括錯誤。如果組包括錯誤，則延緩對EDI交易組的處理，并且在812處生成一功能失敗肯定應(yīng)答。例如，EDI規(guī)范可定義可在組和交易集級別處找到的多個錯誤。表3提供了適用于X12EDI交換的常見錯誤的列表。<table>tableseeoriginaldocumentpage16</column></row><table>4功能組頭和尾中的組控制號不一致5包括的交易集的數(shù)量不匹配實際計數(shù)表3:功能組錯誤一與GS/GE段有關(guān)的錯誤例如，EDI引擎312通過標(biāo)識EDI消息中的行/段GS的第六個值來確定一錯誤，諸如錯誤代碼4，"功能組頭和尾中的組控制號不一致"。在圖8B中，行GS532的第六個值具有值"9"(如由框528所指示的)。在確認EDi交易時，本發(fā)明的各實施例確定在行GE534的第二個值中是否也存在相同的值。如圖8B所示，行GE534的第二個值是"10"(如由框530所指示的)。有了這一差異，確定在該EDI消息中存在錯誤。在另一示例中，通過標(biāo)識GS-GE段之間的交易集來檢測錯誤代碼5，"所包括的交易集的數(shù)量不匹配實際計數(shù)"。如圖8B所示，有一個GS-GE段，而GE行的第一個值是"02"，指示有兩個交易集。由此，該功能組有錯誤。然而，如果確定組中沒有錯誤，則接著在814處通過評估依照X12或EDIFACT格式的格式化規(guī)則和依照包括在EDI交易中的模式的規(guī)則來確定每一EDI交易是否有效。如果確定EDI交易無效，則延緩對EDI交易的處理，并在16處生成功能失敗肯定應(yīng)答。例如，表4提供了常見的交易錯誤的列表。代碼描述一來自AK502代碼列表1交易集不支持2缺少交易集尾頭和尾中的交易集控制號不匹配4所包括的段的數(shù)量不匹配實際計數(shù)5一個或多個段有錯誤6缺少或無效的交易集標(biāo)識符7缺少或無效的交易集控制號表4:交易集錯誤一與ST和SE內(nèi)的數(shù)據(jù)有關(guān)的錯誤使用圖8B作為一個示例，EDI引擎(例如，EDI引擎312)通過評估ST和SE之間的段(行)數(shù)來標(biāo)識錯誤代碼4，"所包括的段的數(shù)量不匹配實際計數(shù)"。在此示例中，該數(shù)量是"12"，而SE行中的第一個值是14。由此，在該交易集中有錯誤，并且這一錯誤代碼可被包括在功能失敗肯定應(yīng)答中。在一個實施例中，EDI引擎(例如，EDI引擎312)可參考或了解各種錯誤條件或EDI交易規(guī)則。在處理EDI文檔時，EDI引擎312確保沒有一個EDI格式化規(guī)則被違反。在任何違反的時候，EDI引擎312以交換或功能級別肯定應(yīng)答的形式適當(dāng)?shù)貓蟾?。或者，如果EDI交易有效，則目的地處的EDI引擎312在818處繼續(xù)處理EDI交易。在820處，生成指示EDI交易有效的確認肯定應(yīng)答。在一個實施例中，當(dāng)接收并確認EDI消息、EDI組禾P/或EDI交易時，EDI引擎312可比較并生成合并的確認肯定應(yīng)答。在另一實施例中，EDI引擎與接收EDI消息、EDI組和/或EDI交易基本同時地生成合并的確認肯定應(yīng)答。在824處，將所生成的確認肯定應(yīng)答返回給源，源在826處接收該確認肯定應(yīng)答。在一個實施例中，源打開用于發(fā)送EDI消息的連接會話并在關(guān)閉該同一連接會話之前接收確認肯定應(yīng)答。由此，在文檔確認期間沒有數(shù)據(jù)庫或數(shù)據(jù)存儲訪問或盤1/0，因為該確認過程是在運行時期間或在EDI交易的接收期間處理的，如由圖3的箭頭318所示。在又一實施例中，該確認過程可以通過在運行時插入處理程序來擴展。在一個替換實施例中，可以在接收EDI消息/交易的同時生成并向單獨的位置(這一位置信息可以在頭部分106中找到)發(fā)送不同的確認肯定應(yīng)答類型。由此，本發(fā)明的各實施例在一個或多個階段中(例如，在確認了交換的一方面之后)生成并發(fā)送確認肯定應(yīng)答，或在單個階段中生成并發(fā)送合并的肯定應(yīng)答。在又一實施例中，這些肯定應(yīng)答可以被配置成在同一或新的套接字連接會話上傳送到不同的目的地，如由圖3中的箭頭320所指示的。例如，假設(shè)模式或格式化規(guī)則指示針對采購定單的確認肯定應(yīng)答被配置成發(fā)送給企業(yè)的客戶服務(wù)部門，而發(fā)票確認肯定應(yīng)答被配置為發(fā)送給同一企業(yè)的會計部門。本發(fā)明的各方面允許通過打開新的連接會話來向正確的目的地發(fā)送相應(yīng)的肯定應(yīng)答。圖9A示出了用于X12格式化EDI交易的確認肯定應(yīng)答，而圖9B示出了用于EDIFACT格式化EDI交易的確認肯定應(yīng)答。在另一實施例中，圖IIC示出了其上可儲存本發(fā)明的各方面的計算機可讀介質(zhì)。例如，接口組件1122、肯定應(yīng)答組件1124、以及確認組件1126可被結(jié)合并集成到EDI引擎312中用于執(zhí)行如圖8A所描述的一個或多個步驟。本發(fā)明的其它方面允許修改EDI模式而無需最終用戶有EDI模式開發(fā)者那樣多的知識。例如，假設(shè)在企業(yè)內(nèi)建立一新的部門，但是對該新部門沒有采用定制EDI模式或規(guī)則。代替請求EDI模式開發(fā)者為該新部門設(shè)計一特定的EDI模式，本發(fā)明的各實施例定義一元模式來表示所有模式，使得各模式的特性被呈現(xiàn)給最終用戶以供修改。圖10A是示出根據(jù)本發(fā)明的一個實施例的用于修改多個EDI模式的單一元模式的屏幕截圖。在窗格1002中，單一元模式的結(jié)構(gòu)被呈現(xiàn)給最終用戶。一旦最終用戶加亮了一特性(由包圍"MaxOccurs(最大出現(xiàn)次數(shù))"的虛線框指示)，就在窗格1004中加亮一相應(yīng)的特性代碼段，從而允許最終用戶修改該特性的值。在一個實施例中，向最終用戶提供實施如圖10A所示的本發(fā)明的方面的用戶界面(UI)。附錄A完整地描述了圖IOA所示的XML模式。圖10B是示出根據(jù)本發(fā)明的一個實施例的用于使用單一元模式來修改多個EDI模式的方法的流程圖。在1006處，通過對多個EDI模式中的數(shù)據(jù)進行解碼來標(biāo)識表示這多個EDI模式的單一結(jié)構(gòu)。在一個示例中，諸如圖11D中的數(shù)據(jù)結(jié)構(gòu)1128等單一結(jié)構(gòu)通過捕捉以下數(shù)據(jù)中的一個或多個來表示多個EDI模式1.每一EDI模式包括具有名稱的根元素；2.根元素包括可以或者是Lo叩(循環(huán))或者是Segment(段)的重復(fù)數(shù)據(jù)塊；3.每一Loop具有以下結(jié)構(gòu)a.Name—循環(huán)的名稱b.Block—數(shù)據(jù)元素集合c.MinOccurs—最小出現(xiàn)次數(shù)d.MaxOccurs—最大出現(xiàn)次數(shù)4.每一Segment具有各種特性a.Name—段的名稱b.Tagld—段的標(biāo)簽IDc.MinOccurs—最小出現(xiàn)次數(shù)d.MaxOccurs—最大出現(xiàn)次數(shù)e.數(shù)據(jù)元素列表5.每一數(shù)據(jù)元素包括元素集合，每一元素可以或者是Composite(復(fù)合)元素或者是Simple(簡單)元素6.每一SimpleElement(簡單元素)具有各種特性a.Name—元素的名稱b.MinOccurs—最小出現(xiàn)次數(shù)c.MaxOccurs—最大出現(xiàn)次數(shù)d.MinLength—最小數(shù)據(jù)長度e.MaxLength—最大數(shù)據(jù)長度f.DataType—數(shù)據(jù)類型，允許的值是A、AN、ID、R、N、Date(日期)、Time(時間)一對每一EDI數(shù)據(jù)類型有一個g.AllowedValues—允許的值集，僅在元素為類型ID時才適用例如，數(shù)據(jù)結(jié)構(gòu)1128包括第一數(shù)據(jù)字段1130，該字段包括與多個EDI模式中的每一個的根元素相關(guān)聯(lián)的根數(shù)據(jù)。該數(shù)據(jù)結(jié)構(gòu)還包括一個或多個第二數(shù)據(jù)字段1132，該字段包括表示多個EDI模式中的每一個的一個或多個數(shù)據(jù)塊的數(shù)據(jù)。一個或多個第二數(shù)據(jù)字段中的數(shù)據(jù)是根據(jù)第一數(shù)據(jù)字段1130中的根數(shù)據(jù)來定義的。在1008處，確定要包括在單一結(jié)構(gòu)中的特性。該特性定義了多個EDI模式的特征。例如，具有特性值"purchaseorder"(采購定單)的根元素指示該單一結(jié)構(gòu)的特征對應(yīng)于諸如圖7A所示的采購定單模式。使用具有特性值的單一結(jié)構(gòu)，在1010處，根據(jù)所定義的特征和單一結(jié)構(gòu)為用戶定義單一元模式。所定義的元模式對應(yīng)于多個EDI模式。在1012處，將所定義的元模式中所確定的特性提供給最終用戶，使得最終用戶能夠如圖10A所示修改多個EDI模式中的每一個的特征。附錄B示出了表示具有以下結(jié)構(gòu)的采購定單模式的XML格式的示例性單一元模式1.PurchaseOrderDetail(采購定單細節(jié))段；2.由Lindtem(行項)和ShippingAddress(發(fā)貨地址)段構(gòu)成的Loop3.Notes(注解)段圖12示出了計算機130形式的通用計算設(shè)備的一個示例。在本發(fā)明的一個實施例中，諸如計算機130等計算機適用于此處所示并描述的其它附圖。計算機130具有一個或多個處理器或處理單元132以及系統(tǒng)存儲器134。在所示的實施例中，系統(tǒng)總線136將包括系統(tǒng)存儲器134的各種系統(tǒng)組件耦合到處理器132?？偩€136表示任意幾種總線結(jié)構(gòu)中的一種或多種，包括存儲器總線或存儲器控制器、外圍總線、加速圖形端口、以及使用各種總線體系結(jié)構(gòu)中的任一種的處理器或局部總線。作為示例而非局限，這類體系結(jié)構(gòu)包括工業(yè)標(biāo)準(zhǔn)體系結(jié)構(gòu)(ISA)總線、微通道體系結(jié)構(gòu)(MCA)總線、增強型ISA(EISA)總線、視頻電子技術(shù)標(biāo)準(zhǔn)協(xié)會(VESA)局部總線以及外圍部件互連(PCI)總線(也稱為小背板(Mezzanine)總線)。計算機130通常具有至少某種形式的計算機可讀介質(zhì)。計算機可讀介質(zhì)可包括易失性和非易失性、可移動和不可移動介質(zhì)，并且可以是可由計算機130訪問的任何可用介質(zhì)。作為示例而非局限，計算機可讀介質(zhì)包括計算機存儲介質(zhì)和通信介質(zhì)。計算機存儲介質(zhì)包括以用于儲存諸如計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其它數(shù)據(jù)等信息的任一方法或技術(shù)實現(xiàn)的易失性和非易失性，可移動和不可移動介質(zhì)。例如，計算機存儲介質(zhì)包括RAM、ROM、EEPROM、閃存或其它存儲器技術(shù)、CD-ROM、數(shù)字多功能盤(DVD)或其它光盤存儲、磁盒、磁帶、磁盤存儲或其它磁存儲設(shè)備、或可以用來儲存所期望的信息并可由計算機130訪問的任一其它介質(zhì)。通信介質(zhì)通常以諸如載波或其它傳輸機制等已調(diào)制數(shù)據(jù)信號來體現(xiàn)計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其它數(shù)據(jù)，并包括任一信息傳送介質(zhì)。本領(lǐng)域的技術(shù)人員熟悉已調(diào)制數(shù)據(jù)信號，它以對信號中的信息進行編碼的方式設(shè)置或改變其一個或多個特征。諸如有線網(wǎng)絡(luò)或直接連線連接等有線介質(zhì)，以及諸如聲學(xué)、RF、紅外和其它無線介質(zhì)等無線介質(zhì)都是通信介質(zhì)的示例。上述任一的組合也應(yīng)當(dāng)包括在計算機可讀介質(zhì)的范圍之內(nèi)。系統(tǒng)存儲器134包括可移動和/或不可移動、易失性和/或非易失性存儲器形式的計算機存儲介質(zhì)。在所示的實施例中，系統(tǒng)存儲器134包括只讀存儲器(ROM)138和隨機存取存儲器(RAM)140?；据斎?輸出系統(tǒng)142(BIOS)包括如在啟動時幫助在計算機130內(nèi)的元件之間傳輸信息的基本例程，它通常儲存在ROM138中。RAM140通常包含處理單元132立即可訪問和/或當(dāng)前正在操作的數(shù)據(jù)和/或程序模塊。作為示例而非局限，圖12示出了操作系統(tǒng)144、應(yīng)用程序146、其它程序模塊148和程序數(shù)據(jù)150。計算機130也可包括其它可移動/不可移動、易失性/非易失性計算機存儲介質(zhì)。例如，圖12示出了對不可移動、非易失性磁介質(zhì)進行讀寫的硬盤驅(qū)動器154。圖12還示出了對可移動、非易失性磁盤158進行讀寫的磁盤驅(qū)動器156,以及對可移動、非易失性光盤162，如CDROM或其它光介質(zhì)等可移動、非易失性光盤162進行讀寫的光盤驅(qū)動器160?？梢栽谑纠圆僮鳝h(huán)境中使用的其它可移動/不可移動、易失性/非易失性計算機存儲介質(zhì)包括但不限于，磁帶盒、閃存卡、數(shù)字多功能盤、數(shù)字錄像帶、固態(tài)RAM、固態(tài)ROM等等。硬盤驅(qū)動器154以及磁盤驅(qū)動器156和光盤驅(qū)動器160通常通過非易失性存儲器接口，如接口166連接到系統(tǒng)總線136。上文討論并在圖12中示出的驅(qū)動器或其它大容量存儲設(shè)備及其關(guān)聯(lián)的計算機存儲介質(zhì)為計算機130提供了計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊和其它數(shù)據(jù)的存儲。例如，在圖12中，示出硬盤驅(qū)動器154儲存操作系統(tǒng)170、應(yīng)用程序172、其它程序模塊174和程序數(shù)據(jù)176。注意，這些組件可以與操作系統(tǒng)144、應(yīng)用程序146、其它程序模塊148和程序數(shù)據(jù)150相同，也可以與它們不同。這里對操作系統(tǒng)170、應(yīng)用程序172、其它程序模塊174和程序數(shù)據(jù)176給予不同的標(biāo)號來說明至少它們是不同的副本。用戶可以通過輸入設(shè)備或用戶界面選擇設(shè)備，如鍵盤180和定位設(shè)備182(通常指鼠標(biāo)、跟蹤球或觸摸墊)向計算機130輸入命令和信息。其它輸入設(shè)備(未示出)可包括話筒、操縱桿、游戲手柄、圓盤式衛(wèi)星天線、掃描儀等等。這些和其它輸入設(shè)備通常通過耦合至系統(tǒng)總線136的用戶輸入接口184連接至處理單元132，但是也可以通過其它接口和總線結(jié)構(gòu)連接，如并行端口、游戲端口或通用串行總線(USB)。監(jiān)視器188或其它類型的顯示設(shè)備也通過接口，如視頻接口190連接至系統(tǒng)總線136。除監(jiān)視器188之外，計算機通常包括其它外圍輸出設(shè)備(未示出)，如揚聲器和打印機，它們可通過輸出外圍接口(未示出)連接。計算機130可以使用到一個或多個遠程計算機，如遠程計算機194的邏輯連接在網(wǎng)絡(luò)化環(huán)境中操作。遠程計算機194可以是個人計算機、服務(wù)器、路由器、網(wǎng)絡(luò)PC、對等設(shè)備或其它常見的網(wǎng)絡(luò)節(jié)點，并通常包括許多或所有相對于計算機130所描述的許多或所有元件。圖12描述的邏輯連接包括局域網(wǎng)(LAN)196和廣域網(wǎng)(WAN)198，但也可包括其它網(wǎng)絡(luò)。LAN136和/或WAN138可以是有線網(wǎng)絡(luò)、無線網(wǎng)絡(luò)或其組合等等。這類網(wǎng)絡(luò)環(huán)境常見于辦公室、企業(yè)范圍計算機網(wǎng)絡(luò)、內(nèi)聯(lián)網(wǎng)以及全球計算機網(wǎng)絡(luò)(例如，因特網(wǎng))。當(dāng)在局域網(wǎng)環(huán)境中使用時，計算機130通過網(wǎng)絡(luò)接口或適配器186連接至LAN196。當(dāng)在廣域網(wǎng)環(huán)境中使用時，計算機130通常包括調(diào)制解調(diào)器178或用于通過WAN198，如因特網(wǎng)建立通信的其它裝置。調(diào)制解調(diào)器178可以是內(nèi)置或外置的，它通過用戶輸入接口184或其它適當(dāng)?shù)臋C制連接至系統(tǒng)總線136。在網(wǎng)絡(luò)化環(huán)境中，相對于計算機130所描述的程序模塊或其部分可儲存在遠程存儲器存儲設(shè)備(未示出)中。作為示例而非局限，圖12示出遠程應(yīng)用程序192駐留在存儲器設(shè)備上。示出的網(wǎng)絡(luò)連接是示例性的，也可以使用在計算機之間建立通信鏈路的其它手段。一般而言，計算機130的數(shù)據(jù)處理器借助在不同時刻儲存在計算機的各種計算機可讀存儲介質(zhì)中的指令來編程。程序和操作系統(tǒng)通常例如在軟盤或CD-ROM上分發(fā)。從這些盤上，它們被安裝或加載到計算機的次級存儲器中。在執(zhí)行時，它們被至少部分地加載到計算機的主電子存儲器中。當(dāng)這些和其它各種類型的計算機可讀存儲介質(zhì)包括用于實現(xiàn)在下文中結(jié)合微處理器或其它數(shù)據(jù)處理器描述的步驟的指令或程序時，此處所描述的本發(fā)明的各方面包括這種介質(zhì)。此外，當(dāng)依照此處所描述的方法和技術(shù)來編程時，本發(fā)明的各方面包括計算機本身。出于圖示的目的，諸如操作系統(tǒng)等程序和其它可執(zhí)行程序組件此處被示為離散的框。然而，可以認識到，這些程序和組件在各種時刻駐留在計算機的不同存儲組件中，并且由計算機的數(shù)據(jù)處理器來執(zhí)行。盡管結(jié)合包括計算機130的示例性計算系統(tǒng)環(huán)境描述，但本發(fā)明的各實施例可以使用眾多其它通用或?qū)Ｓ糜嬎阆到y(tǒng)環(huán)境或配置來操作。該計算系統(tǒng)環(huán)境并不旨在對本發(fā)明的任何方面的使用范圍或功能提出任何局限。此外，也不應(yīng)將該計算系統(tǒng)環(huán)境解釋為對該示例性操作環(huán)境中示出的任一組件或其組合具有任何依賴或需求。適用于本發(fā)明的各方面的眾所周知的計算系統(tǒng)、環(huán)境和/或配置的示例包括但不限于，個人計算機、服務(wù)器計算機、手持式或膝上型設(shè)備、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、機頂盒、可編程消費電子產(chǎn)品、移動電話、網(wǎng)絡(luò)PC、小型機、大型計算機機、包括任一上述系統(tǒng)或設(shè)備的分布式計算環(huán)境等等。本發(fā)明可在諸如程序模塊等由一個或多個計算機或其它設(shè)備執(zhí)行的計算機可執(zhí)行指令的一般上下文環(huán)境中描述。一般而言，程序模塊包括但不限于，執(zhí)行特定的任務(wù)或?qū)崿F(xiàn)特定的抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等等。本發(fā)明的各方面也可以在其中任務(wù)由通過通信網(wǎng)絡(luò)鏈接的遠程處理設(shè)備來執(zhí)行的分布式計算環(huán)境中實踐。在分布式計算環(huán)境中，程序模塊可以位于包括存儲器存儲設(shè)備的本地和遠程計算機存儲介質(zhì)中。接口可以是諸如Java2平臺企業(yè)版本(J2EE)、COM或分布式COM(DCOM)示例中的緊耦合的同步實現(xiàn)。作為替代或除此之外，接口可以是諸如web服務(wù)(例如，使用簡單對象訪問協(xié)議)中的松耦合的異步實現(xiàn)。一般而言，接口包括以下特征的任一組合緊耦合的、松耦合的、同步和異步。此外，接口可符合標(biāo)準(zhǔn)協(xié)議、專有協(xié)議、或標(biāo)準(zhǔn)和專有協(xié)議的任何組合。此處所描述的接口可以都是單個接口的一部分，或者可以被實現(xiàn)為單獨的接口或其中的任何組合。接口可以本地或遠程地執(zhí)行以提供功能。此外，接口可包括比此處所示或所描述的更多或更少的功能。在操作中，計算機130執(zhí)行諸如在圖中所示的計算機可執(zhí)行指令來實現(xiàn)本發(fā)明的各方面。此處所示且描述的本發(fā)明的各實施例中的操作的執(zhí)行或?qū)崿F(xiàn)順序不是必要的，除非另外指定。即，操作可以用任何順序來執(zhí)行，除非另外指定，且本發(fā)明的各實施例可包括比此處所公開的更多或更少的操作。例如，可以構(gòu)想，在另一操作之前、與其同時或之后執(zhí)行或?qū)崿F(xiàn)特定操作是在本發(fā)明的各方面的范圍之內(nèi)。本發(fā)明的各實施例可以用計算機可執(zhí)行指令來實現(xiàn)。計算機可執(zhí)行指令可被組織成一個或多個計算機可執(zhí)行組件或模塊。本發(fā)明的各方面可以用任意數(shù)量或組織的這些組件或模塊來實現(xiàn)。例如，本發(fā)明的各方面不限于在圖中所示并在此處所描述的具體計算機可執(zhí)行指令或具體組件或模塊。本發(fā)明的其它實施例可包括具有比此處所示并描述的更多或更少功能的不同的計算機可執(zhí)行指令或組件。當(dāng)介紹本發(fā)明或其實施例的各方面的元素時，冠詞"一"、"一個"、"該"和"所述"意指存在一個或多個元素。術(shù)語"包括"、"包含"和"具有"旨在是包含性的，且意味著除所列出的元素之外還可以有其它元素。由于可在以上構(gòu)造、產(chǎn)品和方法中作出各種改變而不背離本發(fā)明的各方面的范圍，因此包含在以上描述中并在附圖中所示的所有主題都旨在被解釋為說明性的而非限制的意義。附錄A節(jié)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節(jié)2:使用元模式單一結(jié)構(gòu)的示例采購定單模式<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>權(quán)利要求1.一種至少部分地由計算設(shè)備實現(xiàn)的、用于變換電子數(shù)據(jù)交換(EDI)交易的方法，所述方法包括批量接收EDI數(shù)據(jù)，所述批量EDI數(shù)據(jù)包括多個EDI文檔，每一EDI文檔具有對應(yīng)于一交易類型的至少一個EDI交易；通過根據(jù)EDI標(biāo)準(zhǔn)對所接收的EDI數(shù)據(jù)進行解碼來標(biāo)識包括在所述EDI文檔中的EDI交易；以及從所述批量的多個EDI文檔中生成一合并的EDI文檔，所述合并的EDI文檔包括根據(jù)所述交易類型組織的所標(biāo)識的EDI交易的EDI數(shù)據(jù)。2.如權(quán)利要求l所述的方法，其特征在于，所述合并的EDI文檔是可擴展標(biāo)記語言(XML)文檔。3.如權(quán)利要求2所述的方法，其特征在于，還包括按照XML標(biāo)簽來組織包括在所述合并的EDI文檔中的EDI交易，其中所述XML標(biāo)簽指示所述EDI交易的交易類型。4.如權(quán)利要求l所述的方法，其特征在于，所述合并的EDI文檔包括一乳模式，所述乳模式表示被所述EDI交易參考的多個模式。5.如權(quán)利要求4所述的方法，其特征在于，還包括定義用于變換所述多個模式以便在運行時期間處理的運行時模式映射。6.如權(quán)利要求l所述的方法，其特征在于，還包括根據(jù)包括在所述EDI交易中的一個或多個信息將所述合并的EDI文檔中的EDI交易組織為子文檔，并且其中所述子文檔中的EDI交易與所述多個EDI文檔中的EDI交易相關(guān)。7.如權(quán)利要求1所述的方法，其特征在于，一個或多個計算機可讀介質(zhì)具有用于執(zhí)行如權(quán)利要求1所述的方法的計算機可執(zhí)行指令。8.—種用于在發(fā)送源和接收設(shè)備之間變換電子數(shù)據(jù)交換(EDI)交易的系統(tǒng)，所述系統(tǒng)包括用于批量發(fā)送EDI數(shù)據(jù)的發(fā)送源，所述批量EDI數(shù)據(jù)包括多個EDI文檔，每一EDI文檔具有對應(yīng)于一交易類型的至少一個EDI交易；用于接收所述批量EDI數(shù)據(jù)的接口；用于執(zhí)行計算機可執(zhí)行指令的處理器，所述指令用于通過根據(jù)EDI標(biāo)準(zhǔn)對所接收的EDI數(shù)據(jù)進行解碼來標(biāo)識包括在所述多個EDI文檔中的EDI交易；以及從所述批量EDI數(shù)據(jù)的多個EDI文檔中定義一合并的EDI文檔，所述合并的EDI文檔包括根據(jù)所述交易類型組織的所標(biāo)識的EDI交易。9.如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述合并的EDI文檔是可擴展標(biāo)記語言(XML)文檔。10.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述處理器還被配置成按照XML標(biāo)簽來組織包括在所述合并的EDI文檔中的EDI交易，其中所述XML標(biāo)簽指示所述EDI交易的交易類型。11.如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述合并的EDI文檔包括一乳模式，所述乳模式表示被所述EDI交易參考的多個模式。12.如權(quán)利要求ll所述的系統(tǒng)，其特征在于，所述接口還接收用于變換所述多個模式以便在運行時期間由所述的處理器處理的運行時模式映射。13.如權(quán)利要求12所述的系統(tǒng)，其特征在于，所述處理器被配置成應(yīng)用所述運行時模式映射以在運行時期間匹配所述多個模式。14.如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述處理器還被配置成根據(jù)包括在所述EDI交易中的一個或多個信息將所述合并的EDI文檔中的EDI交易組織為子文檔，并且其中所述子文檔中的EDI交易與所述多個EDI文檔中的EDI交易相關(guān)。15.—種或多種具有用于變換電子數(shù)據(jù)交換(EDI)交易的計算機可執(zhí)行組件的計算機可讀介質(zhì)，所述計算機可執(zhí)行組件包括用于從一發(fā)送源批量接收EDI數(shù)據(jù)并將所接收的EDI數(shù)據(jù)發(fā)送給一接收方的接口組件，所述批量EDI數(shù)據(jù)包括多個EDI文檔，每一EDI文檔具有對應(yīng)于一交易類型的至少一個EDI交易；用于通過根據(jù)EDI標(biāo)準(zhǔn)對所接收的EDI數(shù)據(jù)進行解碼來標(biāo)識包括在所述多個EDI文檔中的EDI交易的標(biāo)識組件；以及用于從所述批量EDI數(shù)據(jù)的多個EDI文檔中定義一合并的EDI文檔的變換組件，所述合并的EDI文檔包括根據(jù)所述交易類型組織的所標(biāo)識的EDI交易。16.如權(quán)利要求15所述的計算機可讀介質(zhì)，其特征在于，所述合并的EDI文檔是可擴展標(biāo)記語言(XML)文檔。17.如權(quán)利要求16所述的計算機可讀介質(zhì)，其特征在于，還包括用于按照XML標(biāo)簽來組織包括在所述合并的EDI文檔中的EDI交易的文檔組件，其中所述XML標(biāo)簽指示所述EDI交易的交易類型。18.如權(quán)利要求17所述的計算機可讀介質(zhì)，其特征在于，所述文檔組件還根據(jù)包括在所述EDI交易中的一個或多個信息將所述合并的EDI文檔中的EDI交易組織為子文檔，并且其中所述子文檔中的EDI交易與所述多個EDI文檔中的EDI交易相關(guān)。19.如權(quán)利要求15所述的計算機可讀介質(zhì)，其特征在于，所述合并的EDI文檔包括一乳模式，所述乳模式表示被所述EDI交易參考的多個模式。20.如權(quán)利要求15所述的計算機可讀介質(zhì)，其特征在于，所述接口組件還接收用于變換所述多個模式以便在運行時期間由所述的處理器處理的運行時模式映射。全文摘要用于變換電子數(shù)據(jù)交換(EDI)交易的可擴展標(biāo)記語言(XML)規(guī)范。批量接收EDI數(shù)據(jù)的集合。該批量EDI數(shù)據(jù)包括多個EDI文檔，并且這多個EDI文檔中的每一個具有對應(yīng)于一交易類型的至少一個EDI交易。包括在EDI文檔中的EDI交易通過根據(jù)EDI標(biāo)準(zhǔn)對所接收的EDI數(shù)據(jù)進行解碼來標(biāo)識。從批量EDI數(shù)據(jù)中EDI文檔生成一合并的EDI文檔。該合并的EDI文檔包括根據(jù)交易類型組織的所標(biāo)識的EDI交易。文檔編號H04L12/56GK101331511SQ200680047362公開日2008年12月24日申請日期2006年11月17日優(yōu)先權(quán)日2005年12月16日發(fā)明者S·瑪什拉洙,S·高拉夫申請人:微軟公司