目錄
正文
大概八月份的時候做過一個有關兩個SAP系統間成本分攤傳輸的項目，使用到了RFC（Remote Function Call）技術。因爲之前有着醫療-CRM相關接口開發的經驗，以爲自己對RFC很熟悉了，做起來會很順利，不想還是遇到了些問題。打算整理一下有關它們的內容，進一步學習。
本文內容的主要來源是SAP的英文文檔。會比較偏重基本概念上的東西，偶爾涉及實際的代碼、配置。後續可能會根據我的實際使用情況更新更詳細的介紹。
本文鏈接：http://www.cnblogs.com/hhelibeb/p/8066753.html
總述
對於SAP與SAP系統及SAP與非SAP系統之間的連接而言，遠程函數調用（Remote Function Call，以下簡稱RFC）是一種標準的通信方式，它可以實現對遠程系統中函數的調用。
所有RFC類型都通過CPI-C或TCP/IP協議進行傳輸。 它們構成了一種Gateway通信。
本文是對所有RFC變體的描述，它們有着不同的特性和適合的使用場景。
同步RFC：sRFC
同步RFC（Synchronous RFC，sRFC）是最基本的RFC形式。在sRFC調用中，調用者會等待遠程被調用者的處理過程。
它的語法形式是：
CALL FUNCTION func DESTINATION dest.
典型的使用場景包括：
- 銷售：爲不同系統創建採購訂單（central sales）。
- 銷售：對於某個查詢，在供應商系統裏執行一個對於指定物料的可用性檢查。
- 物料管理：在另一個系統裏對某個物料訂單執行來源判斷。
- CRM/SRM：對SAP後端系統發起某個物料的可用性檢查。
- CRM/SRM：在SRM組件中創建採購訂單時，在會計集中核算中爲你的成本中心進行預算檢查。
- 會計：向會計集中核算系統請求一個成本中心清單。
- BW：調用BW組件（商業信息倉庫）來請求一個特別的evaluation。
異步RFC：aRFC
異步RFC（Asynchronous RFC，aRFC）類似與tRFC，用戶在繼續調用會話之前，不需要等待它們的完成。不過，aRFC和tRFC之間也存在幾點不同的地方：
- 當調用者開始一個aRFC的時候，被調用的服務器必須可以接收請求。aRFC的參數不會記錄在數據庫中，而是直接發送給對方服務器。
- aRFC允許用戶與遠程系統進行交互式對話。
- 調用程序可以從aRFC接收結果。
你可以在當你需要建立和一個遠端系統的連接、但是希望在調用RFC後不希望等待結果而是希望繼續處理時使用aRFC。aRFC也可以發送給相同的系統。在這種情況下，系統打開一個新的會話（窗口）。你可以在調用對話和被調用會話間切換。使用下面的語句開啓一個aRFC：
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION ... EXPORTING... TABLES ... EXCEPTIONS...
RECEIVE RESULTS FROM FUNCTION Remotefunction 用於一個子程序內接受aRFC的調用結果。可以使用以下接收參數：
-
IMPORTING
-
TABLES
-
EXCEPTIONS
附加項KEEPING TASK阻止連接在接收處理結果後關閉。相關的遠程上下文（滾動區域）保持可以重用的狀態，直至調用者終止連接。
更多有關aRFC的信息可以從以下地方獲取：
有關aRFC變體的描述：
事務RFC：tRFC
在使用事務RFC（ transactional RFC，tRFC）的時候，被調用的函數模塊在被調用系統中正好運行一次（Exactly Once）。
遠端系統不需要在RFC客戶端程序運行tRFC的時候可用。tRFC組件將被調用的RFC函數和相關數據存儲在SAP系統的數據庫裏，包含一個唯一的事務標識符（transaction identifier，TID）。
如果調用發送了，接收系統卻是宕機狀態，調用會保留在本地隊列中一段時間。調用對話程序可以在不等待遠程調用成功/失敗的情況下繼續運行。如果接收系統在一段時間後仍然不可用，調用將被計劃爲後臺作業運行。
tRFC使用後綴IN BACKGROUND TASK.
就和同步調用一樣，參數 DESTINATION在遠程系統定義了程序上下文。結果是，如果你對一個destination重複地調用一個函數（或者一次性調用多個函數），則可以在相同的上下文中訪問被調用函數的全局數據。。
系統會在表ARFCSSTATE和表ARFCSDATA中記錄遠程連接請求和它們的全部參數值。你可以使用事務SM58來查看。當調用程序到達COMMIT WORK語句時，遠程調用會被轉發到給對方系統。
在兩個COMMIT WORK之間，所有的擁有同一個destination的tRFC屬於同一個邏輯單元（LUW）。
tRFC處理流圖示：
你可以在某些情況下使用使用tRFC，比如，對於需要在事務的不同階段更新相關數據庫表的複雜的處理過程。
tRFC會確保所有的計劃更新在程序到達COMMIT WORK語句時被執行。
（注意：tRFC的定義中不能有任何EXPORT參數，因爲調用程序中如果有IMPORT參數，就會導致語法錯誤。此外，你也不可以對執行回調的程序進行異步調用）
系統可用性：
如果遠程系統不可用，SAP系統會將報表RSARFCSE計劃爲後臺作業，並將相關的事務ID作爲變式，再進行處理。這個報表程序會重複地被調用，直到它成功地連接對方系統爲止。
當被計劃爲後臺作業時，RSARFCSE自動地以一個時間間隔運行（默認是每15分鐘運行一次，最多嘗試30次）。你可以通過增強程序SABP0000和SABP0003來自定義該時間間隔。
通過SM59配置destination，選擇一個destination並且選擇 編輯->TRFC選項，在這裏定義連接嘗試次數上限和重複連接嘗試的時間間隔。
如果在嘗試指定的次數後依然不可抵達相應的系統，系統會停止調用RSARFCSE，並寫入狀態CPICERR至表ARFCSDATA中。在另一個指定的時間後（默認是8天），在表ARFCSSTATE內的條目也會被刪除。當然也可以定製這個時間，或者手動在SM59啓動相應的事務條目。
tRFC的缺點：
- tRFC獨立地處理所有LUW。根據激活的tRFC數量，程序有可能會顯著地降低調用系統和被調用系統的性能。
- 此外，在應用中定義的LUW的調用順序是不能得到保持的。因此無法保證事務會按照應用期望的順序運行。tRFC唯一能保證的只有：所有LUW都會或早或晚地被傳輸。
可以在這裏查看tRFC語句的描述：
CALL FUNCTION IN BACKGROUND TASK
隊列RFC：qRFC
隊列RFC（queued Remote Function Call，qRFC）是tRFC的一個擴展。它允許你將多個tRFC調用序列化爲一個隊列。
qRFC調用會首先被函數模塊TRFC_SET_QUEUE_NAME進行序列化處理，然後這些調用被一個tRFC進行實際上的dispatch。
qRFC可以作爲外向隊列（由調用系統序列化）處理，或者是內向隊列（由被調用系統序列化）。
以下是三種事務數據傳輸的場景（爲什麼圖片中的文字是德文？）：
場景1：tRFC
該場景適用於數據彼此間獨立發送的情況。系統1中存在一個調用應用（client）使用tRFC連接系統2中的被調用應用（r server)。在該場景中，數據由tRFC傳輸，意味着發送到目標系統的函數模塊調用會被保證只運行一次。你不可以定義函數模塊運行的順序和時間。如果傳輸過程中發生了錯誤，系統會計劃一個後臺作業，在15分鐘後再次發送函數模塊調用。
場景2：帶有外向隊列的qRFC
在該場景中，發送系統使用一個外向隊列來序列化被髮送的數據。這意味着發送系統的外向隊列包含着存在依賴關係的函數模塊調用。當數據發送時，會保持確定的順序，並且調用會以正好一次且有序的方式（exactly once in order）發送給目標系統。
注意：目標系統處理時不需要改變qRFC的順序，但是，它必須開啓tRFC功能。
場景3：帶有內向隊列的qRFC（以及外向隊列）
在這個場景下，不僅發送系統（client）有外向隊列，目標系統也有內向隊列。如果qRFC存在有內向隊列，這也意味着它在發送系統上必然存在外向隊列。內向隊列在一段時間裏只能處理系統資源允許處理的函數模塊調用數量。它可以防止服務器被一個客戶端阻塞。只有在服務系統單獨存在一個內向隊列的場景是不可能存在的，因爲需要在客戶端系統存在外向隊列，來設置順序並阻止單獨的應用阻塞客戶端系統的整個工作進程。
更多相關信息可見：
後臺RFC：bgRFC
使用
bgRFC（Background Remote Function Call）允許被調用程序稍晚一些接收數據，而不是同步接收。接收數據的時候，需要保證數據只出現一次且無序( transactional) 、或者只出現一次且有序(queued)。
使用bgRFC進行異步調用，會有如下優勢：
- 在同一個SAP系統內（同一個系統ID，同一個client）：解耦，同時提供了並行化能力。負載會分佈在該系統的可用的應用服務器上。這個bgRFC場景被看作一個內向程序。
- 在兩個遠程SAP系統間：解耦，並且由此可以實現應用或業務場景的物理細分。異步調用的結果是，調用者和被調用者的應用服務器的關鍵特性差異可以得到平衡。記錄工作在調用系統中完成。這個場景是一個外向程序。
- 兩個程序結合爲外-內程序：該方式可以獲得全部優化選項的優勢。不過，如果你選擇了這樣做，數據會被記錄兩次，一次是調用者（外向處理）、一次是被調用應用（ 內向程序的特殊類型）。這導致數據庫、應用服務器會有額外的負擔。
bgRFC使用隊列組織不同的調用。當一個調用同時被放置在多個隊列的時候，系統會爲這些隊列創建依賴。這帶來了一個同步點（synchronization point），類似於鎖。
如果一個調用處於依賴隊列中，那麼當且僅當它位於依賴隊列的最上層時，它纔會被處理。
對於同一個destination，不可以將bgRFC和tRFC、qRFC結合起來使用。不過，對於不同的destination，你可以定義你想使用的通訊類型。
語法：
CALL FUNCTION 'function_name'
IN BACKGROUND UNIT unit
EXPORTING ...
集成
從qRFC轉換爲bgRFC的應用程序，必須支持創建qRFC中的隊列與bgRFC中的隊列之間的臨時鏈接的遷移方案。通過這樣的方案，可以保證正確的隊列順序，即便是在從qRFC變爲bgRFC的時刻。
注意：從bgRFC改回qRFC是不可能的。
在SAP NetWeaver Release 7.11以及更高的版本上，bgRFC也可以和basXML（二進制ABAP序列化XML）通信協議一起使用。
架構
傳統的qRFC模型只有在數據被RFC調度程序處理的時候才探測各個獨立單元之間的依賴關係。對於每個destination，外向調度程序都會開啓一個調度程序來處理這個destination的數據。
與之相對的是，bgRFC的依賴關係在數據存儲的時候就決定了。通過這樣做，RFC調度程序可以一次性找到所有的需要被處理的單元，並且通過最小的努力（minimum effort）就可以找到它們之間的依賴關係。在存儲數據的時候需要付出的額外努力，則可以在很大程度上由數據庫設計中的高效率算法和優化補償。
每個客戶端定義一定數量的外向計劃，並且並行處理隊列負載，雖然目標系統的負載會在一個較短的時間間隔後被確定，但是也因此會更加精確。
單元和隊列的刪除程序：
和傳統的程序不同，如果有任何單元或隊列被刪除，依賴依然會保持。因爲單元會被先打上標記，並且在這之後只是被調度程序刪除。
如圖，在刪除了Unit4之後，Unit6只能在Unit3之後運行，因爲Unit4只有在調度程序處理過Unit3之後纔會被刪除。如果你刪除掉queue2，那麼會發生下面的情況：
Unit6會在Unit2之後運行，所有選定的unit都會被調度程序刪除。
注意：刪除隊列或者單元總是具有風險的。在我們的例子裏，它會導致Unit6遇到錯誤，或者導致目標系統的數據庫不一致，因爲它的前提Unit4因爲被刪除而沒有運行。
Gateway:Gateway是另一個潛在的性能瓶頸，在bgRFC中，它也得到了優化。bgRFC中的新的概念是會調節在一臺應用服務器上同時運行的外向調度程序的最大數量，也會調節全部RFC調度程序可用的最大連接數。這個限制會保護本地的Gateway使之不至於過載。
每個發送系統的並行的外向調度程序數量和它們的最大連接數也是可配置的，因此對於destination的Gateway也存在過載保護。
性能的影響：新bgRFC實現的優化在高負載、多依賴的情況下特別明顯。首次運行的時候，線性對數可伸縮性（a linear logarithmical scalability）的RFC數據處理成爲可能（視系統兼容性而定）。
函數隊列的事務特性使得，在處理單獨的單元時，bgRFC不太容易取得明顯的性能提升，但是在應用更多或者更快的硬件的時候，則可以明顯提升吞吐量。限制因素會是數據庫的性能和這些單元的處理速度。
此外，新的API也是優化的一部分。一些多餘的函數被移除，某些舊的API也不再應用。這使得相關的工作更加平滑和有效率，減少支持團隊和開發團隊的工作量。
更多信息：
更多有關bgRFC的信息, 請看:
本地數據隊列：LDQ
本地數據隊列（Local Data Queue ）是一種特別的RFC通信。在這種應用情況下，系統不會主動發送數據。相反，根據拉取規則，系統會把數據存儲在本地，直到被外部系統調用（比如移動設備）。
LDQ可以代替先前由qRFC在不發送場景下提供的功能（qRFC No Send）。相比之下它提供了更有效率的數據模型。
更多內容：
名詞對照
scheduler：調度程序
outbound queue：外向隊列
inbound queue：內向隊列