Imagine – Life without the ABAP stack
2008 – Advanced Adapter Engine and the local processing makes waves… for the first time, the message processing will bypass the ABAP stack
2009 – EHP1 – The AAE gets more features
2010 – Unleash 7.3. SAP mentions an optional Java only release of PI. Advanced Adapter Engine finds itself in a new breed… the Advanced Adapter Engine Extended aka AEX.
Well we should have known it was coming…. the future… Death of the ABAP engine and the birth of Java only SAP PI releases.
I think it is the inevitable as SAP moves to a Java only future and slowly coming out of the dual stack idea we have all come to live with. There has been strong messages at TechEds around the world about this. It might not be the immediate future but then there sure seems to be action happening in the labs which will be realized soon.
The advantages with a single stack approach seem to be in plenty – Faster installation, better performance, lesser cost, reduced resource consumption, lesser hardware, faster restart and many more.
So how different would it be if we didn’t have the ABAP stack anymore?
1. ABAP stack based adapter – None in the future. With 7.3, all the ABAP stack based adapters will move to Java stack. ex. HTTP_AAE and IDOC_AAE
2. ccBPM – This is a huge impact on the future of PI. ccBPM is completely based on the ABAP stack and integrated into the SAP Business workflow engine. With the ABAP stack gone, ccBPM would soon cease to exist.
From the brief conversations I had with SAP during the TechEd, ccBPM is being planned to be replaced with BPMN standard (Business Process Management Initiative). In short, the SAP BPM will find itself being plugged into PI where modeling can happen based on the BPMN standards.
The problem that I can foresee here is the upgrades from a lower version of PI to the future PI. If SAP doesnt provide an upgrade path for moving ccBPM instances onto the BPMN based modeling, then there is going to be a lot of remodeling on existing interfaces developed in PI as part of any migration or upgrade.
PS: Does this now mean we have to think twice about the usage of ccBPM in the near future?
3. ABAP Mapping – We will see is the diminishing usage of ABAP mappings. It is time organizations looked at the mapping techniques being currently used in their PI implementation. Its better to discourage the use of ABAP mappings and encourage mappings to be developed more on the graphical or java model.
PS: No more ABAP mapping ??? Well, I know this might offend a lot of ABAP mapping fans. I am a huge fan of ABAP but never was a fan of the ABAP mapping in PI… maybe I was never comfortable with ABAP mapping… my bad.. my incompetence ..
4. What about all my ABAP stack configurations? – This is something interesting. This is where all the ABAP stack configuration might have to be moved to the Java stack. Or would there be a different way to configure interfaces now? What about my destinations, what about my ports and meta-data, no more SXMB_MONI for sure and how will I do my integration engine configurations? What happens to all the TCODEs I memorized?
5. Tables and lookups – With the ABAP stack being moved, one thing that most of us would definitely miss is the use of custom ABAP tables that might have been introduced as part of interface designs to hold data (ex. for lookups). With no more ABAP, it will be required that PI (Java) DB been exposed so that developers can create custom tables and using JDBC lookup or calls handle data (will miss the PI ABAP RFC lookups). Another option would be to have a dedicated DB or use the ECC ABAP tables for storing such data.
PS: Personally I believe PI should have its DB exposed so that custom activities can be carried out. Why depend on another system for our data, isnt it?
Well, what else do you think? How do you envision the future? What will you miss if there was no ABAP stack?