Skip to Content

A Performance Analysis between point to point Web Service call Vs Brokered Web Service call via PI

We once had a requirement to integrate a 3rd party IVR system with SAP ECC. As a standard practice we approached the solution to be brokered , ie interfacing via SAP PI. The interfacing solution agreed upon was a synchronous webservice call. We would be exposing the web service and IVR would be consuming it. 

The performance requirement we had was 3 secs. That is the request-response cycle should complete within 3 seconds. This led us to consider a statistical analysis between the following cases:


  • Using PI-AAE -Proxy — Here we had exposed the Webservice out of PI, and IVR would Call PI webservice. PI will call ABAP proxy on the ECC end using Advance Adapter Engine’s local processing capability.
  • Direct ECC- RFC Webservice By-Passing PI — This case, an RFC was written on the ECC end and exposed directly out of ECC as WebService which IVR would Call.


We tested both the scenarios using SOAP UI and below is the statistics which we got. Whatever cases crossed the SLA of 3 secs is highlighted in yellow.




Summany of the analysis:




Looking at the above statistics, we find that Direct ECC calls performed better(but not significantly) than being routed through PI AAE. We tested with a small set of data, and having simplest coding, involving one select statement only.  However, with increase of data volume, and with further complex logics involved, this observation / ratio of response times might get changed. 

You must be Logged on to comment or reply to a post.
  • Dear Himadri,

    You did a very good piece of research work. Thanks for sharing it with us!

    During an earlier project implementation on SAP PI 7.0 we learned that using PI for brokering sync web service calls to proxies was a bad architectural choice due to the many handovers between ABAP and JAVA inside the PI stack: that pushed the average round trip time well above the tolerance level.

    It is very good to see that with PI 7.1 and its AAE it is now just a half second that PI adds on top of the round trip time.

    Taking this result one step further, 5/6ths of the time are now consumed on the ECC system to parse, execute and return the proxy call. That puts the optimization work into ECC. It is also what we found at the time: reviewing the select, update and create calls in the ABAP coding and tuning them for performance can bring a substantial speed increase for the overall solution.

    Did you by any chance run a load test against the scenario to see how queueing affects average round trip times if f.ex. 10 calls come in per second over a period of 10 minutes?

    Best regards,

    • Hello Stefan,

      No, We did not carry out further load testing on this.

      The point you mentioned is exactly what I wanted to bring out from this statistics — that the processing time gets split up between PI and ABAP .. and we find that PI added very little overhead. With the increase of message size, for a certain range(which might be wider than we think), we can expect PI’s fixed cost to be increasing in a lesser extent, than that compared to the overall processing time increase, thus bringing down the ratio even further.

      It would be interesting to see a throughput analysis on this.

    • Hi,

      if the java stack is set up correctly then PI in Integrated mode (only AAE), and without payload logging, should not ad more than 50-100 mS for small messages (and simple mapping). The rest of the time is normally used by network and ERP…

  • Hi,

    its intresting to look att this comparison but I think there is a big difference in the 2 test.

    In first test there is a PROXY being tested and in second case an RFC webservice.

    If running a PROXY then you are using the small XI/PI engine in ECC and is this has not been properly setup this could give unwanted latency.

    If you were able to test an integrated configuration SOAP – PI – RFC for small connections you could probably get higher performance.

    I have done similar tests where the SOAP – AAE – RFC connections have given me response times of under 200 mS for a RFC call towards customer lookup.
    A PROXY connection gave me longer response time for the same question.
    However… if the load is very high then PROXY would have the benifit that it is using the XI/PI engine and processing the request in queue (as normal ABAP PI would do).

    There is also the posibility to use the direct connection and still have the central hub of PI.

    • Interesting to learn that Proxy returned a better response time than RFC .. As you said this might be because of poor / not optimally setting up the Proxy(which is a local Engine running on ECC)

      So, are you suggesting that RFCs might be better for small/delta volumes – or in Production, we expect that with proper tuning and infrastructure, Proxies still hold the advantage?

        • You need to keep one thing in mind though: ECC systems have a limited pool of RFC connections.

          By moving high load scenarios from Proxy towards RFC calls you can cause a bottleneck situation here where (sync!!) RFC calls fail as they cannot claim a resource from the RFC pool.

          In bad cases that can force you to shutdown and restart the ABAP stack of both PI and the ECC system as retry mechanisms in PI can keep on blocking all available RFC connections. And in the meantime your sync RFC calls don’t get answered, hence mappings and/or service calls fail.

          So when looking at the setup, do not just take the higher performance of RFCs into account, but also the higher robustness when facing load of Proxy solutions.

          • True… thats why its not easy to say that there is just one correct answer.

            However, when it comes to RFC calls then PI is normally setup with max 5 RFC connections per java node, so with a standard dual java node system, PI should be able to use up to 10 RFC connections/dialogue processes. This is also depending on the settings in the CC.
            The rest is basis settings/tuning/sizing. So as I wrote, tuning and basis is important regardless of RFC or Proxy.

      • Hi,

        yes if we look what happens in ERP for the 2 differnt calls:

        PI calls the XI pipeline in ERP. Message is being placed in queue (SMQ2 and SMQ1) and then processed in queue order by the background scheduler. The processing is then Response is then returned to PI. This gives some overhead running small calls.
        For large nummer of calls or big messages this only uses the number of parallel threads assigned to the IE.

        When calling the RFC a dialogue process is directly used during the processing. For small calls the runtime is short and efficient but when dealing with very large messages or a big number of messages a shortage can be noticable in the dialogue processes.

        So there is not just one simple answer but if a large number of SOAP calls could be processed quicker by RFC the overall load should be lower.
        However the PROXY has the advantage that its probably better handling higher loads, but needs more constant tuning to be optimal…

  • Hi,

    we are running a very complex production confirmation scenario using(PI) proxy/soap, but that never took more then 3 sec.please mention business functionality or abap code at RFC/proxy.

    second thing is,(we have experienced) at the time of upgrade(SP/EHP) at ECC system if it is smooth if webservice consumed through PI,in case of direct consumption it is giving issues…