基于SAP 接口技術(shù)的移動(dòng)終端解決方案

莊辰弘

0 引言

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

1 SAP接口技術(shù)

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

1.1 SAP RFC技術(shù)

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

3種RFC通信：

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

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

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

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

1.2 ALE/IDOC技術(shù)

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

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

圖1 ALE設(shè)計(jì)結(jié)構(gòu)

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

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

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

3) 狀態(tài)紀(jì)錄-用來追蹤文本傳遞各點(diǎn)的狀態(tài)，如狀態(tài)碼、系統(tǒng)時(shí)間、錯(cuò)誤標(biāo)識(shí)等。

1.3 BAPI技術(shù)

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

1.4 SAP-DCOM

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

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

1.5 Web Service接口技術(shù)

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

2 基于SAP接口技術(shù)的中間件：E2E Bridge 平臺(tái)

2.1 E2E Bridge平臺(tái)的簡(jiǎn)介

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

2.2 E2E Bridge結(jié)構(gòu)

除了構(gòu)建服務(wù)操作的模型，E2E實(shí)施的模型驅(qū)動(dòng)集成方法還強(qiáng)調(diào)構(gòu)建服務(wù)架構(gòu)。這是通過定義結(jié)構(gòu)化的服務(wù)組件和明確它們的在UML模型中部署配置來完成的。關(guān)鍵這能保證SOA（Statement of Applicability適用性聲明）和EDA（Electronic Design Automation電子設(shè)計(jì)自動(dòng)化）的維護(hù)性和管理性。圖中展示了E2E Bridge平臺(tái)的高層架構(gòu)，如圖2所示：

圖2 E2E Bridge平臺(tái)的高層架構(gòu)

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

3 SAP接口技術(shù)在移動(dòng)終端的應(yīng)用分析

3.1 需求分析

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

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

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

3.2 系統(tǒng)設(shè)計(jì)目標(biāo)

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

1) 對(duì)于工程師而言：

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

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

c) 可以在手持移動(dòng)終端 PDA上看到實(shí)時(shí)分配的維修請(qǐng)求，服務(wù)工單以及歷史維修記錄。

d) 可以在手持移動(dòng)終端PDA上創(chuàng)建服務(wù)工單，報(bào)價(jià)單并實(shí)時(shí)上傳。

2) 對(duì)于管理層而言：

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

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

c) 可以得到實(shí)時(shí)的工程師KPI（Key Performance Indicator）報(bào)表。

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

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

圖3 移動(dòng)終端與SAP整合后的架構(gòu)

4 總結(jié)

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

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

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

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

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