在解決標題所言問題之前，我們先回頭看看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側直接修改。
轉自：https://www.cnblogs.com/fanjb/p/10782637.html