電子數(shù)據(jù)與企業(yè)ERP內部通信

　　1 原有模式的缺點

　　當前國內外ERP內部信息交換由于沒有相應的標準，不同的ERP軟件產品都采用各自的數(shù)據(jù)交換方式，一般采用直接或間接訪問數(shù)據(jù)庫的方式來得到需要的數(shù)據(jù)。這樣做可以加快數(shù)據(jù)處理的速度。但是在企業(yè)實施、整合或更新，特別是面對不同的ERP系統(tǒng)時，不同的語義和數(shù)據(jù)結構都可能成為障礙。

　　1. 1系統(tǒng)模塊添加

　　在信息化的過程中，一些企業(yè)在初期可能存在企業(yè)信息化人才和計算機設備缺乏等情況，從實際情況和成本方面考慮，往往會采用只采用部分ERP模塊或開發(fā)一些信息系統(tǒng)，在信息化比較成熟的時候再切換到ERP系統(tǒng)。比如許多企業(yè)的信息化都是從會計電算化開始的，在條件成熟的時候，再開始增加模塊或直接上ERP系統(tǒng)。在上ERP系統(tǒng)的時候是選擇全新的系統(tǒng)，還是在成熟的系統(tǒng)上進行升級，是企業(yè)經(jīng)常面對的一個問題。放棄熟悉的系統(tǒng)而轉向一個全新的系統(tǒng)，對企業(yè)而言不僅是極大的資源浪費，而且還要承受更大的風險。在選擇系統(tǒng)升級和添加新的系統(tǒng)模塊時，經(jīng)常面對的一個問題就是如何使新的系統(tǒng)與原系統(tǒng)進行平滑轉換。由于不同的ERP系統(tǒng)可能采用完全不同的數(shù)據(jù)庫系統(tǒng)和系統(tǒng)流程，數(shù)據(jù)庫不兼容、流程差異等都可能造成ERP實施的失敗。

　　1. 2不同系統(tǒng)整合

　　在一個企業(yè)中運行不同的ERP系統(tǒng)并不是很常見，但是出現(xiàn)的問題也許是致命的。在企業(yè)整合過程中，這種情況就可能出現(xiàn)，往往是在要聯(lián)合的企業(yè)分別運行了不同的ERP系統(tǒng)，這樣就常常要求ERP系統(tǒng)整合。由于不同的企業(yè)可能采用不同的ERP軟件，而且企業(yè)的規(guī)模越大難度就越大，在整合失敗的情況下，造成的損失就越大。由于在實際情況中，各個企業(yè)信息化環(huán)境不同，如果ERP系統(tǒng)整合不好就會形成兩個企業(yè)的信息相對獨立，就會形成一個“信息孤島”，使每個系統(tǒng)相對獨立又相互封閉。在明基、西門子手機部門兼并過程中，ERP整合失敗是造成兼并失敗的一個重要原因。

　　2 EDI的工作模式

　　在ERP的發(fā)展過程中，企業(yè)原來的單一企業(yè)向以供應鏈為主導的虛擬企業(yè)發(fā)展，企業(yè)間的合作不斷加強。為了解決企業(yè)間的ERP系統(tǒng)間的信息交流問題，早在上世紀60年代，歐洲和美國幾乎同時提出了EDI的概念。EDI(Electronic Data Interchange，電子數(shù)據(jù)交換)通過計算機通信網(wǎng)絡將企業(yè)間商業(yè)信息，用一種國際公認的標準格式，實現(xiàn)各有關部門或公司與企業(yè)之間的數(shù)據(jù)交換與處理，并完成以貿易為中心的全部過程。國際標準化組織(ISO)將EDI描述為：“將貿易(商業(yè))或行政事務處理按照一個公認的標準變成結構化的事務處理或信息數(shù)據(jù)格式，從計算機到計算機的電子傳輸”。

　　早期的EDI系統(tǒng)實施費用昂貴，隨著XML技術的出現(xiàn)，聯(lián)合國貿易促進及電子商務中心(UN/CEFACT)和美國結構信息標準高級組織(OASIS)又提出了ebXML(Electronic Business using eXtensible Markup Language)的解決方案。ebXML作為一種廉價的EDI實現(xiàn)技術得到了迅速的發(fā)展。

　　ebXML作為一種企業(yè)間的數(shù)據(jù)傳輸?shù)慕鉀Q方案很好地消除了ERP系統(tǒng)間的數(shù)據(jù)差異問題。在解決這個問題之前，我們可以參考一下ebXML的工作模式。ebXML是一組標準化規(guī)范，它使得不同規(guī)模、不同地域的企業(yè)通過互聯(lián)網(wǎng)進行商務通信。通過使用ebXML，公司可以使用標準化的方法去交換商業(yè)信息、開展貿易關系、用正常術語聯(lián)絡信息、定義和注冊業(yè)務流程。

