基于SAP 接口技術的移動終端解決方案

莊辰弘

0 引言

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

1 SAP接口技術

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

1.1 SAP RFC技術

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

3種RFC通信：

1) 兩個獨立的SAP系統之間；

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

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

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

1.2 ALE/IDOC技術

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

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

圖1 ALE設計結構

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

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

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

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

1.3 BAPI技術

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

1.4 SAP-DCOM

SAP于1998首次提供SAP-DCOM接口，以滿足各種桌面應用開發的要求。利用DCOM連接端口，開發人員可以利用VB， C++，以DCOM目標方式訪問SAP數據。在Web應用上，可以用VBScript， JavaScript 以DHTML方式頁面訪問，也可以用ASP訪問數據。另外，利用DCOM也可以間接訪問SAP的企業目標庫BOR。上面提到的BAPI是SAP系統上專用的，在實際應用上不如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，必然要考慮中間件產品了。

1.5 Web Service接口技術

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

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

2.1 E2E Bridge平臺的簡介

E2E Bridge是一種系統集成解決方案。它的設計是基于國際對象管理集團（OMG）模型驅動架構（MDA）原理。目前大多數的公司都面臨著系統集成的困擾，其中有的是為了滿足業務或流程上的需求，有的則是為了更好地服務于分布式系統。E2E Bridge提供了一種方案，它是利用面向服務的概念進行集成需求建模。之后就能夠便捷地直接執行這個模型了。這種 end to end的建模過程是在UML（統一建模語言）下完成的，它由use case（使用個案）、data structure（數據結構）、processes（流程）、business logic（業務邏輯）和 architecture deployment configuration（架構分布配置）構建而成。理論上，我們可以使用任何一種支持標準建模交換格式 XMI（XML Metadata Interchange）的UML編輯器。XMI文件包含了所有構建服務所需的信息。這些內容之后將被部署和執行在E2E運行環境——E2E服務器中。說明和介紹UML中的某個服務，可以提供一個合理的內部運作的高層文檔以及后臺運作的情況的描述。因為，UML可以直接映射出所有服務包含的數據流（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服務器運行環境和插件。插件指的是可被運行環境加載和管理的任何組件。有兩種重要的插件類型即前臺服務和后臺適配器。前臺服務可以和應用不同協議，諸如：SOAP，SAP RFC或者HTTP(s)的客戶端通信。后臺適配器可以幫助接入不同類型的數據庫、遺留系統，當然還有網絡服務。運行環境也同時支持一些基礎的功能，比如過程控制流，處理事件和執行行動腳本。

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

3.1 需求分析

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

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

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

3.2 系統設計目標

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

1) 對于工程師而言：

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

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

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

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

2) 對于管理層而言：

a) 可以監督管理服務工程師的維修日程安排和服務工單狀態。

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

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

3.3 與SAP整合的系統架構

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

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

4 總結

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

[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