对于SAP与SAP系统及SAP与非SAP系统之间的连接而言，远程函数调用（Remote Function Call，以下简称RFC）是一种标准的通信方式，它可以实现对远程系统中函数的调用。

所有RFC类型都通过CPI-C或TCP/IP协议进行传输。 它们构成了一种Gateway通信。

同步 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接收结果。
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname

DESTINATION ...

EXPORTING...

TABLES ...

EXCEPTIONS...

事务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会确保所有的计划更新在程序到达COMMIT WORK语句时被执行。

（注意：tRFC的定义中不能有任何EXPORT参数，因为调用程序中如果有IMPORT参数，就会导致语法错误。此外，你也不可以对执行回调的程序进行异步调用）

系统可用性：

如果远程系统不可用，SAP系统会将报表RSARFCSE计划为后台作业，并将相关的事务ID作为变式，再进行处理。这个报表程序会重复地被调用，直到它成功地连接对方系统为止。

当被计划为后台作业时，RSARFCSE自动地以一个时间间隔运行（默认是每15分钟运行一次，最多尝试30次）。你可以通过增强程序SABP0000和SABP0003来自定义该时间间隔。

通过SM59配置destination，选择一个destination并且选择 编辑->TRFC选项，在这里定义连接尝试次数上限和重复连接尝试的时间间隔。

队列RFC：qRFC

队列RFC（queued Remote Function Call，qRFC）是tRFC的一个扩展。它允许你将多个tRFC调用序列化为一个队列。

qRFC调用会首先被函数模块TRFC_SET_QUEUE_NAME进行序列化处理，然后这些调用被一个tRFC进行实际上的dispatch。

qRFC可以作为外向队列（由调用系统序列化）处理，或者是内向队列（由被调用系统序列化）。

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语句的描述：

队列RFC：qRFC

队列RFC（queued Remote Function Call，qRFC）是tRFC的一个扩展。它允许你将多个tRFC调用序列化为一个队列。

qRFC调用会首先被函数模块TRFC_SET_QUEUE_NAME进行序列化处理，然后这些调用被一个tRFC进行实际上的dispatch。

qRFC可以作为外向队列（由调用系统序列化）处理，或者是内向队列（由被调用系统序列化）。

范例：

相关Demo
系统中几个标准demo程序
RSTRFCT0
RSTRFCT1
RSTRFCQ4 

场景1：tRFC

该场景适用于数据彼此间独立发送的情况。系统1中存在一个调用应用（client）使用tRFC连接系统2中的被调用应用（r server)。在该场景中，数据由tRFC传输，意味着发送到目标系统的函数模块调用会被保证只运行一次。你不可以定义函数模块运行的顺序和时间。如果传输过程中发生了错误，系统会计划一个后台作业，在15分钟后再次发送函数模块调用。

场景2：带有外向队列的qRFC

在该场景中，发送系统使用一个外向队列来序列化被发送的数据。这意味着发送系统的外向队列包含着存在依赖关系的函数模块调用。当数据发送时，会保持确定的顺序，并且调用会以正好一次且有序的方式（exactly once in order）发送给目标系统。

注意：目标系统处理时不需要改变qRFC的顺序，但是，它必须开启tRFC功能。

场景3：带有内向队列的qRFC（以及外向队列）

在这个场景下，不仅发送系统（client）有外向队列，目标系统也有内向队列。如果qRFC存在有内向队列，这也意味着它在发送系统上必然存在外向队列。内向队列在一段时间里只能处理系统资源允许处理的函数模块调用数量。它可以防止服务器被一个客户端阻塞。只有在服务系统单独存在一个内向队列的场景是不可能存在的，因为需要在客户端系统存在外向队列，来设置顺序并阻止单独的应用阻塞客户端系统的整个工作进程。

　IDOCRFCABAP Proxy
实现方式通过Message Control、Partner Profile、Port等设置，实现业务数据的EDI或ALE功能，非标准功能需要通过增强技术实现，最后在PI中将IDOC Metadata导入通过SE37开发功能函数，并激活远程调用功能（Remote Enabled），在PI中将RFC Metadata导入通过建立SAP与PI系统两个集成引擎的连接，在SAP系统中生成service interface的代理类，通过类中的method实现集成
传输方向SAP传出业务数据保存时，根据Message Control机制，将application data组织为idoc并发出，idoc被存入SAP数据库，同时记录idoc状态自开发程序调用RFC函数将数据发出，对于异步RFC只赋值传入参数，对于同步RFC需赋值传入参数，并通过传出参数获得返回值自开发程序调用ABAP Proxy代理类中的method将数据发出，对于异步场景只赋值传入参数，对于同步场景需赋值传入参数，并通过传出参数获得返回值
传入SAP外部系统传入idoc时，根据Partner Profile中的配置，调用相关功能函数或工作流来更新application data，idoc被存入SAP数据库，同时记录idoc状态PI自动调用RFC函数，对于异步RFC只赋值传入参数，对于同步RFC需赋值传入参数，并通过传出参数获得返回值，从而传回外部系统PI自动调用ABAP Proxy代理类中的method，对于异步场景只赋值传入参数，对于同步场景需赋值传入参数，并通过传出参数获得返回值，从而传回外部系统
所用传输协议qRFC/tRFCtRFCqRFC
数据格式SAP:IDOC;PI:IDOC-XMLSAP:内表;PI:XMLSAP:内表;PI:XML
实时性实时/定时实时/定时实时/定时
传输模式支持支持异步，以及两个SAP系统间的双异步同步/异步同步/异步，并支持异构系统间的双异步
性能中中高
日志监控功能优秀一般良好
开发起点中低中
开发工作量小一般一般
开发灵活性一般一般高
SAP开发人员的技能要求IDOC基本配置技能、用户出口查找与ABAP开发技能基本ABAP开发技能、SE37开发函数的技能基本ABAP开发技能、面向对象开发技能
可能会发生的问题队列堵塞性能瓶颈、丢数据队列堵塞
其它　　　
Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生