Skip to Content

Since the release of the AEX, I have been asked repeatedly by colleagues, acquaintances, and customers whether or not they should jump feet first into the new single stack offerings of SAP NetWeaver PI. Having worked with PI since the XI 3.0 days, I find myself struggling to let go of that dual-stack security blanket. In time, this decision will likely be made easier by SAP ripping the ABAP band-aid off of PI altogether. In the meantime though, here is a collection of thoughts I have on whether or not to migrate to a single stack architecture. These reflections are in no way meant to be taken as gospel, just the assorted musings of a developer and his experience working with the tool.

Limitations/Problems with the Current Java-Only Solution Architecture

On the surface, a single stack solution based on Java technology makes so much sense. After all, a dual stack solution consumes many hardware resources, is more complex to maintain/troubleshoot, message processing lags due to stack hopping, and so on. Plus, ABAP is not exactly great at dealing with Internet protocols, XML parsing, etc. The problem (as I see it) has always been that SAP has never had one single AS stack that was robust enough to provide everything a modern Enterprise Service Bus (ESB) requires. In particular, I see the following limitations on the Java side of the house:


  1. There’s no good way to say this, so I’m just going to come out and say it: the AS Java is not as robust and reliable as the AS ABAP. I love Java as a language and as a platform for building enterprise applications, but it’s really hard to beat the AS ABAP when it comes to having a rock solid platform to deploy applications on. It simply doesn’t die, no matter how many bad SELECT * statements lazy ABAPers throw at it. And while the AS Java continues to mature and become more reliable, I sleep better at night knowing my mission-critical transactions are flowing through the Integration Engine. It may bend under a heavy strain, but it rarely breaks. With the AS Java, I always feel like I’m a java.lang.OutOfMemoryError exception away from lying crippled on the side of the road.
  2. Though it is possible to tune JVMs and build large clusters of AS Java server nodes, the reality is that most PI projects I have been a part of have struggled with AS Java performance. Of particular concern are large spikes in message volumes and/or large messages coming through the pipe.
  3. The Java-based runtime environments are not very transparent and difficult to trace. Though the monitoring tools in PI 7.3x have gone a long way towards leveling the playing field, I still think they trail behind what has been established over in the IE. There, I can suspend qRFC queues, set breakpoints within pipeline services and get to the bottom of the most complex of problems with ease. Conversely, if a message gets hung in the AEX, it can be difficult to get to the source of the problem with the current set of tools available.
  4. To me, one of the biggest things that has always set PI apart from other EAI tools is its robust ABAP-based IDoc adapter. While all of the other competing vendors have struggled to keep JCo-based IDoc adapters up and running, PI has always provided excellent support for IDocs. Not to mention all of the extra bells and whistles such as qRFC support, packaging, and so on. JCo, in my opinion, is a fairly leaky vessel and not one I want to trust for delivering important messages to/from ECC systems.
  5. The Java logistics infrastructure is a still kind of a mess. These days, integration content is scattered across the ESR (accessed either directly or indirectly via the NWDS) and the NWDI (particularly for BPM content). Though CTS+ is simplifying the way that these disparate content types are promoted across the landscape, this is a lot to consume for novice Java-based integration developers new to SAP.
  6. Lastly, it is difficult to find good PI admins who really know their way around the AS Java. Over the years, I’ve often had to wear the Basis hat on PI projects, knowing that I was on my own if there was a Java issue that cropped up. Here, if worst came to worst, I usually had the option of refactoring my integration scenario to utilize ABAP components so that I could get the support I needed. Once the dual-stack plug is pulled, it’s sink or swim.

The Verdict?

For now, it is this developer’s humble opinion that customers running mission critical integration scenarios should stick with the dual-stack architecture as long as they can with a few caveats:

  • Developers should make a conscientious effort to utilize AEX-based features as often as they can. For example, if a scenario does not require features of the AS ABAP, it should be packaged up in an integrated configuration and deployed on the AEX.
  • PI Developers and Basis admins alike should brace themselves for a future which doesn’t include the AS ABAP. They should explore the features of the AEX, Process Orchestration, and so on.
  • Any new solutions requiring Integration Processes should be considered long and hard as they are not compatible with the Java-based BPM functionality. Suffice it to say if BPM is a big part of your PI footprint, then some serious thought should be given towards the future of Process Orchestration.
  • Integration architects should continue to nudge developers towards the use of SOA-based designs utilizing enterprise services where they make sense as opposed to older legacy technologies such as IDocs and RFCs. Not only is this a best practice, but it also reduces reliance on shaky JCo-based technologies.
  • Middleware teams should take begin putting together maintenance/monitoring plans which utilize the new SolMan/NWA/PI Java-based toolsets. This will make it easier to migrate over to the single stack solutions down the road.

