0 引言
集團企業是現代市場經濟發展到一定階段的必然產物。隨著中國經濟的迅速發展和企業大規模的兼并重組。出現了一大批具有較強市場競爭能力的大型集團企業。這些企業是中國經濟發展的中堅力量，掌握著國家的經濟命脈。
集團企業一般具有下述特征：
(1)以產權關系為紐帶，以母子公司為主體；
(2)金字塔式的層級組織結構；
(3)地域分散的多法人聯合體。
ERP軟件是現代管理技術和現代信息技術結合的產物，是集團企業實現信息集成、有效規范管理的重要使能技術。目前的集團企業ERP主要有兩種系統結構：集中式和分布式。集中式ERP一般是基于B／S結構的多層應用系統，具有管理維護簡單、便于監控下屬企業、數據集中、管理集中以及便于數據挖掘分析等優點，相比分布式系統其缺點是可靠性相對較低，系統一旦出現問題會影響整個企業集團的業務運行。與集中式的B／S結構的應用系統相比，分布式的C／S系統可充分利用客戶機強大的處理能力，應用功能更加豐富，運行效率也較高，但其缺點是數據相對分散，難以在整個集團企業范圍內實現無重復、無沖突的共享，集團管理層也很難站在整個集團的高度對數據進行深度挖掘分析以作為輔助決策的依據。
從上面的分析可見，在分布式系統的基礎上實現數據集中可較好的結合二者的優點，解決分布和集中的矛盾，使集團企業ERP在保持較高可靠性和運行效率的基礎上實現數據集中，更好的發揮ERP對企業管理的提升作用。為實現此目的，筆者設計了一個基于通訊中間件的數據集中應用系統，該系統主要運行于ERP的后臺數據庫服務器上。
1 總體設計
ERP系統的數據可分為三類：公有基礎字典、私有基礎字典、一般業務數據。公有基礎字典需要在整個企業集團內共享，比如集團企業的組織機構信息、集團公有會計科目、集團公有報表格式和公式等。公有基礎字典是集團實現規范管理的基礎，在整個集團企業內保持一致，一般由集團總部統一維護，然后統一下發到各下屬單位，除非總部授權，一般下屬單位沒有維護權限。私有基礎字典是需要各分支單位根據其業務特點和經營范圍自行維護的基礎數據，比如本單位組織結構、人員信息、私有會計科目、往來單位、設備、BOM、工藝路線、能力參數等信息。私有基礎字典雖然由各單位自行維護，但需要遵守集團統一的編碼和命名規范。同時部分私有基礎字典也可能被其他單位所引用，也需要在整個集團內共享。公有基礎字典和私有基礎字典的共同特點是數據量小、更新頻率低。一般業務數據是企業日常經營活動所產生的數據，比如企業的生產、物流、財務等信息。這類數據的特點是數據量大、更新頻率高，除在有經濟往來的單位外，一般不需要在各同級的單位之間共享，但需要匯總到上級單位和集團總部進行數據挖掘和數據分析，以作為決策支持的依據。
針對不同的數據，系統采用不同的數據復制策略。對于公有基礎字典數據采用只下載不上傳的策略；對于需要全局共享的私有基礎字典定時的上傳和下載，以保持數據在整個集團的一致性，對不需要全局共享的私有基礎數據處理方法等同于一般業務數據；對業務數據一般采取只上傳不下載的策略，有業務往來的單位之間采用定點傳輸的方式實現數據共享。對于部分業務數據比如物流、庫存等數據，需要通過廣域網的方式到其他單位查詢相關數據，如果這種異地請求過于頻繁，將會嚴重影響數據庫服務器的處理性能和業務處理的響應時間，因此對庫存等部分業務數據也采用全局復制的方式，即在所有數據庫服務器之間進行同步復制。
系統還采用了通訊中間件以實現地域分散的各子(分)公司之間以及他們與集團總部的通訊。通訊中間件可采用IBM的MQ消息中間件或國內廠商的一些成熟產品。通訊中間件運行于系統中所有的數據庫服務器和部分進行業務處理的微機上，其作用是屏蔽硬件和網絡傳輸機制以及操作系統的差異，為軟件系統間的通信建立一個基于命名服務的虛擬網絡，如圖1所示。
圖1 基于通訊中間件的虛擬網應用
根據集團企業呈典型的樹狀結構的組織機構特點，對每個子(分)公司給予邏輯上統一的上下級節點編碼，不同單位之間的數據復制只針對其直接上下級節點進行，這樣逐級進行，最終在全網內實現數據復制。在增加一個網絡節點時，只需按統一的編碼規則對其進行編碼，在接入網絡后，即可實現對該節點的復制。
對于某些特定業務，比如統計查詢，如果涉及到對海量數據的處理，直接通過前臺軟件來處理可能需要很長的時間，因此有必要利用服務器強大的處理能力，根據具體需要對數據進行一定的預處理(包括及時或定時處理)得到一些中間處理結果，這樣有利于縮短系統對這些特定業務的響應時間。
2 系統實現技術
數據集中系統的實現技術主要包括兩方面：數據報文的組成和數據復制方法。
2.1 數據報文
數據報文格式的定義對數據集中程序的編碼和維護起著至關重要的作用，它決定了對數據的打包和解包的方式以及對數據處理的各個方面。
在報文的壓縮和加密方面，系統將直接利用通訊中間件提供的壓縮機制和安全管理功能。數據加密是通過某種算法對數據進行編碼防止信息被非法獲取，比較常用的方法都是基于復雜的算法，通過密鑰來對進行數據加密，主要的算法有DESTriple、DES、RC2／RC4／RC5、RSA等。
在報文格式方面，由于ERP中需要復制業務數據類型較多，有大量的基礎數據和業務數據在各分支機構數據庫服務器之間進行復制，因此有必要對報文格式采用統一的編碼規則，以便于數據集中系統中報文處理模塊的維護。
從ERP的業務特點和功能實現的角度出發，設計的數據集中系統報文格式如圖2所示：
圖2 數據報文格式圖
下面對報文格式中各個部分作用加以詳細說明：
(1)業務類型：指明報文的業務類型，它決定了對哪一個數據表進行操作，由4個字節構成：第一個字節：表示子系統編號，如：①生產系統；②物流系統；③財務系統；④人事系統等。第二個字節：表示子系統中的業務類編號，如：①公有基礎字典；②私有基礎字典；③一般業務數據。第三、四兩個字節：表示子系統中的某種業務類中具體數據類型的編號：0l一50為需要全網復制的數據；51—70為逐級向上復制的數據；71—80為需要逐級向下復制的數據；81—99為定點復制的數據。
例如，如果報文頭為1301，則說明報文數據為生產系統中的需要全網復制的業務數據中某個數據表的編號。
(2)消息類型：指明報文內容是需要復制的原始數據信息還是返回的確認信息，用以表明對報文的處理方式，由一個字節構成：
s：表示需要復制的原始數據信息(Source)。
R：表示返回確認信息(Resu]t)，指數據接收方對成功處理的數據返回數據發送方的確認信息。
數據集中系統在通信環節中采用了消息中間件，在進行數據復制的過程中，大致需要經過以下環節：數據提取一數據打包一調用中間件通訊函數發送消息一數據接收方中間件接收到消息一后臺守護進程從中間件消息隊列中檢索到消息一數據解包一保存數據一返回確認信息一發送方接收并處理確認信息。在上述環節中任一環節出現錯誤就會導致復制的失敗，其最終表現為對數據的復制沒有得到確認，必須x,l-相應的數據進行重新復制。因此，在數據接收方處理數據后，對處理不成功的數據就沒有必要返回確認信息，因為數據的復制沒有收到確認信息，必然會重新復制。
(3)操作類型：指明對報文進行操作的類型，由1個字節構成。yj,-為以下幾種類型：I：表示插入操作(Insert)，指新增一條新的數據信息。
U：表示更新操作(Update)，指更新原有的一條數據信息。
D：表示刪除操作(Delete)，指刪除原有的一條數據信息。
(4)報文長度：指明報文的總長度，由6個字節構成。即能標識的最大報文長度為999．999K字節。
(5)記錄數：指明報文中的總記錄數，由2個字節構成。
增加該部分內容主要是為了便于系統解包模塊的處理：可以根據該信息很容易地從報文中分離出各條單項記錄數據。每個報文最多能包含99條記錄。如果報文包含BINARY、IMAGE和TEXT數據類型，由于這種數據信息量一般較大，所以每個報文只包含一條記錄。雖然可以不包含這部分內容，但為了報文格式的統一，仍予以保留，只是其內容恒為“01”。
(6)報文數據：包含報文中的有效數據。具有以下特點：
(1)報文數據按字節順序存儲。
(2)每條記錄前包含6個字節，用來表示該記錄的實際長度。因此，每條記錄的最大長度為999．999K字節。
對BINARY、IMAGE和TEXT等BLOB數據類型而言，不能也不必用4個字節來表示其長度，但為了報文格式的統一，仍予以保留，只是其內容恒為“0000”。如果解包程序檢測到記錄數為1且記錄長度為“0000”，即可知該記錄包含BLOB數據類型。
2.2 數據復制方法
為了實現數據的高效、安全、完整的復制，根據業務類型的特點，采用以下方式：
(1)針對每個需要復制的數據表建立一個任務分發表；
(2)用觸發器適時生成分發任務；
(3)用守護進程定時或定點對分發表中的分發任務進行分發。
2.2.1 任務分發表
由于絕大多數數據都需進行多路分發，即需要分發到多個網絡節點，而且對各節點的分發不可能一次性地分發成功，很可能只是部分分發成功，因此必須跟蹤每條信息對每個節點的分發狀態。同時為了減少對原數據表的操作量(大部分業務數據表的數據量較大，如果經常對原數據表進行掃描，將嚴重影響數據庫的性能)，針對每個需要進行多路分發的數據表建立一個任務分發表，在任務分發表中存放原數據表的全部字段信息，并增加一個機構節點標識字段，表示需要對哪些目標單位進行分發。任務表中應包含需要分發的節點信息和數據信息。數據集中系統直接從任務分發表中按節點標識分組提取分發信息并進行打包發送。為了統一操作，對任務分發表采用統一的命名規范，即任務分發表的表名統一由原數據表的表名加上后綴“-RW”構成。
2.2.2 分發任務的形成和任務分發
任務分發表中存放著所有需要進行分發的數據信息，因此，如何正確形成分發任務是整個復制過程中非常重要的一個環節。在設計中采用的方法是通過觸發器來產生分發任務的，它建立在插入操作(Insert)和更新操作(Update)基礎之上。
觸發器通過以下步驟確定需要對哪些節點產生分發并生成分發任務表：
(1)獲取本地數據庫服務器通訊中間件節點名稱；
(2)通過本地節點名稱獲取上下級節點名稱。如果本地機構代碼等于上級機構代碼，則說明該節點為頂級節點，觸發器將不對上級節點產生分發信息。
(3)觸發器根據所操作的數據需要復制的范圍(全網、向上、向下、定點復制)生成相應的記錄到任務分發表。
2.2.3 數據復制流程
數據復制流程包括數據分發處理流程和數據接收處理流程，流程圖如下：
(1)數據分發處理流程圖
數據復制前應首先設定固定的開始時間和輪循次數，開始時間一般設在零點，從而減輕數據復制對業務系統的影響。達到設定的開始H,1間后，系統開始檢索分發任務表，如果分發任務表存在需要分發的數據并且尚未達到設定的輪循次數的上限，系統則按分發目的地址檢索出分發信息并按報文格式進行打包分發。如果沒有分發任務或超過輪循次數的上限則結束數據分發流程等待下次開始時間。
(2)數據接收處理流程圖
數據接收端程序為一后臺守護進程，當守護進程檢測到通訊中間件發過來的數據報文時，首先提取報文頭并根據報文頭確定報文類型、報文長度等信息，從而調用相應的報文處理模塊。如果消息類型是接收端數據更新成功后發過來的確認信息，則刪除分發任務表中已經發送成功的數據并等待新的數據報文。如果消息類型是需要復制的原始數據，則調用數據更新模塊將數據報文中的數據逐條更新到相應的數據庫表，如果更新成功則生成確認信息并將確認信息打包成數據報文發送回數據發送端，出現異常更新不成功則放棄該報文，數據發送端在沒有收到確認消息的情況下會重新發送數據，直到成功。
圖3 數據分發處理流程圖
圖4 數據接收處理流程圖
3 結束語
分布式集團企業ERP數據集中系統可實現集團公司總部與下屬公司的ERP軟件數據復制，以保持它們之間數據的一致性和完整性；另外，針對海量數據查詢業務，系統還提供一定的預處理功能，以提高查詢效率。在分布式系統的基礎上實現數據集中可較好的解決分布和集中的矛盾，使集團企業ERP在保持較高可靠性和高運行效率的基礎上實現數據集中、應用集中、管理集中，更好的發揮ERP作為企業管理信息平臺的作用。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
相關文章
