http://blog.csdn.net/zltpc007/archive/2007/11/02/1863094.aspx
SAP介面
作為目前ERP市場上最為領先的應用系統之一,一直以來,SAP R/3在提供API應用程式設計介面和介面工具方面也同樣領先於其它ERP廠商。ALE/IDocs是SAP公司為SAP R/3 R4.6C版本所提供的介面機制,目前應用最為廣泛。在 R4.0以後的版本中,又新增了技術上先進的BAPI。本文作為系列介紹之一,對ALE/IDocs, BAPI以及其它可用的整合方式進行介紹。
1、ALE/IDocs是什麼?
ALE 是Application Link and Enabling的縮寫,是SAP專門為SAP與SAP之間所設計的整合中介軟體。IDocs是中介文字 (Intermediate DOCument) 的縮寫,是SAP提供的系統整合專用的資料/訊息格式。ALE在SAP 3.0版本開始就作為SAP整個應用體系的一部分,為分散式資料交換提供了可靠安全的通訊機制。ALE的設計,原本作為兩個SAP流程之間的一種訊息傳遞服務(Messaging Service) ,使SAP與SAP的業務流程之間企業資料能夠有效的交換,為兩個獨立的SAP之間提供了的系統整合服務。不過,隨著應用的發展,ALE/IDocs介面機制也已然成為與其它非SAP系統的標準的整合方式。
2、ALE/IDocs的訊息傳送接收過程
ALE的設計結構可以分為三層,即應用層,資料/訊息分配層和通訊層。通訊層是SAP整合機制的基礎,它利用遠端功能呼叫RFC(Remote Function Call) 呼叫SAP系統的功能模組。
資料/訊息分配層,主要提供三個關鍵服務:按資料分配模型決定資料接收者。訊息的過濾和轉換。資料/訊息的壓縮,以提高傳遞效率。應用層直接與SAP系統介面,生成或從其它系統接收含有路由資訊的訊息文字IDocs,包括訊息接收者的姓名,要求傳送的型別以及對訊息進行處理的規則。 ALE的機制代替了原來的SAP所提供的批資料通訊BDC(Batch Data Communication) 方式。顧名思義,BDC為系統之間提供了簡單的資料批處理服務,還不能作為一種中介軟體技術,它沒有提供系統之間進行無縫整合所要求的糾錯功能、系統管理和其它安全措施。總得說來,應用SAP的ALE機制進行SAP與SAP或非SAP系統整合有以下幾個好處: ALE技術不受SAP版本升級的影響,它提供了版本向後相容性。ALE定義於SAP應用層,與SAP的邏輯層相對獨立,整個ALE中介軟體獨立於傳送和接收系統。 ALE訊息設計邏輯保證訊息的“一次且只有一次”的訊息傳遞。ALE採用“儲存-傳送”技術確保訊息即使系統發生故障或接收方沒有準備接收時也可以達到目的地。這樣就保證接收方不至於收到重複訊息。ALE也提供了IDocs管理功能。主要有文字縮減、文字版本控制以及文字資料過濾。三種控制機制使得SAP開發人員可以根據實際需要對IDocs文字在執行中進行動態處理。ALE提供了系統管理功能,允許對ALE系統進行啟動/復位/恢復等系統操作,為開發人員提供了進一步的管理控制。 IDoc 幾乎可以傳帶任何SAP應用的資料,是一種“外圍”定義格式,與SAP的應用資料定義不直接相關。IDocs已經廣泛應用於早期的SAP-EDI的資料交換,因而它的設計有點類似於EDI的標準,即EDIFACT標準。 IDocs是以字元基礎的,因而是可讀的。它有三種紀錄型別,即:控制紀錄-含文字資訊,如IDoc型別,傳送/接收方資訊以及文字標識。資料紀錄-含管理和實際資料部分。狀態紀錄-用來追蹤文字傳遞各點的狀態,如狀態碼,系統時間,錯誤標識等。
下面對ALE/IDocs在系統整合過程中訊息的實際傳遞進行介紹。
讓我們首先看傳送過程。
一個傳送過程由事件觸發,文字生成,資料打包以及交由傳輸媒介傳遞這四個步驟組成,具體如下:
應用系統事件觸發 系統目標(Objects) 的狀態變化,使用者自主活動或其它資料庫特定變化等可以啟動資料表的觸發程式,從而進行資料傳遞的初始化工作,如資料準備。
生成主IDoc文字(Master) 按標準格式生成主IDoc檔案,包含所有可以傳遞資料(不分接收者)
生成通訊Idoc 從主IDoc中生成只與特定接收者有關的文字,通訊文字是主文字的子資料集(Subset)
Idoc 傳送 利用非同步通訊方式將一定版本的IDoc傳遞到接收方。
下面,讓我們看接收過程。
接收過程始於SAP系統從外部收到IDoc文字。接收過程的優點在於,接收方既可以是SAP系統,也可以是第三方系統,這也是SAP與第三方進行有效整合的基礎。接收過程由以下三個步驟組成:
儲存Idoc-將文字儲存於資料庫,並進行語法校驗
郵件處理程式讀取Idoc--一個專門設計的IDoc處理程式讀取IDoc併產生SAP或其它系統所需的系統訊息。多個程式可以同時執行。
生成系統文字--處理程式進一步生成系統文字供系統使用,並將結果資訊存於Idoc d的狀態紀錄中。
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) 的概念,其定義結構由以下幾部分組成:
基本資料--所有目標類的通用屬性,如目標標識和預設方法(Method) 。
介面介面--目標的方法(Method), 事件(Event), 特徵(Attributes) 。
鍵(Key Fields)--供BOR中目標檢索使用
方法(Methods)-- 對目標進行所要求的各種操作。
特徵(Attibutes)-- 描述目標特徵。
事件(Events)-- 觸發以改變目標狀態。
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++。代理元件有以下屬性:
Client-要訪問的R/3客戶系統
UserID-R/3使用者
Password-使用者密碼
Language-系統語言
Destination-預先定義的目標名稱
另外,每個元件具有以下方法:
PutSeesionInfo()—設定系統一次呼叫的目標引數
AdviceRfcGuiSink()—用於需要SAPGUI或dubugging的場合。
CommitWork()-用於資料更新,無implicit commit的場合。
InitKeys()-DCOM目標鍵初始化
DimAs()-返回Microsoft ADO(Advanced Data Object) 紀錄集(支援遊標控制)。
其它從R/3 BO定義中繼承的方法。
總起說來,SAP R/3 作為一個相對靈活的ERP系統,利用上述的各種整合技術能夠實現SAP系統之間以及SAP 與其它系統之間的資料/過程的整合。當然,一個應用系統的高度客戶化導致了系統整合的難度。隨著系統功能的增加,多種可供採用的整合技術也就顯得很有必要。對於SAP R/3使用者來說,正確選擇適用的整合技術是實現成功系統整合的關鍵。
利用BAPI,開發人員可以實現對BOR進行實時訪問,從而實現應用系統(SAP-SAP)之間在資料/邏輯層上的有效整合。
本文來自CSDN部落格,轉載請標明出處: http://blog.csdn.net/zltpc007/archive/2007/11/02/1863094.aspx