在解决标题所言问题之前，我们先回头看看RFC和sproxy这两种接口的优缺点。

　　关于PI接口的实现，目前我了解到的各大国企项目像中海油、中石化、国网等，普遍实现方式是RFC和代理类sproxy这两种。至于我现在做的国网人资项目，由于历史原因更或者是接口开发者贪图自己的方便原因，实现方式都是RFC类型（很不幸，为了项目的延续性和未来交接，那个贪图方便的人就是指我）。RFC类型较之于代理类存在了很多弊端，总体而言有以下几点：

1、RFC类型（外围服务）使用的SM59 Destination这种连接形式存在着性能瓶颈，最无法忍受的是丢数据现象。我在为薪酬组开发薪酬过账接口时，PID的环境下SM59连接丢数据现象非常严重，几乎接近50%的失败率，当然这里面存在了开发环境分配的服务器资源不足的原因，好在PIP并没有此情况，但依然无法接受。

2、当业务出现变更，调整了RFC的传入传出参数时。RFC类型的接口需要在PI的ESR配置部分重新导入函数。如果接口还在开发环节还好，如果已传生产就带来了额外的工作量。同时由于通道缓存问题，PI的IB部分也需重新激活才可以。

3、SM59创建的连接PROGRAM ID需要在环境单独创建。

4、从项目的协作角度来看，大型企业的项目组划分详细，PI和ABAP是作为两个技术部门存在的。往往ABAP开发并不了解PI的开发配置，就会出现abaper在GUI更改了RFC的参数字段，但并未通知PI人员的情况。等传到生产出现了问题，不必要的扯皮就出现了。

下表是更加详细的区别对比：

　　回到标题问题！

　　福利组的两个公积金接口，一个作为服务方，一个作为消费方。两个接口的开发过程都经历过一次小的调整。前者是RFC的传入表结构增加了一个字段，出现了字段映射错位的情况，奇怪的是错位的字段是新增字段前面的字段；在ESR重新导入RFC后，问题没有得到解决。第二个接口是传出表结构里的一个业务类型字段长度变更，变更前长度为2，测试值为Y2。变更后长度为1，值为D。但是外围系统却接受到了D2的值。在ESR重新导入RFC后，问题并没有得到解决。这两种情况在查日志时均显示正常，OM测试，ID测试均正常，并没有字段错位、长度不一致的问题。但在RFC里debug动态断点时错误又真实存在。校验了各个组件无果之后，只能祭出了最后一招，重新激活各个组件。重新激活后，问题得到了解决。后来和其他PI开发讨论这个问题时得知，其实只需要重新激活communication channel就可以，原因是xml报文形式会在CC通道里留有缓存。

　　RFC类型接口的的这些问题完全可以在使用代理类接口后来规避。因为代理类的参数是在PI端进行的开发配置，当业务发生更改需要改变参数时必然会经过PI，参数经过PI推送到GUI，abaper无法在GUI侧直接修改。