SAP XI技術(shù)在ERP與MES集成中的應用
在邯鋼SAP R3與MES集成項目中,根據各個(gè)業(yè)務(wù)模塊的需求,確定通過(guò)xI接口交換的數據信息主要包括以下幾類(lèi)。
(1)從四級R3下傳到MES的數據,包括物料主數據、客戶(hù)主數據、撿配清單、生產(chǎn)訂單等。
(2)從MES上傳到R3的數據,包括質(zhì)檢判定、生產(chǎn)收貨、物料移動(dòng)類(lèi)型記賬等。
(3)三級之間傳輸的數據,包括工廠(chǎng)到工廠(chǎng)采購訂單,三級之間的物料轉儲單等。
針對邯鋼的業(yè)務(wù)流程及xI技術(shù)特點(diǎn),該項目的實(shí)施流程包括以下幾個(gè)步驟。
(1)業(yè)務(wù)情景分析。描述要實(shí)施的業(yè)務(wù)情景及該業(yè)務(wù)涉及到的后端系統,確定接口策略(新建接口或改造原有接口),設計業(yè)務(wù)的技術(shù)架構、功能架構以及xI架構,并在SLD(System LandscapeDirectory)中創(chuàng )建系統實(shí)體模型。
針對邯鋼ERP與MES集成項目中各個(gè)業(yè)務(wù)模塊的需求,其業(yè)務(wù)情景可描述為:1)在SAP系統內創(chuàng )建銷(xiāo)售訂單;2)進(jìn)行可用性檢查;3)生成計劃訂單;4)轉換為生產(chǎn)訂單;5)在MES中創(chuàng )建相應數據;6)生產(chǎn)完成后創(chuàng )建相應的收貨單。以上情景的數據傳輸都在xI數據平臺上實(shí)現,由100多個(gè)接口管理數據的接收。
(2)接口分析。確定接口的以下特性及參數:接口的實(shí)時(shí)性(同步或異步),接口是否需要技術(shù)的或者應用層次回應方式的確認(閉環(huán)與否),每個(gè)接口的導入和導出消息類(lèi)型,每個(gè)消息類(lèi)型的數據結構,文本文件的格式,數據庫的結構,IDoc(Intermediate Document),RFC(Request for Comments),BAPI(Business Application Programming Interface)的結構以及XML的數據結構,為每個(gè)消息類(lèi)型提供數據樣本,并在集成知識庫里創(chuàng )建消息對象實(shí)體。
以生產(chǎn)訂單管理流程為例,其接口如圖2所示。
(3)映射定義?;诮涌诜治龅慕Y果確定接口的映射規則,選擇實(shí)現映射的技術(shù)(圖像工具、JAVA、XSLT)并根據定義的樣本規則實(shí)施映射。
(4)環(huán)境準備。包括測試環(huán)境定義和測試環(huán)境準備。測試環(huán)境定義,包括代理服務(wù)器的配置和網(wǎng)絡(luò )硬件設備連接性的定義;測試環(huán)境準備,包括完成系統的安裝并在安裝后檢查xI服務(wù),創(chuàng )建用戶(hù),分配用戶(hù)權限等;如果是為上線(xiàn)做準備,還必須定義上線(xiàn)切換策略,并將切換策略按照開(kāi)發(fā)機一測試機一生產(chǎn)機的順序執行上傳。

