AiE – an modern IDE for ABAP programmers
Few words about me
I started to develop ABAP since 2008 within the standard SAP modules (FI, MM, SD, CO etc.). At the moment, I am part of the FS-PM custom development team for an insurance company.
How I started with AiE
I want to be honest and to recognize that I had two tentative to jump from SE80 to AiE. In both cases, I gave up because it was difficult to change my comfort zone, so for example, from an “nice” form-based class builder in SE80 to an source-code based class builder in AiE. Another reason was also the debugger, because I had the false idea that debugging in the old ABAP debugger is easier and faster as in ADT.
After hearing a lot of good opinions from my work colleagues about AiE, I said to myself that I still have to give a chance to AiE and to forget my previous development style, or in other words, to make it “a part of the history” 🙂
Like as I said, it was a little bit difficult at the beginning, but now I can say that developing in AiE is 10X more efficient and faster than in SE80, having a lot of features which helps you in the application development. That’s why, I try now to convince more and more colleagues to jump to AiE in order to use the fascinating features of AiE.
Favorite Features from AiE
I will enumerate some of my favorite features from AiE:
- The magic key combination ALT + U – Delete unused variables (all)
- Extract Method – an very useful refactoring feature
- Quick Fix (combination key CTRL + 1) – you get appropriate proposal(s) for selected object, i.e. for an new declared method in class declaration part, you can select the method name and trigger the feature Quick Fix in order to automatically create the implementation of the method in the class implementation part.
For the ones which want to know the features of AiE, the AiE feature explorer is the best way to do that.
In the end, thanks Victor Ionescu for the AiE Feature Explorer challenge and last, but not least, thanks Thomas Fiedler for providing us the AiE.
Thanks Catalin for your blog.
There are a lot of more quick fixes in our backlog coming with the next releases.
Any proposals form your side concerning features that are yet not covered in AIE.
Thanks. It will be very useful to consider as quick fixes also the generation of getter and setter methods for an specific class attributes.
Even though I agree that Google's reasons are pretty solid (they wanted a faster IDE with a better workflow, specialized on Android dev), I think that SAP right now is trying to offer a unified (+ open source and free) development environment for all/most of their products. Right now Eclipse is the only way you can develop SAP ABAP, UI5, HANA, cloud etc. without having to constantly change between IDEs. Eclipse was really the best way to go (apart from building their own IDE from scrap, which would have taken a lot longer).
I'm a bit surprised about your opinion that AIE makes ABAP development less efficient. Especially as response to a blog that tells something about a factor of 10.
I really talked with a lot of ABAP developers (not Java developers) over the last two years that told me that they are more efficient with eclipse compared to SE80. So maybe you can share your experiences with AIE and where you see improvement potential.
Concerning the installation process we have since a couple of weeks a guide how you can setup a corporate internal updatesite which makes it very easy to install the tools on every developer workplace.
to my understanding the new Android IDE is also a fat client installation. Why haven't they chosen a Web based environment? Maybe because of the offline capabilties?
I mostly disagree with your idea of a HTML5 web-based IDE. I must admit that it seems appealing, but at a closer look, it would be terribly hard to completely replace SE80 (without using a browser plug-in to integrate SAP GUI). Right now it is almost impossible to do all the tasks needed as a developer without using a screen based transaction. There are just too many transactions (SAP estimates that there are, in total, ~400.000 dynpro screens that are actively used by customers/partners) for SAP to possibly remake them all into HTML5 apps (check out the SAP UX related materials). Not to mention that you might also have to use or even create classic screens that are part of your current project and were/will be developed by your company. So as long as there will still be development on classical/legacy scenarios, such an IDE is unfeasible.
Also, my previous point still stands: Eclipse manages to provide tools for most technologies/programming languages offered by SAP, both on premise and in the cloud. ABAP, XSJS, UI5 (js, json, xml), oData, Java, and so on. In my opinion, a web based IDE which could leverage all these capabilities would prove to be quite sluggish and anti-productive.
EDIT: Also, I must underline that if Google does something, it doesn't mean that it is a guarantee that it will work in the long run. Google has an extensive history of abandoning, canceling or completely remaking their projects (search 'google graveyard').
did we not talk already a lot aiming at this point in the near past. I'm a bit confused that you are starting it again? Why don't you write a blog about it, so people can directly comment it and give you feedback to your view?
like Florian Henninger I know your views about the cloud editor being the solution that should have been implemented at least four years ago.. 😉 and with WebIDE (which suprisingly enough is not yet named HanaIDE) SAP does follow that aproach - in a different arena though.
I do think that with the ADT tools SAP is decoupling the ABAP Workbench backend from the frontend in a way that we'll most likely will see a cloud based ABAP dev environment in the near future. A WebIDE Plug-in should work wonders there... (speculations on my part 😉 )
In the meantime I do think that AiE is a step in the right direction - because it delivers now a better development experience! Maybe late but.. but better late than never!
I do prefer Eclipse over SE80 and look forward to every single next release - but would gladly jump on the shiny ABAP cloud wagon once it arrives in a train station near your convinience.
that's exactly the point. Most of the logic of the development tools run on the ABAP server. Our major investment was the service enablement of the backend functions like syntax-check, activation etc and the REST architecture to trigger these services from arbitrary clients. A good proof-point for this architecture is the web access to ABAP resources:
Improved ADT links or how to display your ABAP source code in a web browser
By the way the integration of the SAP Web IDE with the ABAP backend to store SAP UI5 applications in ABAP is done via the AIE infrastructure.
for my point of view it's everyone's own decision which development environment is best her/him. Setting Eclipse to the current strategic development environment is a logical step for me - at the moment I see the benefit in real project life of combining SAP HANA administration, SAP HANA development (both on ABAP and native as well), ABAP development, SAP Gateway and SAPUI5 in one single Eclipse
installation. Of course, especially for CRM there is the WebUI missing, but the component workbench works very well and why should SAP re-implement it in the same way; maybe a better WebUI component workbench is appreciated.
But at the same time I understand everybody who says "I perform best in SE80" - and that is okay (if she/he doesn't need the new fancy features but view building is hard in SE80 without CDS); co-existence is important.
Now to Google: why should we care if they stop to support Eclipse? Of course, some developers using Gateway services are affected if ADT (did not know that Google has also an ADT ;-)) is not supported any more. And by the way, not everything Google does is important (to me). But SAP WebIDE will be (to me).
So I really encourage everybody: if you've got constructive feedback or some ideas (e.g. I like the point of integrating Eclipse SAP-ADT with WebIDE) please write a small blog with some screenshots if necessary and we've got a discussion base.