Skip to Content

The main bottleneck of ABAP Proxies is the amount of custom coding that is required. Though we cannot get away with it I will try to organize the coding in a better fashion over here.

Though out of context here, I would like to put few of thoughts on most of the questions raised in forum posts while choosing ABAP proxies:

Lot of debating happens when the XI developers need to choose between RFC adapters or Idoc adapters or Proxies. I will try to propose a solution out of my little experience and I leave the decision to the readers what has to be chosen in their projects.

It is very clear that proxies comes into context only when WAS >= 6.2.But we can still use Idoc adapter or RFC adapter for communicating with SAP systems having WAS >=6.2!! That calls for a problem, as there are too many options. What is the best option out of it?

My Recommendations:
1.Use Idoc adapter if standard idoc is available to meet the business requirements.
2.Use RFC adapter if the data volume is less and there are standard BAPI’s available to achieve the functionality otherwise we face critical performance bottlenecks.
3.Best option is to use a proxy while handling large volumes and developing a custom business processes.

Coding Proxies in a better way:

ABAP Proxies in XI(Client Proxy) has to be read before understanding this as the idea presented here is an enhancement to the blog and same proxy object is used for demonstrating in a more understandable fashion.
The disadvantage of proxy is that it involves lot of custom coding and we need to educate the ABAPer’s to code the proxies. We can see that SAP NW is going towards Object Orientation but still we code traditional reports for executing every proxy.
Do I need to write 80 reports for executing 80 proxies and do I need to schedule 80 reports incase of client proxies? Can we design proxies in a smarter way? Yes. Check this sample code, which will take the proxy name and generates the proxy code automatically that triggers the client proxy.

Generic Template for triggering a client Proxy:

This report can be used to trigger any client proxy .All we need to do is to just feed the proxy name.In SE24, We have to write proxy/interface specific code for the object. Here we abstracted the triggering of proxies from application logic.

Screen dumps:

Create the report YPROXIES in se38 editor with the source code provided above. Fill the text elements as shown in the below figure.
Text Elements
Fill in the proxy class name details as shown below and press F8, which will trigger the proxy:
Exec generic Proxy
Application proxy logic is written in the proxy itself as depicted below:
App Proxie

To report this post you need to login first.

11 Comments

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

  1. Anonymous
    Hello Sravya,

    We took an entirely different approach to that proposed by you. We went proxies for 6.2+. From our experience I would strongly advice on using proxies versus RFC adapter. RFC adapter sounds easy , looks easy but comes with a heavy cost. More over the scenario will be so tightly coupled to the backend RFC (names,structures).
    With proxy we get a lot of control on defining the interface, better performance.

    Well that’s my thought…..

    cheers,
    Naveen

    (0) 
    1. Sravya Talanki Post author
      Yes Naveen.I agree…but simple info like fetching po details or update tables ..can be done through RFC or BAPI instead of doing lot of custom coding.

      Probably I partly agree to you.

      (0) 
  2. Krishnakumar Ramamoorthy
    Sravya

    I agree with your point for using proxies for sending data out of ECC(R/3) to XI and ofcourse it has proved itself on perfomance. But when it comes to data coming in to ECC, I prefer IDOCs instead of proxies for the simple reason that it is integrated (standard) with workflow. That way, when an IDOC fails because of application data or syntax, I can always trigger a workflow and use the notification procedure to send notifications. However, with proxies, I still have to code some custom stuff for error handling like sending alerts.
    Thanks
    KK

    (0) 
    1. Sravya Talanki Post author
      KK,

      This is something we cannot really debate on as everything has its own advantages and disadvantages.
      Say if you have a huge idoc that has to be transferred to ECC..ideal would be to use a proxy.

      (0) 
    1. Sikha Kayal
      Hi Sundar,
          I am also getting the same dump as mentioned by you Parameter OUTPUT not passed to the execute-asynchronous method.Can you please help me to solve te same.

      Regards
      Sikha

      (0) 
  3. Satinder Singh
    Dont you still think that even though when we code ABAP proxies, we still end up using some BAPI or iDoc only to execute the business logic, e.g. create sales order or update the system status etc.
    (0) 

Leave a Reply