　　在ebXML的使用過程中，企業(yè)間的XML格式差異都是通過ebXML注冊中心來消除的。在ebXML注冊中心將不同公司的相同信息一一對應起來，在不同公司要求獲取數(shù)據(jù)的時候，將需要的公司信息轉換為請求可以識別的ebXML格式。

　　3 模塊間通信的標準化

　　在信息系統(tǒng)設計開發(fā)中，對于數(shù)據(jù)流和數(shù)據(jù)字典中格式的最終實現(xiàn)是由于系統(tǒng)開發(fā)時采用的開發(fā)工具與系統(tǒng)模型相關。在實際的應用中，由于對內部數(shù)據(jù)格式?jīng)]有統(tǒng)一的規(guī)定，不同的ERP系統(tǒng)，或者同一ERP系統(tǒng)不同版本的內部交換格式都可能是不同的，這樣就對系統(tǒng)的整合及二次開發(fā)帶來一定的難度。

　　雖然在不同的語言中，也存在各自的數(shù)據(jù)交換語言，比如Ajax技術中就采用JSON作為其數(shù)據(jù)交換的標準。由于Ajax使用的JavaScript是一種腳本語言，腳本語言較低的效率和缺少XML解釋器使得Ajax放棄了對XML的選擇而轉向了簡潔的JSON，雖然JSON在數(shù)據(jù)格式和使用上都比XML簡潔，然而JSON專注于JavaScript方面的數(shù)據(jù)交換，缺乏語言的兼容性，而且JSON不是一個標準化的格式，穩(wěn)定性和安全性都不能很好地保證，所以在普及方面還是有很多的問題。

　　類似的技術是ADO.Net采用了XML作為數(shù)據(jù)交換的中間格式，XML作為數(shù)據(jù)交換的統(tǒng)一格式為其實現(xiàn)跨數(shù)據(jù)庫提供了基礎。由于ADO技術只是作為一種跨數(shù)據(jù)庫的數(shù)據(jù)操作方式而設計，對于數(shù)據(jù)含義的統(tǒng)一和解釋并不是必要的。同時，在新一代的數(shù)據(jù)庫存儲技術中，XML已成為新的數(shù)據(jù)庫存儲格式，XML在Web應用中也起到了舉足輕重的作用。而在桌面應用中，XML也已成為很好的數(shù)據(jù)存儲格式。XML作為新一代的數(shù)據(jù)存儲標準，XML著眼于數(shù)據(jù)存儲及數(shù)據(jù)的呈現(xiàn)，作為下一代的網(wǎng)絡語言XML是成功的。然而在語義統(tǒng)一方面，XML并沒有做出相應的規(guī)定，不能作為模塊間通信的數(shù)據(jù)交換語言。

　　4 如何使用ebXML消除數(shù)據(jù)差異

　　消除模塊間的信息交換格式不統(tǒng)一的問題，成熟的ebXML似乎是一個可行的解決方案。由于ebXML在設計之初就是為了統(tǒng)一不同系統(tǒng)間的通信格式，作為系統(tǒng)內部數(shù)據(jù)交換的統(tǒng)一格式，也是非常合適的。

　　在系統(tǒng)設計時，系統(tǒng)設計人員就根據(jù)需要對系統(tǒng)做出系統(tǒng)設計，數(shù)據(jù)字典和數(shù)據(jù)流是其中重要的一部分，合理高效的數(shù)據(jù)流是好的信息系統(tǒng)的基礎，在信息系統(tǒng)試運行期間，針對用戶變化的需求有時可能要對數(shù)據(jù)做出一定的修改和完善，如何在變化的需求中保持系統(tǒng)的穩(wěn)健性是信息系統(tǒng)設計開發(fā)者需要考慮的一個問題。在系統(tǒng)模塊直接訪問數(shù)據(jù)的開發(fā)方式下，一旦某個數(shù)據(jù)流需要做出修改，涉及的模塊都要做出相應的修改。而利用ebXML將數(shù)據(jù)流進行對象化封裝是一個比較好的解決方案。

　　在ebXML的實施中，不同系統(tǒng)的的差異由ebXML注冊中心來消除，不同含義的XML信息通過在注冊處查找對方的定義來實現(xiàn)轉換，對于不同的數(shù)據(jù)信息也可以采用類似的處理辦法來進行轉換，我們可以在ERP系統(tǒng)與數(shù)據(jù)庫之間加入EDI翻譯層作為ERP系統(tǒng)與數(shù)據(jù)庫交互的中介，系統(tǒng)中各個模塊間的數(shù)據(jù)流可以在EDI翻譯層定義，所有的數(shù)據(jù)相關定義存儲在EDI翻譯層，ERP的各個模塊不再直接對數(shù)據(jù)庫進行操作，在系統(tǒng)模塊請求的時候，只是向EDI翻譯層發(fā)出數(shù)據(jù)流請求，而EDI翻譯層將根據(jù)系統(tǒng)設計時預定義的數(shù)據(jù)流格式，從數(shù)據(jù)庫獲得并轉換為XML格式報文返回給ERP系統(tǒng)。

