Skip to Content

When talking to our customers at various occasions, we frequently get the feedback that they actually would like to move from their PI dual-stack installation towards Java-only to benefit from the latest improvements we have done with respect to TCO (Total Cost of Ownership/Total Cost of Operations) and TCD (Total Cost of Development) reduction:

  • Lower hardware resources needed
  • Better performance in terms of throughput and response time
  • Design time, configuration, and process modeling in Eclipse
  • New graphical configuration approach via so called Integration Flows
  • More flexible modeling options for integration centric processes due to BPMN usage
  • Business Rules capabilities
  • Human tasks in integration processes

However, they are often unsure about what installation option would meet their respective requirements, and what target release they should go for. Questions arise such as: Can they already go ahead, do they have to wait and stick to dual-stack, would an AEX installation be sufficient, or would they have to move to the latest Process Orchestration bundle, etc?

For an overview of which installation options we do support, please take a look at my blog. It provides you with a high level overview of the main characteristics and use cases for each installation option. However, it does not go into the capabilities in detail. Knowing the features coverage of the Java-only installation options for the area of Process Integration and Orchestration would definitely help you in answering the questions above, i.e., what features are supported as of which release and what are the gaps compared to the dual-stack.

This information is actually available with the release notes that SAP provides, however spread across multiple pages in the SAP standard documentation. I have gone through the painful process to consolidate all PI release notes starting with release 7.10, and have prepared the information in a way that you can compare the different installation types per release and latest service pack, respectively. You’ll find this information here:

PI Release Notes Consolidated – Features Comparison

Please note that for most categories the feature list is not complete, this is done intentionally, it only reflects the features where the installation types differ. Listing all features that are supported in general would have kept me busy for the rest of the year :-), and would not add any value here. Furthermore, I would like to add that it only contains the information that I digged out of the release notes, so I do assume no responsibility for any omission.

A couple of tips when working with the comparison document:

  • I do compare the latest SP of releases 7.10, EhP1 of 7.10 (7.11), 7.30, and EhP1 of 7.30 (7.31), except for the Integration Flows. Since this feature has been introduced with 7.31 only, and we have invested quite a lot in SP4, I explicitly distinguish between SP2 and SP4 of release 7.31.
  • Rating: It’s quite self-explanatory that green icon means fully supported, yellow not fully supported, and red not supported at all. You will find this information and others also on the Legend page.

          01Rating.png             

  • The PI dual-stack (DS) consists of the Integration Server (ABAP) and the Adapter Engine (Java). Each stack gets its own rating. The Sum column reflects the aggregated rating for the complete dual-stack.

          01DS.png

  • When reading the Directory and Runtime ratings, note that for the Advanced Adapter Engine (AAE), the AEX, and the PO the ratings refer to capabilities of the Integrated Configuration Object (ICO), whereas for PI DS they refer to the classical configuration objects (i.e., sender agreement, receiver determination, interface determination, receiver agreement).
  • Sometimes the cells contain n/a. In most cases this could mean that the respective feature depends on another feature which is not supported yet. For instance, the newversion of the Directory API is not supported for release 7.10, so all objects below are rated as n/a.

               04DirAPI.png

  • For Business Process Management (BPM) capabilities, the comparison is based on Enterprise Integration Patterns. For an overview about the patterns, please refer to the book “Enterprise Integration Patterns” by Gregor Hohpe & Bobby Woolf, Addison-Wesley Professional, 2004. Beside other characteristics, the patterns can be distinguished between stateless and stateful mode. For former, the patterns can be either implemented via the messaging system of PI or modeled via BPM. For this reason, the stateless patterns are rated green on the AEX although it does not come with any BPM capabilities. In the example in figure below, you can see that the Splitter pattern is supported on the AEX, i.e., by running a one-to-many mapping in the messaging system. This is also supported on the PO. In addition, you can model and run the Splitter pattern on the BPM engine of PO. If you like to get more details about how specific patterns can be implemented on the PO, please refer to the blog about Enterprise Integration Patterns for Process Orchestration.

          05BPM.png

I hope this information helps you in making the right decision when considering an upgrade or migration of your PI landscape. In case of questions do not hesitate to comment on this blog or directly send me an email.

To report this post you need to login first.

13 Comments

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

  1. Fred Verheul

    Hi Alexander,

    I’m sure it must have been painful to bring all this information together (maybe that says something about the standard documentation made available??), but I’m sure it adds lots of value to customers. Thanks for sharing!

    Cheers, Fred

    (0) 
  2. Alexander Bundschuh Post author

    Hi all,

    just to let you know that I have just updated the comparison document. There was a mistake with respect to ABAP mapping support on the Java-only installation types AEX and PO. Other than previously and wrongly stated it is not supported which is pretty obvious. Thanks to the teched participant who pointed to the mistake.

    Alex

    (0) 
  3. Alexander Bundschuh Post author

    Hi all,

    yet another update of the comparison document.

    Major change with respect to the communication with non-SAP backends via IDoc. JCo 2.1 is out of maintenance since April this year. So, it is recommended to migrate to JCo 3.0. Communication with non-SAP backends via JCo 3.0 standalone will be supported as of JCo 3.0.10.

    Alex

    (0) 
  4. Markus Schalk

    Hi Alex,

    absolutely great overview you provided to us. Keep on going, it’s very helpful preparing the migration to PO.

    Best regards,

    Markus

    (0) 

Leave a Reply