In 1999, I started my professional career at a mid-sized German hospital. In 2000, we had succeeded in bringing our at-the-time already ageing patient management and billing system through the Y2K madness that was happening all around without too much effort. Then the news came – although the system was Y2K-proof, it wasn’t built to handle multiple currencies, and the vendor had decided to discontinue the product. Looking for a replacement, we finally ended up using the combination of FI, CO, IS-H for patient management, PM for our building services and maintenance department. A bit later, MM and especially i.s.h.med for the clinical aspects were added as well. At the time, one of my main tasks was to implement various forms and additional reports. I already knew several programming languages at the time and had some experience with Oracle, Interbase and other RDBMS, so taking a dive into ABAP development was a natural choice. This was back in release 4.6D. Since then, I’ve worked for a few years one of the companies that make i.s.h.med and which is nowadays part of the Siemens AG. During that time, I had the chance to learn a lot about ABAP development both in customer projects and for add-on and product development. Since 2009, I’m with one of Germany’s largest inpatient and rehab healthcare providers. Today, I’m responsible for the development team that extends and enhances i.s.h.med and connects it with surrounding systems – but since the team is small and I can’t resist it anyway, I still write quite a bit of ABAP applications.

I actually knew quite a bit about Eclipse, even in conjunction with ABAP systems, before ABAP in Eclipse emerged in its current form. For my bachelor’s thesis, I designed and explored a modeling solution to generate “stuff” (a common technical term) in the i.s.h.med system. During that project, I learned a lot about Eclipse and its flexibility and extensibility – not only as an IDE, but also as a starting point to develop your own applications. Sadly, the prototype was never developed into a full project. At the time, I used cheat sheets to guide first-time users through my application. Although simpler and a lot less interactive, cheat sheets and the ADT Feature Explorer follow a similar basic principle that has proven to be very valuable to support new users.

Since I’m rather familiar with the “traditional” ABAP development environment, there was no real incentive for me to explore the ADT in its first stages. I use data dictionary objects a lot, and most of our development is still screen-based (dynpros), which are both unsupported. For DDIC objects, that will change, for screens it probably won’t. Combine that with the fact that you were basically cut-off from the existing documentation (descriptions and documentation texts) in the early releases of the ADT, and I think it’s understandable that I decided to concentrate on other issues and give the ADT some time to mature. At this year’s TechEd && d-code in Berlin, I took the opportunity to visit the DEV165 session and familiarize myself with the current state. I’m still not using ADT for my day-to-day development, mostly because nobody else in my team is and we’d lose a lot by splitting up the toolkit right now, especially since a full two-way transfer of the documentation is not yet implemented. However, I will be presenting the ADT during our team meeting tomorrow, including Cristina Jitareanu, Christian Graff and a number of colleagues who unfortunately haven’t yet found the time to use all aspects of the SCN. I would also recommend it to Daniel Sonnabend but I know that Daniel actually has had the opportunity to take a look at the ADT earlier than me, due to the fact that we have to support far lower releases.

To report this post you need to login first.

