Skip to Content

Often we come across the dilemma of which adapater should I use while integrating with SAP systems. Will try and discuss on the options available and what could be some of the points that one should consider before you zero in one of the adapters. If you see the list of Adapters given by SAP, a quick seggregation can be done depending on the type of systems that these adapters are going to communicate with. Now, one of the obvious systems with which XI is going to communicate will the SAP systems (SAP R/3 – 4.6C, 4.7, ECC 5.0, CRM, SRM etc etc). Now these systems could be on the sending side or on the receiving side or could be on both sides where R/3 is integrating with SRM / CRM …. or vice versa. So, what are the options that SAP gives us to communicate with SAP systems. 1. IDOC Adapter 2. RFC Adapter 3. Proxy Now, how do you choose the right one for a given scenario. One of the things that SAP strongly suggests is the usage of PROXIES. Now, if you take a close look at the adapters specified here, the one thing that strikes right away is the usage of proxies. We know that proxy generation is possible only if your WAS is >= 6.20. So, that is one parameter that comes up straight away for the usage of proxies. — Use Proxies only if the WAS version is >= 6.20. We will also look into other reasons where we should go for a proxy. Let’s take a case and discuss the same. The immediate question that probably you are getting is : I am on WAS 6.2 or higher and also at the same time either I have a standard BAPI / Remote enable function module for the given functionality on the application system. So, what should I do now? In this case, there are 2 ways in which the implementation can happen. 1. Configure a RFC Adapter and call the BAPI / RFC. However the potential problem that I could see is that the RFC adapter existing on the Java stack communciating with the BAPI existing on the SAP application system. 2. The second option that I have got is to write a proxy on the SAP application system (which will be called by XI) and internally the proxy will call the BAPI. At this point of time if your question is, as long as I am dealing with the latest versions of SAP systems, should I totally avoid using RFC Adapters – MY TAKE on this would be, YES. Do NOT use RFC Adapter, rather go ahead and use the proxy. However, the problem could be that the pre-built meta data and the mapping that SAP delivers might not be useful as the BAPI is wrapped with a PROXY now. But as the proxy is also expected to have the same message interface as that of the BAPI, we might still be able use the pre-defined mapping. This is something that we need to try out and then decide how do I go about this interface. But for whatever reasons, if you are not getting advantage of the pre-defined integration content, PROXY is the way to go. Now, if you are dealing with SAP systems < 6.20, we do NOT have choice of PROXY anyway, so go ahead and use a RFC adapter. Now, as far as the IDOC adapter is concerned I think the choice would be straight forward. Where ever there is a standard IDOC given by SAP (usually mapping also will be delivered for SRM / CRM system integrations), so go ahead and use the same. The questions that you might be having now is that for a standard object if I have an IDOC as well as a BAPI, which one do I go for. My opinion would be its going to be dependent on the specific scenario that you are trying to develop. We can think of multiple variations of design for this case. For Exapme
1. Send one IDOC at a time.
2. Club multiple IDOCS and send as a single IDOC.
3. Make one single RFC call, for each business transaction.
4. Avoid making multiple calls to the same BAPI / RFC, rather have a wrapper BAPI and send all the records in one time.
5. Use the PROXY and send all the data in one shot and make single calls to the BAPI from the PROXY on the application system – only if you can use PROXIES.
The biggest advantage of the proxy is that it always by passes the Adapter Engine and will directly interact with the application system and Integration engine – so it will and should give us a better performance. So, there are the choices that you have while designing a SAP interface, so take a close look at the interface and identify your priorities for the interfaces. The parameteres could be some thing like PERFORMANCE, ERROR LOG, AUDIT LOG, MONITORING OF THE TRANSACTIONS INDIVIDUALLY. Do a comparison of the pros and cons of the choice of adapters that you have for the parameters for the specific interface and then make a call. Initially, it might look alike – what’s the big deal, its a simple case of sending / receiving data from SAP – especially if you are coming from R/3 world, but bellive me, you have got good chances of landing up in trouble, if you don’t take care of your priorities of the interface.

To report this post you need to login first.


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

  1. Bernd Eckenfels
    Personally I would avoid coding as far as possible (from the customer side), so the Proxies are harder to use in this scenario.

    I am also not sure how the quality of service for the proxy engine looks like, do you have experiences with long time usage?


    1. Ravikumar Allampallam Post author

      I agree with you that “Avoiding Coding” – can be another point while designing the interfaces.

      Just for the purpose of discussion, as there will be a SAP technical team which will be managing that specific application system, we could as well ask them to write the PROXY. However, the questions of ownership might arise.

      We have not seen PROXIES for a long duration, however for whatever we have seen in past 1 year, we have not seen any issues.


    2. RA Eijpe
      Avoid coding is the best way for customers, but not always possible. When a BAPI uses a separate BAPI_COMMIT call, you can not handle this without avoiding code. You now have the possibility to wrap the bapi in a new RFC or to use a proxy. I agree that proxy is the best way. Even if you use a bapi of a WAS <= 6.20. In this case you can use a proxy against the XI machine it selves and use the abap statement call function … destination … to the old system.
  2. Anonymous

    IDOCs, according to me, are the best way to go for asynchronous communication. IDOCs come with rich logging, error handling and workflow integration in the back end R/3 system. Best thing, all BAPIs could be converted to IDOC interface using the BAPI/ALE generator.

    Proxies could be great way to go for synchronous communication where you have a request response cycle but for async. communications, nothing can beat IDOCs. Most cases, business transactions fail because of incorrect master or transaction data. Its always a better practise to have error handling done in the R/3 backend system, where business users will have access, rather than doing the error handling in XI.

    What do you think?

    1. Ravikumar Allampallam Post author

      I agree with you. However, with new business process and new solutions coming up all the time we might not find a IDOC in all cases. In those cases consultants are tempted to write a RFC and use that rather than using PROXY. In fact I have see projects where the design is in such a way that the RFC is being call with in the BPM loop. So, what they could have done is atleast write a rapper RFC and make a single call. Anyways, that’s my opinion.

      You have raised an excellent point of validating the data in R/3. This is another bad practice that I have seen in projects, that for some reason there is lot of validation dumped on the middleware systems and then they complain about bad performance of the interface. Customers should understand that there are specific tasks that has to be done by the application system also in the integration process.

      Another point that I would across in case of file interfaces is that while you are designing the format of the files, design it in such a fashion that the validations can be done and load can be decreased.

      I would like to know everyone else’s ideas on the same.


  3. Anonymous
    Ravi –
    One other quick note. Most of us make this mistake and don’t realize unless someone points it out. There are a couple of mis-spelt words in your blog. I know the SDN team is working very hard in maintaining the quality of weblogs but its our responsibility to make sure such trivial mistakes don’t mar the content.
    It’s just a suggestion and I personally don’t mind this as long as the content is interesting 🙂
  4. Ruben Rivas
    Your article is very interesting, your proposal has been supported with interesting arguments.

    In your article you mention that “SAP strongly suggests is the usage of PROXIES”, do you have any the reference where they say that or if you have any additional reference that help me along these lines, I really will appreciate a lot.




Leave a Reply