(5)系統配置。配置后端系統,保證系統能夠產(chǎn)生和接收與樣本數據一樣的數據,根據步驟(1)~ (4)的結果在集成目錄中配置xI對象和xI集成目錄。
(6)系統測試。用不同的數據集進(jìn)行點(diǎn)到點(diǎn)的業(yè)務(wù)情景測試和上線(xiàn)切換測試。
完成上述步驟并收集各種數據后,進(jìn)行系統環(huán)境配置并完成以下工作:設定集成情景、建立消息類(lèi)型、確定業(yè)務(wù)系統、確定邏輯路由規則、確定技術(shù)路由規則、進(jìn)行ABAP Proxy的調用以及JavaServer Proxy的使用。
3 關(guān)鍵問(wèn)題及解決方案
xI作為新興技術(shù)在國內的應用還是首次,它的成功運行很好地支持了邯鋼ERP項目的進(jìn)行,對國內信息化建設中的數據集成、數據通信有很大的借鑒和推動(dòng)作用。以下將對系統在實(shí)施過(guò)程中遇到的多系統通信和數據擁堵問(wèn)題及其解決方案進(jìn)行描述。
3.1 多系統通信問(wèn)題
邯鄲鋼鐵集團信息化項目中包括多個(gè)三級系統,其中三級的通信通過(guò)DB To DB和Web Servers(如Tomcat)兩種方式實(shí)現。如何將xI的通信方式與其他的Web Server集成,是系統實(shí)施中要解決的一個(gè)重要問(wèn)題。
由于xI本身具有Web Application Server機制,因此在與其他Web Server通信的方式上采用目前通用的SOAP協(xié)議,即由Tomcat組織XML數據通過(guò)SOAP協(xié)議組織數據到xI,具體實(shí)施過(guò)程如下:
建立XML Schema,連接X(jué)ML文檔事例到XML Schema,SOAP把XML的使用代碼轉化為請求和響應參數編碼模式,并采用HTYP傳輸[3]。一個(gè)SOAP方法可以簡(jiǎn)單地看作遵循SOAP編碼規則的HTYP請求和響應。一個(gè)SOAP終端則可以看作一個(gè)基于HTYP的URL,用來(lái)識別方法調用的目標。和Corba/IIOP一樣,SOAP不需要具體的對象被綁定到一個(gè)給定的終端,而是由具體實(shí)現程序來(lái)決定如何把對象終端標識符映射到服務(wù)器端的對象。SOAP請求是一個(gè)HTYP POST請求,它的類(lèi)型必須為text/xml,且必須包含一個(gè)請求.URI。服務(wù)器解釋這個(gè)請求.URI的方式與該請求的實(shí)現方法相關(guān)。
3.2 數據擁堵問(wèn)題
由于xI與三級系統的連接是一對多的關(guān)系,由xI系統對應多個(gè)系統,而數據下傳采用排隊機制,因此在數據沒(méi)有設定優(yōu)先級的情況下,下傳的順序為先人先出。當下傳通信失敗時(shí),xI會(huì )自動(dòng)重新調度通信,直到調度達到一定次數(可配置),才認定該通信失敗,調度下一接口,該數據保存在數據庫中準備手動(dòng)調度。在正常情況下,xI的隊列可并發(fā)處理多條數據,但一旦下傳數據的任一接收方出現異常,如發(fā)生網(wǎng)絡(luò )中斷、數據庫死鎖等情況,由單點(diǎn)故障重復調度數據就會(huì )造成數據隊列過(guò)長(cháng),系統開(kāi)銷(xiāo)大規模增加,進(jìn)而出現單點(diǎn)故障引起數據擁堵的狀況。
針對單點(diǎn)故障引起的數據擁堵問(wèn)題,項目在實(shí)施過(guò)程中將XI的數據分發(fā)機制與現有設備想結合,建立分布式體系結構,將易發(fā)生數據異常的接口配置到分流機,如圖3所示。
由于項目中分流系統選用惠普的小型機HP4640,操作系統為HP-ux,數據為為Oracle,而OS/400的數據為為DB2,兩種系統的JVM機制有很大的區別。因此,分流系統的數據主要保存在Oracle中,數據調度時(shí)直接從Orale中調度,而不從DB2中調度,當某個(gè)接收點(diǎn)出現問(wèn)題時(shí)可以把有問(wèn)題的數據拋給Oracle,等該接收點(diǎn)恢復正常時(shí)再手工觸發(fā)數據下傳,這種方式將不會(huì )影響其他隊列數據正常下傳。
3.3 實(shí)施效果
邯鄲鋼鐵集團信息化項目的數據通信不但設計復雜,而且數據流量大、業(yè)務(wù)高峰數據壓力大,這些都給硬件以及軟件帶來(lái)很大的考驗。XI技術(shù)的有效實(shí)施,保證了數據的有效傳輸對異常事件的響應速度也得到了顯著(zhù)提高。目前數據業(yè)務(wù)量平均保持在同步數據每天10000-15000條,異步數據8000-12000條左右。當前的系統配置在滿(mǎn)足業(yè)務(wù)需要的甚而上優(yōu)化了系統性能,實(shí)現了業(yè)務(wù)系統的集成與優(yōu)化。
評論