ABAP RFC接口程序设计(client) james_lx版
经过1年的实践，多次处理RFC接口相关程序后，我发现可以提出一个RFC标准设计模式（CLIENT方式），用于以后的接口程序设计。该模式主要运用于：外部数据传入SAP系统，SAP系统处理后返回结果，这样的场景。外部系统数据进入，是基于RFC函数的。数据通过RFC的参数传入SAP系统。
RFC函数的程序代码做如下事情：
- 数据变量定义
- RFC传入参数检查
- 传入的数据，系统时间，自动编号等数据组装到日志表前部分数据中
- 保存日志表前部分数据到日志表
- 调用SAP系统功能完成数据处理
- 第5步的结果保存到日志表的后部分字段中并写入RFC返回的参数中。
我们以一个实际的RFC程序例子来说明：
示例RFC程序： ZSD_IF_FM020 销售订单数量修改及关闭
RFC业务背景： 在DMS销售系统，某销售订单数量被更改或打上关闭标识，这个数据需要从销售系统传到ERP系统中，使ERP系统中做相应的修改。
RFC函数涉及数据表：
中文名称 | 程序中名称 | 类型 |
RFC传入数据表 | GT_ITEM | 内表 |
RFC 返回数据表 | GT_RETURN | 内表 |
日志表 | ZSD025 | 透明表 |
*该RFC函数涉及2个变量，都是内表格式。
GT_ITEM放的是DMS向ERP修改销售订单的数据，
而GT_RETURN用于ERP接口做完事情后，返回给DMS的消息数据。
ZSD025日志表用来记录RFC工作的过程，用于用户以后随时监控该接口的工作情况。
RFC函数ZSD025日志表字段：
客户端 | 日志表前部分 |
ID | |
创建记录的用户 | |
创建记录的日期 | |
创建记录的时间 | |
销售和分销凭证号 | |
物料号 | |
数量 | |
销售凭证项目 | |
订单状态(N不变，U修改，D删除) | 日志表后部分 |
处理标志 | |
处理日期 | |
处理时间 | |
消息文本 |
*在日志表的前部分字段，用于记录DMS数据传入了ERP系统。
日志表的后部分字段，是等待RFC函数中主要的工作（修改了ERP系统中的销售订单数据）完成后，记录到日志表。
处理日志表的前部分代码，业务逻辑简单，代码也相应简单，几乎不会出错。
而RFC在修改ERP内的销售订单（或其它复杂的处理）时，会调用ERP系统功能，不排除有出错或系统DUMP的可能。如果出现任何问题或影响到后面的代码都不能执行，我们也可以清晰的从日志表前部分看到发生了什么。
因为这样设计，日志表的前部分和后部分夹作复杂的代码，复杂代码如果异常，可以从前部分看到RFC是要处理的记录。
ABAP 的OPENSQL，Modify命令非常有意思， 它会检查数据库表的数据，是否是已经有的（主键），如果有，接下来它会修改这一条数据。
这个Modify命令正好和我们的日志保存功能配合：
第一次我们对日志表写入了前部分数据。
ERP代码处理
第二次我们对日志表写入后半部分数据，使用Modify命令。
