RFC的生命周期

遇到的问题

SM04中看到有部分JCO调用的RFC的会话无法释放，极端情况导致所有第三方系统基于RFC的方式，都无法访问SAP。

解决方案

问题原因没有定位到，其实也算不上解决
在确认调用方代码没问题后，在SAP服务器端做了一些优化

1. SAP推荐升级Kernel，出于风险没有采纳
2. 对于特别耗性能的RFC系列接口
   • 优化处理逻辑
   • 减少调用、甚至不调用
3. 过期会话，自动删除

自开发程序，定期执行，记录日志，在哪些接口上挂起了。 稍微一统计，就能识别哪个系统，哪些接口会导致问题。

RFC技术分析

正常的会话

可以通过参数设定多少时间后logout，比如rdisp/gui_auto_logout

RFC的会话

服务器端不会自动释放

个人猜测，RFC技术是很多其他技术的基础，比如ALE、iDoc，SAP在设计的时候就没有考虑去中断RFC的会话。只要调用端不主动释放，会话会一直被保持。

这里不讨论RFC调用时，分配了Work Process且一直在执行中，最后因为达到Work Process最大允许时间而被迫释放的场景。

JCO的会话管理

• 不使用连接池
  调用完即释放
• 使用连接池
  调用完后，继续放到连接池中。连接池中的另一个线程会定时检查池中的连接，若连接达到指定的时间未被使用，由该线程执行释放。

1.这里讨论的是stateless的JCO 3.0 访问方式 。
2.经常在SM04看到，连接池调用的会话保存一段时间后再消失，就很容理解。

挂起场景猜测

以下场景都是个人猜测

1. 调用端突然中断
   比如网络异常

RFC通常都是第三方服务器发起，请求SAP RFC接口，服务器之间网络异常比较少。但是以前在搞ITS时频繁遇到类似问题（ITS和RFC是两个东西），手持设备直接访问SAP ITS服务，仓库之间切换AP，导致SM04中看到会话挂起，这个和ITS的版本也有关系。

2. JCO 2.0中访问没有主动释放
3. JCO 3.0有状态调用没有主动close
4. SAP服务器端异常
   归根到底因为SAP Kernal在特定场景下，无法重置当前会话状态(比如标识此RFC函数已经调用结束)，导致调用端无法回收，SM04中看到就是长时间挂起。

• Kernal 问题，SAP自己产品的Bug

感觉这次遇到的问题类似这个场景，RFC中的代码逻辑，无论CPU处理还是DB取值都比较麻烦，并且函数内部有submit和call transaction之类的调用，可能特定条件触发了会话管理异常，无法标识调用结束？

• 内部工作过程挂起
  比如Dialog WP 等待 DB WP，DB WP因为数据库服务器问题，没有响应，导致Dialog WP也没有响应，表现为SM04中会话挂起

总结

1. RFC会话服务器端不会主动去关闭
2. 谁调用谁关闭
3. 关闭的前提： 服务器端已标识RFC执行完毕

所以面对SM04无法释放的会话，调用方和SAP服务器都可能背锅。