莊辰弘

0 引言

隨著SAP R/3 (system application and products in data processing這款主流的ERP企業(yè)管理軟件平臺)成為國內(nèi)越來越多大企業(yè) ERP應用的首選，很多企業(yè)都面臨著同樣一個問題，即如何讓新的 ERP平臺和一些老的，或是新增加的子系統(tǒng)/子平臺默契配合。在保證既有功能的前提下，提高系統(tǒng)和系統(tǒng)間信息傳遞的效率，從而保證和提高企業(yè)的生產(chǎn)競爭力。在這樣的背景之下，ERP系統(tǒng)接口的應用、開發(fā)、甚至規(guī)范，會起到積極的作用。好的接口會使得系統(tǒng)之間能真正做到“無縫”連接，有效的整合各系統(tǒng)間的數(shù)據(jù)，以達到資源共享和協(xié)同工作的目的。本文的目的在于通過對 SAP接口技術的介紹和實例的驗證，普及和推廣以規(guī)范這一接口技術為核心的一體化信息集成架構。

1 SAP接口技術

SAP組建數(shù)量龐大，各系統(tǒng)（ECC，BW和Portal）之間需要即時通信。對于用戶來說，最佳的感受就是在同一系統(tǒng)中進行。為此，SAP從誕生之日開始，就提供了眾多的API應用編程接口和接口工具，以方便SAP二次開發(fā)和愛好者進行研究。RFC，ALE/IDocs是SAP公司早期為SAP R/3 R4.6C版本所提供的接口機制，目前應用最為廣泛。在R4.0以后的版本中，又添加了技術上先進的BAPI，DCOM以及Web Service技術。下面對這些接口方式以及其它可用的整合方式進行介紹。

1.1 SAP RFC技術

RFC（Remote Function Call，遠程功能調用）是 SAP系統(tǒng)和其他（SAP或非 SAP）系統(tǒng)間的一個重要而常用的雙向接口技術，也被視為SAP與外部通信的基本協(xié)議。其他更高級的SAP接口和通信技術，如后續(xù)的BAPI和ALE等都是基于RFC實現(xiàn)的。簡單地說，RFC過程就是系統(tǒng)調用當前系統(tǒng)外的程序模塊，從而實現(xiàn)某個功能，而且調用系統(tǒng)和被調用系統(tǒng)中，至少有一個必須是SAP ABAP系統(tǒng)。這種遠程功能調用，也可在同一系統(tǒng)內(nèi)部進行（如本地SAP系統(tǒng)內(nèi)的遠程調用）；但通常情況下，調用程序和被調用程序處于不同系統(tǒng)。SAP系統(tǒng)RFC應用的原理很簡單，有一些類似于三層構架的C/S系統(tǒng)，第三方的客戶程序通過接口調用 SAP內(nèi)部的標準或自定義函數(shù)，獲得函數(shù)返回的數(shù)據(jù)進行處理后顯示或打印。 根據(jù)通信方向和通信類型，共有

3種RFC通信：

1) 兩個獨立的SAP系統(tǒng)之間；

2) SAP系統(tǒng)作為調用系統(tǒng)，與外部遠程系統(tǒng)（非 SAP ABAP系統(tǒng)）通信；

3) 外部系統(tǒng)作為調用系統(tǒng)，與SAP系統(tǒng)通信。

優(yōu)點：SAP的RFC調用是其接口技術中最簡單和易用的一種方式，該方式開發(fā)比較簡便，特別適合于外部報表開發(fā)。 缺點：但對于大數(shù)據(jù)量的查詢效率相對較低。如果有大數(shù)據(jù)量開發(fā)需要很多使用IDOC和BAPI接口開發(fā)技術，RFC接口方案開發(fā)量小，實施簡單，很快就能滿足客戶需求，如在外部系統(tǒng)打印報表,或外部系統(tǒng)獲取SAP簡單的數(shù)據(jù)信息進行加工處理等。但這種方案只能滿足客戶簡單的需求。

1.2 ALE/IDOC技術

