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?
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.
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
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
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.
maybe we can write an arcticle/blog on the comparsion on different programming languages?
All the best,
Guido
All the best,
Guido
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
Entities and data sources are great idea to make highly configurable lookups that can even change source DB on the fly!!
never said it is an issue....
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
I hoped that JAVA was gone together with Shai - or is anyone up to paying fees to Oracle?
Regads,
Vijay
@greg_not_so
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
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.
Thanks,
Srini
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