BPM是SOA架構的核心組件之一,這意味著集成能力是BPM系統的必須能力,一個沒有集成能力的流程管理系統永遠無法成為BPM。
很多人都認為,做系統集成就是做接口,其實,遠遠沒有那么簡單。那么,怎樣是正確的思路呢?要回答這個問題我們先討論下集成的目標
- 實現業務自動化;
- 降低IT架構的總擁有成本;
- 同時,系統與系統之間是松耦合的,可以任意替換其中的組件。
基于這些目標,我們來對比下兩種方式的優劣勢:
集成模式
現在市場上的流程管理產品的集成能力參差不齊,主要有以下幾種系統集成的方式:
從實際的應用來看,我們看到絕大部分流程管理產品采用【系統集成節點】這種集成模式。這種模式只能用于做DEMO,一旦上生產環境就會發現是完全不可用的。我們看到,很多客戶采用了這種系統之后,不得不再自行開發一個集成程序,專門用于流程引擎與第三方系統的交互,來保障集成的高可用。通常,內置ESB的BPM系統默認能跟第三方ESB集成。
所以,客戶如果需要選擇一款具備集成能力的流程管理產品,那么必須選擇一款內置ESB的BPM。從實際來看,除了Lombardi和Oracle BPM以外,國內一流的流程管理產品的集成能力,大大領先于國外的其他流程管理產品。
運行環境
集成系統的運行環境至關重要,如果集成組件本身的運行環境都不是高可用的,那么一切都無從談起。常見的流程引擎運行環境有:
- 流程引擎HOST在其他系統的進程里,比如:IIS,SharePoint等。
- 流程引擎HOST在自己的Service里。
我們看到很多中國的二流的流程產品,采用的是HOST在其他進程里的模式,這對于系統集成來說是一個災難。絕大部分國外的產品和中國的一流的流程管理產品,都采用的是HOST在自己的Service里面。
前端集成
前面介紹了集成的各種方式,對于最終用戶來說,他們關注的還是如何展現,比如是否方便與門戶系統集成,統一組織架構,單點登錄。通常,主流的流程管理產品在這方面都不存在問題。
開發模式
我們看到有一些流程管理產品,做一個與SAP集成的流程需要寫一段代碼,下一次再做一個與SAP集成的流程又要寫一段代碼,這兩段代碼80%是一樣的,如果每做一個系統集成的流程都要寫一段代碼,那么開發人員的工作量將非常大。
安全性
這個是一個重要的指標。安全性包括很多方面,比如:密碼安全、數據安全、接口安全、帳戶管理等。通常,前面那些都可以通過基礎設施,比如:硬件、操作系統等實現,ESB則需要自行實現帳戶管理,帳戶管理里面有一項重要的功能就是帳戶映射。
帳戶映射管理是指ESB需要記錄每個用戶與業務系統用戶的對應關系,這個映射可能是M:N的關系。比如:一個上海的員工,在發起一個采購訂單審批的時候,他只能選擇上海公司代碼下的物料號,而不能選擇北京公司代碼下的物料。這意味著,用戶在BPM上的賬號要映射到ERP的賬戶上。
BPM里的ESB的其他基礎功能
集群、日志、數據處理(數據映射、數據轉換、XPat支持、內聯函數和處理腳本支持等)、事務管理、BPEL、適配器、自定義擴展、權限管理、帳戶管理、配置傳輸管理、性能監控、會話管理、監聽服務、后臺作業管理、字段狀態管理、表單支持等。
增值服務
對于具備ESB能力的流程系統,很多廠商在其中研發了大量的增值模塊,比如:SAP Connector、Master Data Management、SWIFT等。
這并不是簡單的接口調用,而是一個完整的解決方案,比如:跟SAP集成,并不是簡單的支持BAPI和RFC即可;跟SAP集成,其實是跟SAP環境集成,通常,SAP還會有大量的外掛程序,要實現跟SAP的集成,不但要實現跟SAP集成,還要實現跟SAP外掛程序的集成。
又比如實現主數據大集中,這并不只是技術問題,還需要大量的行業經驗才能實現,很顯然,金融行業的集中管理的客戶主數據跟制造行業的客戶主數據是完全不一樣的。實施人員需要清楚地知道在某個行業里要把哪些系統的哪些數據進行集中,又分別采用哪種集中模式等等。
總結
系統集成絕不是調接口,高可用是必須的,否則一切都無從談起。雖然市場上有很多產品具備一定的集成能力,但是絕大多數只是淺度的集成,根本無法在生產環境中使用。如果客戶對流程自動化有要求,那么只能選擇具有ESB模塊的流程產品。而且這種ESB要能支持復雜的數據結構,比如:訂單、XML類型等。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:CIO:系統集成怎么做?接口還是ESB
本文網址:http://www.guhuozai8.cn/html/consultation/1082055701.html