ALE 是Application Link and Enabling的縮寫，是SAP專門為SAP與SAP之間所設計的整合中間件。IDocs是中介文本 (Intermediate DOCument) 的縮寫，是SAP提供的系統(tǒng)整合專用的數(shù)據(jù)/消息格式，可用于EDI、ALE或導出導入(XML，ASCII)文件等。當然也可ALE在SAP 3.0版本開始就作為SAP整個應用體系的一部分，為分布式數(shù)據(jù)交換提供了可靠安全的通訊機制。ALE的設計，原本作為兩個SAP流程之間的一種消息傳遞服務(Messaging Service) ，使SAP與SAP的業(yè)務流程之間企業(yè)數(shù)據(jù)能夠有效的交換，為兩個獨立的 SAP之間提供了的系統(tǒng)整合服務。不過，隨著應用的發(fā)展，ALE/IDocs接口機制也已成為與其它非 SAP系統(tǒng)的標準的整合方式。ALE的設計結構可以分為3層，即應用層、數(shù)據(jù)/消息分配層和通訊層。通訊層是SAP整合機制的基礎，它利用遠程功能呼叫 RFC(Remote Function Call) 調用SAP系統(tǒng)的功能模塊。

數(shù)據(jù)/消息分配層，主要提供 3個關鍵服務：按數(shù)據(jù)分配模型決定數(shù)據(jù)接收者、消息的過濾和轉換、數(shù)據(jù)/消息的壓縮，以提高傳遞效率。應用層直接與SAP系統(tǒng)接口，生成或從其它系統(tǒng)接收含有路由信息的消息文本IDocs，包括消息接收者的姓名、要求發(fā)送的類型以及對消息進行處理的規(guī)則。ALE設計結構，如圖1所示：

圖1 ALE設計結構

ALE的機制代替了原來的 SAP所提供的批數(shù)據(jù)通訊BDC(Batch Data Communication) 方式。顧名思義，BDC為系統(tǒng)之間提供了簡單的數(shù)據(jù)批處理服務，還不能作為一種中間件技術，它沒有提供系統(tǒng)之間進行無縫整合所要求的糾錯功能、系統(tǒng)管理和其它安全措施?？偟恼f來，應用SAP的ALE機制進行SAP與SAP或非SAP系統(tǒng)整合有以下幾個好處：ALE技術不受SAP版本升級的影響，它提供了版本向后兼容性。ALE定義于SAP應用層，與SAP的邏輯層相對獨立，整個ALE中間件獨立于發(fā)送和接收系統(tǒng)。ALE消息設計邏輯保證消息的“一次且只有一次”的消息傳遞。ALE采用“存儲-發(fā)送”技術確保消息即使系統(tǒng)發(fā)生故障或接收方?jīng)]有準備接收時，也可以達到目的地。這樣就保證接收方不至于收到重復消息。ALE也提供了IDocs管理功能。主要有文本縮減、文本版本控制以及文本數(shù)據(jù)過濾。3種控制機制使得SAP開發(fā)人員可以根據(jù)實際需要，對IDocs文本在運行中進行動態(tài)處理。ALE提供了系統(tǒng)管理功能，允許對ALE系統(tǒng)進行啟動/復位/恢復等系統(tǒng)操作，為開發(fā)人員提供了進一步的管理控制。IDoc 幾乎可以傳帶任何SAP應用的數(shù)據(jù)，是一種“外圍”定義格式，與 SAP的應用數(shù)據(jù)定義不直接相關。IDocs已經(jīng)廣泛應用于早期的SAP-EDI的數(shù)據(jù)交換，因而它的設計有點類似于 EDI的標準，即 EDIFACT標準。IDocs是以字符基礎的，因而是可讀的。它有3種紀錄類型，即：

1) 控制紀錄-含文本信息，如IDoc類型，發(fā)送/接收方信息以及文本標識。

2) 數(shù)據(jù)紀錄-含管理和實際數(shù)據(jù)部分。

3) 狀態(tài)紀錄-用來追蹤文本傳遞各點的狀態(tài)，如狀態(tài)碼、系統(tǒng)時間、錯誤標識等。

1.3 BAPI技術