For now, the dual stack solution provides developers with the best tool coverage available. So, unless your server admins are desperate to re-coup server resources, I see no reason why you would want to give that up as a developer – for now. Hopefully a couple of years from now, this will be a slam dunk case and we’ll all laugh at why SAP ever had a dual stack architecture to begin with.

To report this post you need to login first.

7 Comments

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

  1. Nabendu Sen

    Hi James,

    Thanks for this article with so many details. As a developer starting career with XI3.0, I also feel lots of missing parts of ABAP stack in current Java Stack installation. But the question is, do we want to see SAP PI as an independent Integration Platform in Middleware Solutioning or still a tool which can best integrate SAP systems with Non SAPs. I have seen very closely Integration Market leaders like Web Methods or Tibco which mainly work in Java platform, still I can say we are 2 step behind of them. I know ABAP stack had lot of parts which were more stable and more straight forward than implementing in Java, but this is the right time that SAP wants their Middleware Solutions in open market. Still lot of clients think PI as a subpart of ERP/ R3 development and to couple of them “its a preferred skill over R3 Development”. All gaps and incapability of PI needs to be addressed by SAP as soon as possible, thinking about the future of EAI Framework.

    (0) 
  2. Carlos Ivan Prieto Rubio

    Thank you for creating a interesting thread about PI instalation options.

    I don’t agree with you, as Nabendu said, the best Middleware solutions in the market runs on Java arquitecture.

    Java stack is an open solution, better performance, BPM, NWDS is better than old designers tools. For business solutions SAP Web AS ABAP is the best choice, as integration platform it’s not the suitable platform.

    I think SAP takes the right direction for drives this platform.

    In my opinion SAP lost many time investment in double stack when the right choise would be to invest in Java Stack.

    I still waiting for message brokers capabilities in next versions for high volumen scenarios.

    Best regards

    Iván

    (0) 
    1. James Wood Post author

      I think in some ways we’re saying the same things. I love Java as a language and agree it’s the right choice in the long term. After all, it was built from the ground up to support Internet technologies, XML parsing etc. whereas ABAP wasn’t. So, it’s a natural fit for building an EAI tool.

      The problem I see is not so much the language as it is the platform it runs on. Quite frankly, I’ve seen the AS Java crash too often for me to trust it as a standalone platform for delivering mission-critical messages through the enterprise; I wish I could say otherwise but it’s simply the truth. I guess my point is that there is still a lot of work that needs to be done to bring a Java-only PI solution up to par with some of the other leading EAI tools on the market. If PI is Java-only, then what sets it apart from these other products? I just think SAP has to be careful not to take too many steps backwards in order to take steps forward.

      (0) 
  3. Martin English

    I worked on an NW04s rampup in 2006 or 2007, and there is very little difference in the support tools available on those Java stacks and the Java Stack in the Process Orchestration 7.31 systems that I have just gone live with. Yes, you can see more static information in the NWA, but the Visual Administrator has gone. All in all, from a BASIS perspective, it’s probably a nett loss in functionality.

    As a BASIS guy, the key components of any implementation are the support and monitoring tools. While they are (to some extent) available via the NWA for Java stacks (or PIMONITOR for Process Orchestration), they are still not as reliable and detailed as the  ones available for ABAP stacks. After what ? six or seven years ?

    I mean, I love playing with HANA, River / NEO / Netweaver in the Cloud / whatever it’s called when you read this, or SAP on AWS etc, but can we get just a little bit of love for the customers who currently (and will continue to) contribute the majority of the bottom line ?

    hth

    (0) 
    1. Basis-SAA Team

      Please can you answer my Question.. We are on Sap PI 7.1 Ehp1 and need to upgrade due to an ehp7 upgrade.. We were told we had to be on releases 7.3 or later . Can we upgrade straight from  Sap PI 7.1 Ehp1 Dual stack to Sap PI 7.4 dual stack PO or or can we just upgrade straight to Sap PI 7.4 dual stack and will evrythign be okey Many thanks

      (0) 

Leave a Reply