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变体的描述：

事务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）。相比之下它提供了更有效率的数据模型。

名词对照

scheduler：调度程序

outbound queue：外向队列

inbound queue：内向队列