BAPI是Business Application Programming Interface的縮寫， 是SAP為3.0版本以上提供的基于企業(yè)目標(Business Object) 技術的接口應用界面。SAP在3.0版本以上采用了Object-oriented技術，邏輯定義了SAP R/3系統(tǒng)的所有功能目標，并且將所有的目標(Objects) 和BAPIs存儲于企業(yè)目標庫BOR(Business Objects Repository)。 SAP R/3 企業(yè)目標的目標類型(Object Type) 相當于目標設計語言中類(Class)的概念。利用BAPI，開發(fā)人員可以實現(xiàn)對BOR進行實時訪問，從而實現(xiàn)應用系統(tǒng)(SAP-SAP)之間在數(shù)據(jù)/邏輯層上的有效整合。SAP R/3的企業(yè)目標庫BOR(Business Objects Repository)中封裝了 R/3的功能對象。通過 BAPI（Business Application Programming Interface）可以訪問 BOR。BAPI是 R/3平臺專用的開發(fā)接口，但是從系統(tǒng)整合的角度看，BAPI主要是支持SAP應用-SAP應用之間的整合，SAP應用-非 SAP應用之間的整合需要其他的技術，其中 R/3 DCOM接口應用比較廣泛。

1.4 SAP-DCOM

SAP于1998首次提供SAP-DCOM接口，以滿足各種桌面應用開發(fā)的要求。利用DCOM連接端口，開發(fā)人員可以利用VB， C++，以DCOM目標方式訪問SAP數(shù)據(jù)。在Web應用上，可以用VBScript， JavaScript 以DHTML方式頁面訪問，也可以用ASP訪問數(shù)據(jù)。另外，利用DCOM也可以間接訪問SAP的企業(yè)目標庫BOR。上面提到的BAPI是SAP系統(tǒng)上專用的，在實際應用上不如DCOM來得廣泛。DCOM 端口主要有兩個技術模塊組成，一個是管理模塊，另一個模塊生成SAP BO的DCOM 代理組件(Proxy Components)，生成的DCOM組件存放于C++。

R/3的DCOM接口主要用于Windows平臺的應用程序訪問R/3。R3 DCOM可以除了可以訪問BAPI外，還可以遠程調用R/3上的ABAP程序（需要DCOM Connector 4.6D以后的版本支持）。R/3 DCOM更適合于小型的R/3外掛程序，或者與基于 Windows的小型應用集成。對于大型 R/3 EAI，必然要考慮中間件產(chǎn)品了。

1.5 Web Service接口技術

Web Service是獨立的，模塊化的，自描述的應用功能模塊或服務。它基于XML標準格式，通過使用標準的因特網(wǎng)協(xié)議，這些應用功能模塊可以被描述、查找、使用或調用。因此每一個 Web Service都封裝了一序列可以使用的功能集。例如，供應商的價格查詢、核查庫存系統(tǒng)的特定的物料、查找特定的電話號碼、或者核對信用卡、轉帳、付款等。從表面上看，web Service就是一個應用程序，它向外界暴露出一個能夠通過 Web調用的 API。從深層次上看，Web Service是一種新的Web應用程序分支，它是自包含、自描述、模塊化的應用，可以在網(wǎng)絡中被描述、發(fā)布、查找以及通過網(wǎng)絡來調用。Web Service是一種基于Web的中間件技術。用戶通過把應用程序的一部分包裝成Web服務的形式，將自己的應用程序功能提供給別人，實現(xiàn)應用程序之間的接口。

2 基于SAP接口技術的中間件：E2E Bridge 平臺

2.1 E2E Bridge平臺的簡介

E2E Bridge是一種系統(tǒng)集成解決方案。它的設計是基于國際對象管理集團（OMG）模型驅動架構（MDA）原理。目前大多數(shù)的公司都面臨著系統(tǒng)集成的困擾，其中有的是為了滿足業(yè)務或流程上的需求，有的則是為了更好地服務于分布式系統(tǒng)。E2E Bridge提供了一種方案，它是利用面向服務的概念進行集成需求建模。之后就能夠便捷地直接執(zhí)行這個模型了。這種 end to end的建模過程是在UML（統(tǒng)一建模語言）下完成的，它由use case（使用個案）、data structure（數(shù)據(jù)結構）、processes（流程）、business logic（業(yè)務邏輯）和 architecture deployment configuration（架構分布配置）構建而成。理論上，我們可以使用任何一種支持標準建模交換格式 XMI（XML Metadata Interchange）的UML編輯器。XMI文件包含了所有構建服務所需的信息。這些內(nèi)容之后將被部署和執(zhí)行在E2E運行環(huán)境——E2E服務器中。說明和介紹UML中的某個服務，可以提供一個合理的內(nèi)部運作的高層文檔以及后臺運作的情況的描述。因為，UML可以直接映射出所有服務包含的數(shù)據(jù)流（data flow）、事件處理器（event handler）和操作（operations），所以，你的文檔必須做到實時更新。

