Warning: This blog is essential a rant and an opinion piece! 
I have repeatedly mentioned my dislike of the RFC functionality especially in terms of PI-related integration. RFC is a technology from the old days of SAP that amazingly (and unfortunately 
) still surviving in these days of SOA, cloud and mobile!
Even SAP themselves have publicly come out to discourage the use of RFCs in the following guideline published years ago, but unfortunately the use of RFC is still widespread today.
SAP Guidelines for Best-Built Applications that Integrate with SAP Business Suite
SOA-WS-3. If access is needed to SAP application functionality that has not yet been service-enabled, SAP recommends wrapping remote function calls (RFCs) or BAPI® programming interfaces as web services. Direct access to RFCs or BAPIs is possible, but it is not encouraged.
In my humple opinion, it is possible to design and architect an integration landscape that is free from the usage of RFC in all its form. However, this requires an architectural approach that considers integration holistically (factoring in all the parts - middleware and backend systems) instead of the silo approach of limiting integration to the sole responsibility of the middleware/PI/PO.
Here are my thoughts on the common usage of RFCs in PI-related integration and some possible alternatives.
RFC as a lookup
The introduction of the RFCLookup functionality in PI 7.1 has unfortunately contributed to the proliferation of RFC usage in PI, much to the detriment of the SOA guiding principles. A graphical SOAP Lookup functionality would have been more appropriate but until now there is no indication if we will ever have that.
As I mentioned before in this blog, the RFCLookup functionality is tolerable at best and buggy at worst!
The common use case for RFCLookup is for data enrichment in PI - enriching the contents from the source prior to delivery to the target system. The usage of RFCLookup implies that either the sender or the receiver is an SAP backend system. If we look at integration holistically, especially taking into consideration the debate of Integration Logic Vs Business Logic, it can be argued that data enrichment should be performed at the backend system - prior to sending for sender systems or after receiving for receiver systems. Sometimes, the argument for RFCLookup is to reduce ABAP development on the SAP backend system but this argument becomes invalid if a custom RFC-enabled function module needs to be developed to be used by the RFCLookup in PI. More often than not, this is true as commonly the data enrichment requirement is unlikely to be fulfilled by existing standard SAP RFCs.
Here are some options for performing data enrichment on the backend SAP systems.
BAdI, User Exits
If the interfaces used in the backend systems are standard SAP functionality (RFC, IDoc, Enterprise Services), data enrichment can be handled in the user exits or BAdIs.
Integration Framework
A more robust approach would involve having an integration framework in the backend system. Such frameworks provide capability for data enrichment/translation (fix values or value mapping), validation and logging. Below are some options of standard and custom frameworks:
- Application Integration Framework (AIF) - a licensed framework by SAP for interfaces using IDoc, Proxy, RFCs
- Custom framework for IDoc-based interfaces
- Custom framework for proxy-based interfaces with FEH/ECH/PPO
Even if data enrichment lookups from PI cannot be avoided, it is still possible to perform SOAP based lookup which provides better logging mechanism (although it takes more effort.) Below is a blog utilizing SOAP lookup via ABAP proxy.
RFC as an interface
As we can see from this example thread, there is no clue what happens after an RFC call is executed as there are no traces/logs in the called system. Even though the message status in PI is "delivered", it is hard to determine what happened. This makes troubleshooting and supporting such an interface difficult.
Instead of using RFC as an interface (either sender or receiver), there are other alternatives as listed below:
- Exposing the RFC as a web service as mentioned by the guideline above - this uses the Web Service Runtime of the SAP backend system which provides better logging and error handling capabilities
- Proxy interface - the SAP recommended outside-in approach for developing new custom interfaces based on ESR. The RFC function module can be called within the proxy logic
- IDoc interface - If the RFC is a Business Object (BOR) function module, associated IDoc/ALE objects can be generated for it using BDBG. The IDoc basically just wraps around the RFC function module, and also provides better error handling capabilities
Conclusion
As mentioned in the arguments above, with some effort in design and architecture, it is possible to avoid usage of RFC in PI-related integration. The end results are more robust interfaces and increase in supportability. Wherever I go, I try my best to advocate such an approach. However, there are organizations where the usage of RFC is so deeply embedded into the architecture and design that it is hard to avoid it.
If you have other thoughts, whether for or against this, feel free to comment below - I'd love to hear your thoughts 