SAP RFC介紹：關於sRFC，aRFC，tRFC，qRFC和bgRFC

時間 2019-11-07

標籤 sap rfc 介紹關於 srfc arfc trfc qrfc bgrfc 简体版

原文原文鏈接

大概八月份的時候作過一個有關兩個SAP系統間成本分攤傳輸的項目，使用到了RFC（Remote Function Call）技術。由於以前有着醫療-CRM相關接口開發的經驗，覺得本身對RFC很熟悉了，作起來會很順利，不想仍是遇到了些問題。打算整理一下有關它們的內容，進一步學習。html

本文內容的主要來源是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：ide

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存在有內向隊列，這也意味着它在發送系統上必然存在外向隊列。內向隊列在一段時間裏只能處理系統資源容許處理的函數模塊調用數量。它能夠防止服務器被一個客戶端阻塞。只有在服務系統單獨存在一個內向隊列的場景是不可能存在的，由於須要在客戶端系統存在外向隊列，來設置順序並阻止單獨的應用阻塞客戶端系統的整個工做進程。

更多相關信息可見：

Queued Remote Function Call (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）。相比之下它提供了更有效率的數據模型。

更多內容：

Local Data Queue (LDQ)

名詞對照

scheduler：調度程序

outbound queue：外向隊列

inbound queue：內向隊列