Skip to Content

A few days ago, I concluded a five-part blog series called ABAP calls Java via RFC (1): Introduction. The ABAP Calls Java via RFC (5): Configure the Connection and Run of the series prompted an inquiry by a fellow SCN member, who asked why I was writing about direct RFCs between ABAP and Java in the first place. His understanding was that since SAP’s NetWeaver Process Integration (PI) is available, using RFC in the way I described ought to be a thing of the past.

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.

Summary

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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Vijay Vijayasankar
    I really liked your perspective on consultants – and just sent your blog to my team with specific mention of the summary section.

    The blog itself is quite good (as always) – and brings perspective to a pertinent architecture issue. Architects have biases – some like SOA, others like event based architectures and so on. In extreme cases, they will force fit everything into one model, to the detriment of the solution.
    As you rightly pointed out, there are several use cases where a direct call is warranted.

    (0) 
  2. Krishnakumar Ramamoorthy
    Thorsten Franz

    Just a quick note on your remarks about asynchronous communication in webservices. WS-RM specifications are designed for asynchronous communication in webservices and is supported by both ABAP and Java applications. Within ABAP, WS-RM uses bgRFC which is supposed to be better than the tranditional tRFC/qRFC we know of.

    Good blog, thanks for putting this up.

    KK

    (0) 
  3. Stephen Johannes
    I guess we need to escort the SAP folks out who built the Internet Sales Application, and all other types of e-commerce b2b sales applications built with PI, or is that an allowed exception?

    In addition what about all those portal iviews that directly communicate without using PI?  I find the article conclusion basically absurd.

    Take care,

    Stephen

    (0) 
    1. Thorsten Franz Post author
      Hi Stephen,
      I don’t know the applications you refer to, but the way I understand what you wrote, the Internet Sales Application and similiar B2B applications by SAP use PI for integration. That’s exactly what I advocate as the standard from which one should only deviate with good reason. So what’s the problem?
      Along the same lines, a Portal iView communicating with the back-end can be regarded as the UI layer of an application speaking with its own application layer. This integration is by nature so tight that it falls into the category of tight application which rarely need de-coupling through PI and are good use cases for direct RFCs. Again, what’s the problem?
      By the way, I find it important to differentiate between the recommendations from software development and implementation consulting. Implementation consultants are the “last line of defense” for reality against wishful thinking, so it’s important that they are pragmatic and avoid idealist thinking.
      Cheers,
      Thorsten
      (0) 
  4. Jan Penninkhof
    …it doesn’t make much sense to put PI in between in you webdynpro Java project. But that’s just my opinion after I’ve done a project with and a project without integrating PI as an inbetween layer.

    To my opinion, PI:
    – Adds the need for an additional XI resource to the project, which is demanded by the complexitity of the PI platform.
    – Causes a performance decrease, especially in the synchronous calls that are usually required (in the setup I worked with, delays in PI increases the roundtrip with up to 3 seconds.
    – Decreases the agility of a project team in which the Java- and ABAP developer often have to wait for the PI-mapping to be complete or updated. On top of that, in my project, most PI mappings were just 1:1 mappings, in which PI hardly offered any value
    – Adds an extra point of failure.

    PI only offers value-add in the event that:
    – You’re not only connecting to an ABAP system, but also to other systems
    – BPM is involved

    On top of all this, the adaptive RFC connection has so much nice stuff to offer, which adds to the agilty of your development process. E.g.: I really like the fact that data dictionary information is getting imported (and easily updated) in your webdynpro project, so that you don’t have to create all those types, structures and value lists by hand.

    (0) 

Leave a Reply