Skip to Content

Let’s Talk PI… AAE – Advanced Adapter Engine or the “Answer to Accelerated Execution” – You Decide!

It is not uncommon for customers who have a middleware solution deployed in their landscape to periodically ask “How can we accelerate message processing and improve message throughput in our middleware solution?”. For SAP NetWeaver Process Integration customers, the answer is clear: AAE – Advanced Adapter Engine or you might say the “Answer to Accelerated Execution”.

Starting with SAP NetWeaver Process Integration 7.1, the Advanced Adapter Engine was introduced where “local” message processing can now take place. Why “local”? Because common mediation services such as routing and mapping are locally provided in the Advanced Adapter Engine. That translates into significant gains in performance and message throughput. As a bonus, the configuration process is much more simplified – with the new Integrated Configuration Object, all configuration is completed in one place. To many this is old news. Yet there are still many customers who are hestitant to take full advantage of AAE.


Let’s Talk About It!

At SAP TechEd 2009 come join us at the Expert Networking Lounge (Phoenix, Vienna) where we can take a look “under the hood” of PI and AAE and have an interactive discussion of why you must take advantage of the Advanced Adapter Engine.

You must be Logged on to comment or reply to a post.
  • I am not sure of my Vienna plans at this point but I am a reluctant user of this feature – why?

    1. Customers I have worked with have like PI for 1 reason – We log everything – SXMB_MONI, RWB, Visual Admin, and these logs help when things go bad or as a proof that the middleware was OK.

    2. Normally Issues on Middle Ware is almost always raised weeks after the issue might have occured. Example PO sent out from SAP but no PO response / ASN is detected couple of weeks after the Original PO might or might not have been sent. At these times these logs are helpful.

    3. Using AAE takes away this advantage. Infact logging is minimal and that is where the real performance benefits come from and hence in most of the cases, customers would pump in more CPU / Application Instances / DeCentral AE’s rather than loose these logs. If local processing is available, then so should the logs – Let me see my inbound payload and outbound payload in AAE logs from RWB and then I will be convinced.

    Any takers on my side?
    Would be a interesting session! All the best!

    PS : These comments are on the basis of working on PI 7.1 6 months ago.

    • Hello Bhavesh –

      Your viewpoint is appreciated and you do bring up some valid concerns.  However, I definitely have to disagree with and clarify some points that you have made.

      1.  Hopefully, logging isn’t the ONLY reason why your customers like PI 😉  From an adapter engine standpoint, logging still takes place – RWB message monitoring and audit logs are available as usual.  Of the ones you list, SXMB_MONI obviously is not available, but the rest (or it’s equivalent) are.  When you need to troubleshoot, the logging and the “proof” is there.

      2.  In the example you gave, the AAE message logs would be available to prove that the PO was sent.

      3.  Using AAE does not take this advantage away.  The fact is that logging, in and of itself, is not where all “the real performance benefits” come from, though I do agree that overall less logging (relative to classical processing), and thus less persistence steps, is one of key areas where performance gains are made.  You can still see the soap xi message and payload in the RWB. Currently, the main restriction to logging is the availability of the payload after mapping – give you that.  But besides that, the necessary logging is there.

      As the point of this blog is to draw attendees to this session and have an interactive discussion on-site, I don’t want continue this here. Your comments here are really appreciated and hopefully you’ll be able to attend the session in Vienna (or Phoenix, where I’ll be) where we can talk more about it.


  • I am fully agree with above comment, logs are must have requirement in most of the case , thats the reason we can not use AAE feature… , need to do some other thing to make the process fast (other than not logging).
    • Yes, I agree that logs are a must have requirement which is definitely why logging in the AAE does in fact take place.  But to say that processing was made faster because of “not logging” really misses the point.
  • Though AAE boasts of performance improvements, i observed few drawbacks with this feature

    1. Logging information is not detailed when compared to SXI_MONITOR or other transactions

    2. If the message fails to deliver at the target during local processing then the entire message processing starts from scratch which means even the mapping would be re-executed which wont be the case with our traditional approach.

    • 1.  Logging information is pretty detailed in the RWB audit logs also.  But perhaps you can briefly clarify what is lacking?
      2.  Good observation. This is true. Harmless in terms of message processing, but it is redundant/inefficient processing in error cases. But pretty sure this also is tied to not persisting after mapping.