　　而對于外部系統(tǒng)的數(shù)據(jù)操作同樣由EDI翻譯層來消除差異性，在不同的ERP系統(tǒng)互聯(lián)的時候，首先要在EDI翻譯層對對方的數(shù)據(jù)流和數(shù)據(jù)字典做出對應的數(shù)據(jù)解釋，即將對方的數(shù)據(jù)流和自己的數(shù)據(jù)庫對應起來。在不同系統(tǒng)間通信時，如果需要外部數(shù)據(jù)，則對EDI翻譯層發(fā)出數(shù)據(jù)請求，己方的EDI翻譯層收到后將請求轉發(fā)給被請求方的EDI翻譯層，對方的EDI翻譯層收到后則根據(jù)定義數(shù)據(jù)格式做出反應和處理，然后將要求的數(shù)據(jù)返回給發(fā)送方的EDI翻譯層，己方的EDI翻譯層再把數(shù)據(jù)返回給ERP模塊，這樣完成整個數(shù)據(jù)處理過程(參見圖2)。即在全局方面，EDI翻譯層也可以作為ebXML的端點來實現(xiàn);在內部系統(tǒng)中，EDI翻譯層又是ebXML的本地化的實現(xiàn)。所以在具體實施中，EDI翻譯層并不與ebXML沖突，兩者可以很好地結合在一起。

　　5 在企業(yè)開發(fā)中的意義

　　在ERP系統(tǒng)與數(shù)據(jù)庫中間加入翻譯層，使得數(shù)據(jù)層與處理層分離的開發(fā)方法不僅在ERP系統(tǒng)整合等應用中發(fā)揮作用，而且對于ERP系統(tǒng)設計也有著重要意義。采用這種方法使得ERP軟件的設計與數(shù)據(jù)庫無關，對于設計人員而言，在針對不同數(shù)據(jù)庫的開發(fā)中，不需要關注數(shù)據(jù)庫之間的差異，而由EDI翻譯層來消除其間的差異。在新版本開發(fā)中，數(shù)據(jù)流的修改不再影響到整個系統(tǒng)，只要在EDI翻譯層修改數(shù)據(jù)流及數(shù)據(jù)字典的定義即可。在系統(tǒng)設計時，針對在對在不同企業(yè)、但企業(yè)流程相同或相似的系統(tǒng)，開發(fā)人員只要針對企業(yè)做出不同的數(shù)據(jù)定義，而應用部分則不需要完全重新開發(fā)。另外在XML開發(fā)中，還可以通過XSL使界面和數(shù)據(jù)分離，經(jīng)過層次的分離后，ERP系統(tǒng)設計者可以專注于ERP系統(tǒng)的流程，而從具體的數(shù)據(jù)處理工作中擺脫出來，這樣不僅降低了ERP系統(tǒng)的開發(fā)難度，還增強了系統(tǒng)的柔性，針對企業(yè)定制ERP系統(tǒng)的難度將得到降低，對于提高ERP實施的成功率有很大的促進作用。

　　作為信息系統(tǒng)設計的一種數(shù)據(jù)解決方式，采用數(shù)據(jù)層、系統(tǒng)處理層分離設計的做法可以使開發(fā)人員專注于自己的模塊，大大提高工作效率。

　　然而，由于在數(shù)據(jù)處理的過程中從數(shù)據(jù)庫得到的數(shù)據(jù)和用戶發(fā)送的數(shù)據(jù)都要由EDI翻譯層進行轉換，這樣必定會降低數(shù)據(jù)處理的效率。在ERP信息系統(tǒng)中，一般來說，數(shù)據(jù)處理速度不是系統(tǒng)的瓶頸，且ERP系統(tǒng)一般都是部署在企業(yè)內部網(wǎng)中，網(wǎng)絡速度和系統(tǒng)轉換速度都不會對系統(tǒng)處理速度造成很大的影響。與其帶來的效益相比，這些都是可以接受的。這種方法對于開發(fā)通用ERP系統(tǒng)的意義尤為明顯。

　　6 結束語

　　ERP系統(tǒng)的整合是一項重要的工程，并非單純的數(shù)據(jù)整合。本文旨在提出一種跨系統(tǒng)、跨數(shù)據(jù)庫的數(shù)據(jù)整合方案，通過ebXML的數(shù)據(jù)轉換將不同類型的數(shù)據(jù)轉換為系統(tǒng)可用的XML數(shù)據(jù)格式，在不同的系統(tǒng)中的數(shù)據(jù)格式識別問題由ebXML注冊中心來解決。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]