2.2 E2E Bridge結構

除了構建服務操作的模型，E2E實施的模型驅動集成方法還強調構建服務架構。這是通過定義結構化的服務組件和明確它們的在UML模型中部署配置來完成的。關鍵這能保證SOA（Statement of Applicability適用性聲明）和EDA（Electronic Design Automation電子設計自動化）的維護性和管理性。圖中展示了E2E Bridge平臺的高層架構，如圖2所示：

圖2 E2E Bridge平臺的高層架構

它包含了 E2E服務器運行環(huán)境和插件。插件指的是可被運行環(huán)境加載和管理的任何組件。有兩種重要的插件類型即前臺服務和后臺適配器。前臺服務可以和應用不同協(xié)議，諸如：SOAP，SAP RFC或者HTTP(s)的客戶端通信。后臺適配器可以幫助接入不同類型的數(shù)據(jù)庫、遺留系統(tǒng)，當然還有網(wǎng)絡服務。運行環(huán)境也同時支持一些基礎的功能，比如過程控制流，處理事件和執(zhí)行行動腳本。

3 SAP接口技術在移動終端的應用分析

3.1 需求分析

項目對象是一家從事餐飲設備現(xiàn)場維修的售后服務部門。部門業(yè)務已經(jīng)在SAP上運行，但在項目實施前，仍有一系列的問題困擾著管理團隊和服務工程師。

1) 由于售后維修地點分布在全國各地，所以對管理層很難做到對服務工程師的現(xiàn)場服務，以及對分配在服務工程師手中的零部件庫存，進行實時有效的管理。

2) 由于服務區(qū)域地域跨度大，幅員遼闊。所以通常工程師手中完成的工單需要花費 3周以上的時間，才能傳回本部SAP系統(tǒng)內(nèi)。

3.2 系統(tǒng)設計目標

IT設計人員認為，可以通過移動終端的解決方案來保證SAP與移動終端的實時交互。這樣就可以有效提高管理效率，優(yōu)化服務流程以及提高庫存準確度。通過項目的實施，可以同時幫助現(xiàn)場服務工程師以及他們的管理團隊：

1) 對于工程師而言：

a) 可以在手持移動終端PDA上實現(xiàn)日程管理

b) 可以在手持移動終端 PDA上查詢實時的客戶信息，零備件庫存數(shù)量以及維修設備主數(shù)據(jù)。

c) 可以在手持移動終端 PDA上看到實時分配的維修請求，服務工單以及歷史維修記錄。

d) 可以在手持移動終端PDA上創(chuàng)建服務工單，報價單并實時上傳。

2) 對于管理層而言：

a) 可以監(jiān)督管理服務工程師的維修日程安排和服務工單狀態(tài)。

b) 可以在SAP中得到精確的庫存管理信息。

c) 可以得到實時的工程師KPI（Key Performance Indicator）報表。

3.3 與SAP整合的系統(tǒng)架構

移動終端的開發(fā)是在 EchoPlus平臺上進行并完成的。通過E2E Bridge這個接口中間件，有效地整合了應用的前臺通信和后臺數(shù)據(jù)庫。手持移動設備PDA通過無線的GPRS或者3G技術，可以做到和EchoPlus平臺的實時同步，并最終將數(shù)據(jù)實現(xiàn)與SAP的交互，系統(tǒng)架構，如圖3所示：

圖3 移動終端與SAP整合后的架構

4 總結

接口技術是系統(tǒng)整合技術中的難點。尤其對于 SAP這樣龐大的集成性軟件來講，由于內(nèi)在的復雜性和軟件公司的商業(yè)保護目的。很少能找到公開的詳細技術資料，即使有，也一般掌握在幾家大的工業(yè)軟件商手中。再加上本人的學術水平和實際經(jīng)驗的限制，所以本文僅僅提供和論述了一些SAP主流的接口技術和一款由此基礎上開發(fā)的接口中間件和成功實施的商業(yè)案例。借此機會與大家共享，希望今后在此基礎上能有進一步的研究和提高。

[1]Teresa Jones,[M]E2E Technologies, 2006

[2]黃佳，《SAP程序設計》，[M]北京，人民郵電出版社，2008

[3]斯普頓，《SAP交換架構》，[M]上海，東方出版社，2005

[4]Michael Wegelin and Michael Englbrecht,[M]SAP Interface Programming, SAP Press