Skip to Content
Author's profile photo Shabarish V Nair

Imagine – Life without the ABAP stack

The Signs

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?

Assigned Tags

      21 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hello,

      first of all, I'm an ABAPer. That the only programming language I really know by heart.
      My fault - okay.

      For what I know ABAP has some good features which are not or partailly known in other programming languages: 
      + internal tables
      + n returning parameters
      + built-in grabage collector
      + MVC-framework for UI  (WD4A)

      , but at the end the programming language doesn't matter. Solution does!

      All the best,

      Guido

      P. S.: In BI-Integrated Planning they are moving from Java towards ABAP.

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar
      Blog Post Author
      from a PI perspective, somehow it does makes sense to go a single stack way (at least from what SAP has been projecting....)

      ABAP is definitely a powerful language but as you said, in this case its the solution that matters and not the prog. lang.

      Thanks for the comment,
      Shabz

      Author's profile photo Former Member
      Former Member
      hey

      Was surprised to c this. all that you listed is available in other languages.

      Java has all of them so does C#.

      Garbage collection exists in Java from 1995.
      n returning parameters are arrays/collection in java.
      Internal tables are array of classic java beans or array of getter setter classes in Java.

      MVC is not there in WebDynpro ABAP. true MVC can be implemented using Java or ASP. For real information on MVC check the open source group. Thats the real standard.

      Simple way to find if you are using MVC or not is to see if controllers in your components control the view flow. In case of WebDynpro it is application be it on Java or ABAP. So true MVC is quite different.

      But what you said is correct, langauges dont matter the solution does as long as languages are on par.

      Regards

      LNV

      Author's profile photo Former Member
      Former Member
      Hello LNV,

      just concerning MVC:

      Accorded to Wikipedia MVC is a archtectional pattern which separates domain logic from UI.

      Pattern can be implemented in different ways towards different enviroment. I personally don't see that can be a "standard" on implementing this.

      For WD4A is SAP UI framework to implement this architectional pattern MVC.

      So yes, you are right you can do selects and pure
      business logic in UI layer in WD4A.
      So no, you are not right you can separate UI from Business logic by using WD4A.
      At the end you are as archtiect and developer are responsible to using the given framework in order to implement a MVC-driven UI.

      All the the,

      Guido

      reference:
      Model-View-Controlle
      http://en.wikipedia.org/wiki/Model-view-controller
      WD4A
      http://help.sap.com/saphelp_nw70ehp2/helpdata/en/7c/3545415ea6f523e10000000a155106/frameset.htm

      By using the BUS-Framework for classic GUI is helping you to implement MVC-based application there.

      Author's profile photo Former Member
      Former Member
      Hello LNV,

      maybe we can write an arcticle/blog on the comparsion on different programming languages?

      All the best,

      Guido

      Author's profile photo Former Member
      Former Member
      If you are using java based integration solution, it doesn't mean you can't call ABAP code. There can be alternative to do so. RFC, for instance, can be called from any Java program. Similarly a ABAP mapping/ABAP code can be called from any other system. SAP is still looking for an alternative solution so that you can call it in your java based integration tool. But presently it is not available ( in PI 7.3).
      Author's profile photo Former Member
      Former Member
      Is ABAP2Java and Java2ABAP done by JCo or XML-based messaging?

      All the best,

      Guido

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar
      Blog Post Author
      why would you want to write your mapping in a different system and execute it via RFC or any other  alternative? Na.... doesnt make sense and I wouldnt use it 🙂
      Author's profile photo Vijayashankar Konam
      Vijayashankar Konam
      Farooq,
      All that SAP is looking forward to is to eliminate context switching between stacks. By calling RFCs from Java, again, defeats the single stack solution itself.

      Regards,
      Vijay

      Author's profile photo Former Member
      Former Member
      It is extremely simple to do the same. JDBC is not the only option. PI 7.3 will run on JEE5 and lookup of tables is cake walk. Simple drag and drop if you use the right editor.

      Entities and data sources are great idea to make  highly configurable lookups that can even change source DB on the fly!!

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar
      Blog Post Author
      what i meant is the traditional use of PI ABAP tables for lookups and temp data storage will be missed 🙂

      never said it is an issue....

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar
      Blog Post Author
      thanks for the view into the JEE5 world and data sources.... sounds more optimized and rich in performance
      Author's profile photo Former Member
      Former Member
      At last it seems that SAP recognizes now that Dual stack systems were an awful error. It is a waste of hardware ressources and an administration nightmare.

      The right solution is to use the right stack for the right job : ABAP stack for the business applications (ERP, SRM, CRM, etc..) and Java stack for utilities like PI.

      Olivier

      Author's profile photo Holger Stumm
      Holger Stumm
      I think this was a bad design move. SAP should have trashed the pointless Java implementation towards already functioning technology.
      I hoped that JAVA was gone together with Shai - or is anyone up to paying fees to Oracle?

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar
      Blog Post Author
      nice to see the conversations getting interesting 🙂
      Author's profile photo Vijayashankar Konam
      Vijayashankar Konam
      I don't think SAP has to pay any royalty to Oracle for using Java. Java is available free to use (the compiler). SAP has created its own web server based on java 1.4 (NW 7.0)and java 1.5 (NW 7.1). That is proprietary of SAP. However, SAP or anyone else other than SUN could change the Java compiler bahaviour/design as that is the property of Oracle.

      Regads,
      Vijay

      Author's profile photo Former Member
      Former Member
      Oracle's SUN gets Eclipsed with IBM and one can prepare for the event. now, going back to my smoke and mirrors...

      @greg_not_so

      Author's profile photo Former Member
      Former Member
      Hello Shabarish,

      Nice to see a very interesting blog from you and the interest it has created within the community.

      From my stand point, this was long over due. From the begining i felt it was point less to be doing the call switching between the ABAP stack and Java Stack. It made sense to use ABAP stack given that it was SAP's forte in the begining. So based on the following i feel this is a very good move

      1. Total Cost of Ownership : Maintaining a high avaliable dual landscape has been a pain

      2. Faster Upgrades : With this move i am exicited that PI uprades can be done within few hours and the there will be many resources who are aware of the Java stack

      3. Performance on Steroids : With just one stack now i am sure we can now match<10MS response times. Currently the best response time one can get with synchronous calls is around 200MS

      4. Loose the good old SAP work flow: ccBPM is rock solid but is so complicated that it is avoided by the masses. ccBPM is based on SAP's workflow. Netweaver BPM will elliminate this issue given how easy it is to use it.

      5. Language Advancements: Given the rate of advances going on in the Java world and given the millions of contributers for Java, it will be very hard for SAP to put in the same kind of innovation into the language that supports PI. Netweaver BPm implementation is a very good example of the power to be harnessed from the Java Community

      6. JMS Topics and future : PI for long time has always been based of Hub and Spoke design, and in the recent years a push has been made towards an ESB architecture. THis cannot be completed till PI supports topics based subsription versus receiver determination. TOpics make it easy to get messages with very little configuration or work time.

      I hope Project Caffeine, where the goal is to compile ABAP to JAVA comes to main stream as there are a lot of us who used the power of ABAP mapping and other ABAP stack related fucntionality.

      I hope a sidecar start will not be the only option provided by SAP to towards the new PI7.3

      Regards,
      Naveen

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar
      Blog Post Author
      thanks for the note Naveen.

      Hope my post doesnt trigger a Java vs ABAP war again 🙂 The idea was to inform the community of the future vision on SAP w.r.t. PI and access their views.

      I personally believe this is a definite and powerful move ahead given the advantages that can be reaped.

      Author's profile photo Srini Tanikella
      Srini Tanikella
      Nice Blog Shabarish! I have posted a link to this in ASUG.com. I think SAP has done a reasonably good job in communicating this - I definitely remember this coming up at TechEd in 2009 & 2010 and it seems to be a sensible move.

      Thanks,
      Srini

      Author's profile photo Alessandro Guarneri
      Alessandro Guarneri
      This is just to be considered as normal evolution.

      Thanks for sharing your thoughts.

      Re ABAP Mapping, I love it, but useful in rare cases.
      Re BPM, it's a long time I think PI and Galaxy should merge!
      Re Lookups, we'll do in ECC or other SAP backend.

      Not a big deal in the end.
      But still I love ABAP. 😉

      Cheers,
      Alex