The blog post formerly known as “Why I hate… I mean, avoid using RFC in PI

Warning: This blog is essentially 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 😥 ) is 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 humble opinion, it is possible to design and architect an integration landscape that is free from the usage of RFC with respect to PI. 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 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:

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.

Mapping-Lookup to ABAP-Proxy

RFC as an interface

As we can see from this example thread, there are no clues 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 definitions. 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 direct usage of RFC in PI-related integration. This results in 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 🙂

To report this post you need to login first.

9 Comments

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

  1. Charan R

    Hi Eng,

      I second with your thoughts on the usage of RFC in PI. RFC look up may have been the culprit for increased usage of RFCs in PI. In one of the projects that I worked on there was rampant use of RFCs which were created for some odd reasons even when ppl knew that there won’t be any logs of the msg processing in SAP for RFC calls.

    It is better to go with alternatives rather than use RFC.

    Rgds

    Charan

    (0) 
  2. Eduardo Bertoni

    Hi Eng Swee,

    I agree with you, I see you’ve linked my thread… Thing is, I proposed RFC since proxy wasn’t an option, until they see proxy is the option… Now I’m migrating everything to be proxy-based, but a thing that still forces people to use RFC’s is that once in ECC ABAPers tend to say it’s easier to work with RFC’s rather than proxies.

    (0) 
  3. Michal Krawczyk

    Hi Eng Swee,

    Completely agree with that point – will soon post a blog on AIF with BRFPlus integration for doing such lookups at the backend systems 🙂

    Regards,

    Michal Krawczyk

    (0) 
  4. Iñaki Vila

    Hi Eng,

    I agree with your opinion about to avoid the RFC interfaces in PI, mainly because it is a not open technology with only SAP meaningful and for the monitoring lacks.

    – About RFC lookup, i think all the “external” lookups (SOAP, JDBC or what you can do in a MM) are not a good idea, worse if you are in a sync scenario.

    – About an interface, i have no doubt to choose an ABAP proxy, although don’t you think the exposing like webservice is a better idea if you want to do more generic, decoupled and standard your integration?

    However i can post a good points about my old RFC friend, may be losing your original idea about your blog (my apologizes for this 🙂 ):

    – I wonder, is RFC necessary?, it is like to say, is COBOL nowadays necessary?. In my opinion the answer is Yes. Not all companies can invest to change the old integrations, that they are very critical. Sometimes it is better to keep something that works and don’t make a new headache.

    – If you don’t use a middleware integration because the perfomance is critical or the client can not invest in that, the RFC is the faster way to communicate. With a colleague i tested years ago the faster way to connect Delphi with an ECC directly, and the faster was the RFC.

    Starting to do webservices or ABAP proxies based in function modules. To wrap the RFC module functions can be tedious to ABAPers, you have to maintain your function module in two places.

    It’s quite intereseting these kind of blogs, about to share our ideas. Another great blog Eng!.

    Regards.

    (0) 
  5. Eng Swee Yeoh Post author

    Thanks for all the feedback so far! 🙂

    Eduardo,

    Glad to hear that common sense have prevailed 🙂

    I am an ABAPer too and those who say RFC is easier to work with instead of proxies are more often than not those who do not code in ABAP Objects. (There’s a never-ending debate in the ABAP Development space about OO vs procedural, but I rather not get into that!) If they really are not willing to develop proxies, there is always the option of developing the RFC and exposing it as a web service as mentioned above – I wouldn’t go for it, but it’s there for those who want to.

    Michal,

    Looking forward to your blog – will be interesting to know the latest alternatives available 😉

    Inaki,

    – IMHO, any organization that is serious about integration should have some form of integration framework on their backend system. This allows for the separation of business logic and integration logic, and since lookups are normally related to business logic, we can avoid it in PI.

    – I think it’s also possible to develop custom generic interfaces via proxy too. It will be something similar to the standard Enterprise Service proxies, for example the PurchaseOrderERPRequest_In_V1 can be configured to be used in multiple scenarios. It’s all about modelling a generic ESR service interface based on the backend business process instead of one that is usable for only 1 scenario. I’ve also done a similar approach in modelling a service interface that is reusable.

    – Yes, I agree that not all company can revamp and move forward. I’ve been in organizations like that and it took me a lot of time convincing the team to drop the old habits at least for new developments.

    – Yes, for those without a middleware, RFC is a valid option. The scope of my blog was mainly usage of RFC in PI as there are other alternatives available.

    – Yes, I agree it can be an additional task if an RFC already exist, then to have to wrap it inside a proxy. We can go through the following logic to make the decision 🙂 (although I personally would prefer standardizing on a single type of integration protocol.)

    
      if(!RFC.exists()) {
       createProxy();
      } else {
       if(RFC.isBORFunctionModule()) {
        generateIDocALEwithBDBG();
       } else {
        exposeRFCasWebService();
       }
      }
    
    
    
    

    Rgds

    Eng Swee

    (0) 
  6. Dipen Pandya

    Hi Eng,

    Great & Encouraging blog.

    RFCs are still being used just because ABAPers find it easy to do, but now other options are also available to use.

    I completely agree with you.

    BR,

    Dipen.

    (0) 
  7. Steven De Saeger

    Great rant euh blog …

    The ‘irony’ ofcourse is that on a dual stack PI the mapping calls from ABAP towards JAVA are done using … RFC … 😛

    I second your thoughts that RFC should be avoided as much as possible within the context of SAP PI – especially for lookups – but let’s not forget that RFC technology on its own still merits a place within ABAP development – even within purely ABAP OO development …

    The usage of RFC within tRFC, qRFC, bgRFC and parallell execution remain unmatched so far …  and it still remains a good technology to connect non-SAP systems directly … it is even being used (again by SAP) as a possible connection within SAP Gateway.

    But your point about PI stands as a rock 🙂

    Steven

    (0) 
    1. Eng Swee Yeoh Post author

      Hi Steven

      Yes, I agree that RFC and all the related xRFC stuff would not have to worry about being chucked away in the near future in an ABAP environment – there’s still no OO replacement for invoking new tasks in parallel or background 🙁

      Thanks again for your comments.

      Rgds

      Eng Swee

      (0) 

Leave a Reply