The question is valid, and I hope that I can make some convincing points explaining what direct RFCs might still be good for.
Before I’m misunderstood, let me point out that I am an advocate of PI. It or generally a middleware, central integration hub, enterprise service bus, or whatever you want to call it, should be a standard element of complex system and application landscapes. If it’s missing in your landscape, you’re probably spending much more money on development and operations than necessary.
This blog does not discuss PI vs. RFC, which would be the wrong question. It discusses the question: "Are there still uses for direct RFCs even though PI is available?"
Why should you definitely have a PI?
It’s important to de-couple software systems wherever possible and pursue the goal of encapsulation also at software component level. This gives you the flexibility to change integration scenarios (change an interface, replace a service provider, even extend a process) without affecting other systems.
The integration knowledge – which function is located in which system, with which signature, technology, mappings, process knowledge, message statuses, etc. – needs to go somewhere, and it’s a good idea to locate it centrally in a system which is well-suited for the purpose.
Process knowledge can be modeled using BPEL
Central monitoring and error handling
Better compatibility with outside-world web services and more powerful within the SAP landscape than the Java and ABAP application servers
Can it be desirable to build an integration process without PI?
Firstly, there are still SAP landscapes without a PI system, sometimes even for a good reason. PI and any similar tool is only worth its TCO if the complexity of the integration scenario which it supports is sufficiently high: In a landscape consisting of two ABAP systems forever communicating through one RFC in one direction, a PI would be overkill and actually increase complexity.
Secondly, even if there is a PI, you don't necessarily want to run every communication through it. There may well be integrations between partner systems that are by nature so tightly coupled that nothing should stand between them. This is especially true for the ABAP and the Java stack of a dual stack system, and may also be true if the ABAP and Java stacks do not share one application server, but are still closely paired. For example, you would not put a PI against a BI Java and a BI ABAP system, which is typically a very tight one-to-one pairing. (An ironic example are the Java and ABAP stack of the PI itself, which communicate of course without the help of another PI because infinite regression is bad for you.)
Thirdly, simple ad-hoc integrations may be created with direct peer-to-peer connections; as complexity grows, you can move them to PI.
Ok, but when to use RFCs and not Web Services?
There are some cases where the specific features of the RFC protocol can be very desirable. On the sender side of an RFC call, you have all the different RFC flavours such as tRFC, aRFC, or qRFC, not all of which can be easily replaced by a web service call: It’s a simple way of firing a transactional, asynchronous, or queued message.
Dual-stack system are becoming less frequent for very good reasons (I’m not a fan either), but if you have one (again, probably for a good reason), or another scenario in which two partners reside on the same physical system, then the “Fast RFC” allows you to communicate extremely efficiently between them because they can pass parameters by means of shared memory rather than going through the TCP/IP stack.
If the called system is an AS ABAP, the calling system is an AS ABAP or Java, the target is a pre-existing RFC, and there is no perspective of the ABAP system being replaced in providing the service, it’s alright not to wrap the RFC into a web service.
In rare cases, a Java system might want to “step in” and implement a service that is normally provided by an ABAP system.
For light-weight server programs running on a Java SE platform (as opposed to Java EE), RFC might actually be simpler to implement (with the classic JCo, not the JCo Provider Service) than a SOAP web service.
Finally, why learn about RFC if you do use a PI?
Providing services through the JCo Provider Service behind a PI will rarely make sense even if the calling system is an ABAP system.
However, RFC is one of the protocols supported by PI, so using RFC on the caller or receiver side doesn’t rule out the use of PI.
It’s not the same. Apart from the different RFC flavours, RFC and the JCo have other features that differentiate it from SOAP web services, such as callbacks to the internal session of the caller (yes, even between ABAP and Java), and IDoc integration.
Last but not least, it’s always good to learn something. It might come in handy one day.
Many use cases are for direct or indirect RFC calls between ABAP and Java systems are quite weird, but so is everyday life in IT. When presenting a consultant with the question on how to handle a particular integration scenario, observe him or her closely.
If your consultant tells you to go without a PI and make direct RFCs the general rule in a complex landscape, you should seriously question that and either ask for your money back or call security to have the consultant escorted outside.
If your consultant gives you any rule and claims there are no exceptions, you should bill the consultant.
If the consultant asks for more details in order to understand the process first, you’ve probably made a good choice – because PI did not kill RFC.