15 Comments

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

    1. Volker Wegert Post author

      Hi Thomas,

      The first immediate benefit for me is the flexibility of the UI – the possibility to arrange the various views and editors spontaneously as I need them. The editor is nice, but I’m far from reaching the same speed as with the “classical” form-based class builder – simply because I have to type in a lot more. I’m hoping that will change over time. The integrated SAP GUI for Java – well, it’s there. That’s something positive, I suppose 🙂

      In the long-term, I’m hoping for

      • extensibility for small-scale tools (like a custom plug-in to generate methods or something like that)
      • extensibility for custom object types (if you won’t support dynpros, maybe someone else will?)
      • extensibility for whole new toolchains (Xtext-like modeling anyone?)

      There’s another downside though, at least for us: Most of the backend operations are reeeeally sluggish at the moment. Code completions or quick fixes that take five seconds to pop up are anything but a productivity boost.

      Cheers

        Volker

      (0) 
      1. Ernesto Caballero

        Hi Volker,

        I couple of days ago I also tested Eclipse (Kepler Version) with ABAP. To my surprise, I thought it was going to convince me from the start but it didn’t. As you mentioned, really basic stuff from ABAP can’t be used (Web Dynpros, Data Dictionary, to name a few). IF you want to work with Web Dynpros, a small window opens and you actually see the SAP screen but really small (as the window is surrounded by Eclipse – You can maximize it though). Another downside as you said, is that it adds some seconds to open, lets say, the DDIC window.

        I got the feeling it might be a long way to fully replace SAP UI with Eclipse.

        Just my humble opinion.

        Ernesto.

        (0) 
        1. Thomas Fiedler

          Hi Ernesto,

          it was not the intention to just copy the ABAP workbench to eclipse before releasing it To our customers. We are developing the tools in an agile development mode.

          We are focussing on the topics where we think that we can improve the developer efficiency the best. Thats the reason why we started with ABAP source code editors. Then we started with Web Dynpro which is available in eclipse since last year. DDIC is the next candidate on our road map. Maybe you already saw the new view editor in eclipse which gives you much more features than SE11. Next is structure and data element editor. So we are working to close the gaps based on your feedback.

          Regards,

          Thomas. 

          (0) 
          1. Volker Wegert Post author

            Thomas,

            do you have a timescale when the DDIC integration will be availables? More specifically, can you already tell us something about the SP levels that will provide the necessary backend functions?

            Thanks

              Volker

            (0) 
            1. Thomas Fiedler

              Hi Volker,

              Q3/2015 is a realistic estimation for the shipment of DDIC support in eclipse. Depends a bit on our shipment strategy: shipment via SPs vs. EHP. Our Text-based Structure editor is nearly complete so that we can go on with data elements and domains. What is your opinion concerning the question form-based vs text-base DDIC editors.

                

              Regards,

              Thomas.

              (0) 
              1. Peter Inotai

                “What is your opinion concerning the question form-based vs text-base DDIC editors.”

                Is there no plan for graphical editors? In HANA there are some nice editors for views (eg for calculation view). The text based DDL-editor can be difficult to read if you have many tables and the source is getting long.

                Peter

                (0) 
                1. Thomas Fiedler

                  Hi Peter,

                  yes, you are absolutely right. For CDS Views we also want to provide a graphical editor that shows the joins and association relationships of the CDS view. Looks really promosing what I saw yesterday in our sprint review. Will be most likely delivered in the same timeframe as the text-based DDIC editors.

                  Regards,

                  Thomas.

                  (0) 
              2. Volker Wegert Post author

                What is your opinion concerning the question form-based vs text-base DDIC editors.

                I have to admit I’m rather fond of the form-based editors. They are really easy to handle with both mouse and keyboard navigation, and they are the same everywhere. You have much less stuff to read and parse because you can identify the state of an object at a glance. In text based editors, you always have to read the keywords as well. I’m not particularly satisfied with the movement towards a source-only view for ABAP classes, neithter in the classical editor nor in AIE. Personally, I’d take a bet that it slows down everyone. When creating a new method signature in the form-based editor, you can focus on the essentials – what goes in, what comes out, what types are involved? When creating a new method signature in the text-only editor, you have to have all that in your head and observe the syntactical specialties (METHOD vs. METHODS? EXPORTING before or after CHANGING?) as well. It’s not that difficult, but the developer has to do it manually where in the form-based editor, it’s the machine that ensures that this “boilerplate coding” is present. Shifting work from the machine to the developer is almost always a bad move.

                (0) 
                1. Thomas Fiedler

                  Hi Volker,

                  the method defintion is a very good example that shows that you have to adapt your wokring model to be more efficient with eclipse. You are absolutely right. When you are creating a method in eclipse just like you do it in SE24 you will be slower for sure. But when you are using the Quick Assist to create a method from the call statement I’m sure that you will be quicker than in SE24. Because the call statement you anyhow have to code in the editor and the rest is done by Quick assist.

                  Regards,

                  Thomas.  

                  (0) 
                  1. Volker Wegert Post author

                    Thomas,

                    unfortunately, that’s only half of the picture. It is certainly a viable alternative for internal (private) auxiliary methods. For everything else, our approach is different: we create the interfaces first, with the method signatures using other interfaces almost exclusively, and only then fill in the implementation classes. This way, it’s a lot easier to later mock certain classes for unit testing. At the time the method signature is created, there is no CALL METHOD that we could use a quick-fix on….

                    Best regards

                      Volker

                    (0) 
                    1. Thomas Fiedler

                      Hi Volker,

                      this scenario to me sounds more like an UML->ABAP generation approach.

                      You know the UMAP project that has this kind of generation in scope?

                      Regards,

                      Thomas.

                      (0) 
          2. Peter Inotai

            “DDIC is the next candidate on our road map. Maybe you already saw the new view editor in eclipse which gives you much more features than SE11. Next is structure and data element editor. So we are working to close the gaps based on your feedback.”

            Really good news. It was one of the thing I missed the most when I checked ADT. 🙂

            (0) 

Leave a Reply