SAP started with message interfacing back in R2 using the IDoc framework, which was later renamed to ALE (Application Link Enabling). The IDoc exchange was a predecessor for what is now known as message brokers. The IDoc and ALE did have a number of remarkable features:

  • IDocs have binary format and therefore are very compact in size.
  • IDocs are structured documents of which the structure can be created and/or enhanced by the user.
  • IDocs contain information on the sender and the recipient
  • IDoc processing status in the sender system can extend up to the processing status of the same IDoc in the receiving system

With todays message brokers and XML structured documents features as routing information or end-to-end processing status are not part of the message, but need to be implemented in the broker. On the other hand, the modern message brokers are far more flexible in routing, translating or even merging messages from source to destination.


SAP started with XI 2.0 as a system integration platform based on the Java Messaging Standard (JMS). It used many features of the ABAP engine to create the first message broker. Because the JMS was adhered, java became a second part of the XI middleware. The ABAP stack delivered system functionality such as queuing, logging, specific communication, monitoring and workflow.


SAP found that most competitors were positioning there brokers as process integrators, allowing customers to build automated processes on top of message exchange. SAP therefore renamed XI to PI (Process Integration) and elaborated the ccPBM functionality. ccBPM was a JAVA layer on top of the ABAP workflow, making the workflow message oriented instead of task oriented. Unfortunately combining the two virtual machines (ABAP and JAVA) results in performance degradation, whenever data needs to be exchanged between ABAP memory and JAVA memory. Therefore the third iteration of SAP's message broker was a version where a lot of functionality used from the ABAP stack got rebuild into the JAVA stack. This was called Advanced Adapter Engine (AAE) and AAE-Extended.


The AAE is the JAVA only part of PI and became quickly very popular with the customers. A Java only message broker was easier to maintain, the performance in message troughput was much better and the requirements on CPU and memory and database IO were lower. The disadvantage however was the loss of ccBPM. To compensate for this loss, customers still have the option of using a double stack PI system, using the JAVA only part (AAE). But for the messages requiring ccBPM the double stack can be used. SAP is also offering a second solution, that is purchase a JAVA workflow solution (Orchestra) from a third party vendor which integrates nicely into the AAE environment. This is where the last name comes from, SAP PO which stands for PI Orchestra.