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

大概八月份的時候做過一個有關兩個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的調用屬性
• 從aRFC接收結果
• 保持遠端上下文
• aRFC的并行處理

有關aRFC變體的描述：

• CALL FUNCTION - STARTING NEW TASK
• RECEIVE
• WAIT UNTIL
• RFC示例

事務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的資訊, 請看:

• bgRFC: 配置
• bgRFC: 管理
• bgRFC: 程式設計

本地資料隊列：LDQ

本地資料隊列（Local Data Queue ）是一種特别的RFC通信。在這種應用情況下，系統不會主動發送資料。相反，根據拉取規則，系統會把資料存儲在本地，直到被外部系統調用（比如移動裝置）。

LDQ可以代替先前由qRFC在不發送場景下提供的功能（qRFC No Send）。相比之下它提供了更有效率的資料模型。

更多内容：

Local Data Queue (LDQ)

名詞對照

scheduler：排程程式

outbound  queue：外向隊列

inbound queue：内向隊列

相關文章：ABAP RFC遠端調用

 　　　　  qRFC示例程式