Skip to Content
Author's profile photo Bjørn-Henrik Zink

Is HANA the end of ABAP Objects?

Long time has passed since I wrote my last ABAP Objects blog. I have been working as a development lead during the past years, focusing mainly on leadership and concepts such as design thinking and lean. I am in the middle of a major SAP implementation and therefore a question that is puzzling me a lot is:  “How will HANA impact our object-oriented ABAP design?” As a devoted ABAP Objects believer, I still often get into basic discussions with developers on why to use ABAP Objects.  Some clever developers argue that “HANA is the end of ABAP Objects”. In this blog I will briefly describe some of my thoughts on this delicate subject. I am not an HANA expert, my knowledge merely covers some basics about HANA that can be found here on SCN. However, I probably represent the majority of SAP customers and therefore my thoughts might be inspiring for others to comment this blog post or write a better blog themselves.

Let’s start with the top five reasons why I prefer object-oriented (OO) programming for ABAP:

  1. Reuse. Objects are self-contained and therefore reusable.
  2. Complexity. OO is ideal for breaking complexity into smaller and more manageable units with different responsibilities. ABAP developers often spend vast amounts of time to find out how BAPIs work and what impact various parameters (in those huge signatures) have on the functionality. Wrapping BAPI calls into methods with reduced signatures often makes it less complex for other programmers to use the BAPIs.
  3. Consistent business rules. Reusable code makes it is possible to write business rules centrally. Changes to the business rules will impact all code using them and thereby keeping them consistent.
  4. Division of labor. The division of labor comes with both reuse and structure of OOP. Senior developers can work with a central library and less experienced developers can focus on peripheral implementations. 
  5. Maintainability. In my opinion OOP is more structured and therefore easier and faster to grasp. Once the logic is understood, changes can be implemented centrally which reduces the development time significantly.

If HANA is the end of ABAP Objects, then it would imply that the above mentioned benefits will erode with HANA?

  • Reuse. I currently cannot see any reason why HANA will prevent us from creating reusable code. Even if the calculations are no longer done in the application layer, it is probably still smart to wrap HANA calculation calls in methods and bundling HANA calculations for an object in a class.
  • Complexity. Sometimes I hear the argument that HANA is so fast that it is better to place all code in the UI layer. Wait a minute! Technically there is nothing preventing a developer from writing select statements or BAPI calls directly in the UI layer today, but to achieve the above mentioned benefits we do not. I cannot understand why this should change with HANA.
  • Consistent business rules/Division of labor/Maintainability. Same as above assuming that 1 and 2 are fulfilled.

My best guess is that ABAP Objects is here to stay, but there will probably be HANA specific design patterns. Does that mean that code written in ABAP classes will stay the same? Surely not.  As described in various blogs here on SCN, code pushdowns will have a significant impact on existing code, for example calculations on internal tables.

To sum it up, is HANA a good excuse to not learn ABAP Objects? No, HANA is not the end of ABAP Objects! OO is a paradigm that is not directly related to HANA. However, HANA will most likely change the code within existing objects and the data that is passed between the objects.

I would love to see more ABAP Objects on HANA blogs. Why not start by showing us how SAP is implementing the ALV framework?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Breddemann
      Lars Breddemann

      Well written and valid points.

      What seems to be overlooked quite often is that HANA development is database oriented development and thus really nothing new concerning the development steps and processes required for it.

      If anything, including HANA will add logic on the DB or middle tier layers, but barely at the UI.

      Features like assisted search or recommendations while typing don't require to throw thorough software component design over board. Instead, proper encapsulation and design of such features are pretty much the only way, to keep the development feasible and maintainable.

      - Lars

      Author's profile photo Bjorn-Henrik Zink
      Bjorn-Henrik Zink
      Blog Post Author

      Thank you for your swift comment Lars. It provides more clarity to the blog post and is highly appreciated.

      Author's profile photo Former Member
      Former Member


      thanks for the very interesting post; I like it.

      I would like to add another point to your list above: "Testability".

      Creating "mock" implementations for interfaces  makes it easy to create unit tests for validating components. In addition this approach can help during interface design (e.g. usability, consistency of the interface) or in general for test driven development.

      In particular, in the context of SAP HANA unit testing via ABAP objects can be very beneficial because it allows to mock a complex "data crunching" in HANA for testing purposes. In addition to testing, this can also be exploited for parallelizing developments.

      Regards, Eric

      Author's profile photo Bjorn-Henrik Zink
      Bjorn-Henrik Zink
      Blog Post Author

      Hi Eric,

      thank you and thanks back for your excellent HANA blogs!

      I fully agree about "Testability" and was on the verge of adding it to the list. The reason I didn't is merely because I, admittedly, am using ABAP Unit too little to be claiming it as a main benefit for me. 


      Author's profile photo Naimesh Patel
      Naimesh Patel

      Hello Bjorn-Henrik,

      Thanks for a post on very different point of view. I agree that ABAP objects is here to stay.

      There will code push down to HANA DB for better performance, but that would around DB processing. E.g. you were selecting the DB records and manipulating them in your Methods to derive to a result without HANA. With HANA, you would push down this result logic as well to HANA by using SQL statements or HANA stored procedures. What you would still need is to expose this data to Users - probably an ALV - so you would still better of using the design pattern MVC.

      Not sure how Persistent object would evolved over the time when using the HANA. Currently, I don't think we can pass complex SQL to achieve the Code Push-down using Persistent Objects.

      Naimesh Patel

      Author's profile photo Bjorn-Henrik Zink
      Bjorn-Henrik Zink
      Blog Post Author

      Hi Naimesh,

      thanks for your comment. To many, including you, I am probably just stating the obvious with this blog. But I just had to write it anyway - in case somebody thought that ABAP Objects is negligible in the era of HANA.

      Keep up the great work with, I always read your blog posts.


      Author's profile photo Former Member
      Former Member

      Hi Björn-Henrik,

      you suggested to explain how ALV is implemented.

      With NW 7.40 SP02 we will release a new version of ALV - combining the convenience of the UI features with the mighty of HANA. And of course it is - for all the good reasons mentioned above - implemented in ABAP OO.

      So what is the new ALV about?

      The classic ALV works on an internal table, created and filled by the application developer, and provides all the nice features like sorting, filtering, grouping and aggreation, single und multi selection, user functions and so on.

      The new ALV changes this paradigm in integrating the data access. This allows us to push down features like authority checks, paging, sorting, aggregation and grouping to the database. We select only the data which is necessary for the actual page.

      Just to give you an impression how that works:

      " Bind control in the PBO module

      IF lo_container_d0555 IS NOT BOUND.

         CREATE OBJECT lo_container_d0555
            EXPORTING container_name = 'D0555_CONTAINER'.

          " Instantiate ALV
          lo_alv_display = cl_salv_gui_table_ida=>create( iv_table_name    = 'SFLIGHT'
                                                          io_gui_container = lo_container_d0555 ).

          " Add authorization to the data selection

              iv_authorization_object = 'S_CARRID'
              it_activities                    = VALUE #( ( auth_field = 'ACTVT' value = '03' ) )
              it_field_mapping        = VALUE # ( auth_field = 'CARRID' view_field = 'CARRID' ) ) ).



      This piece of code selects the pages of SFLIGHT and executes the authority check on the database. Only the part of SFLIGHT which fits to the page and user authorizations is selected and displayed. Sorting in ALV for example is executed on the database.

      By the way we are also providing this paradigm shift for FPM (Floor Plan Manager) in the context of WebDynpro.

      With ABAP on HANA we opened the ABAP stack and enriched it by new features to leverage the possibilities of the database. A developer has to choose the most appropriate language for his tasks. But in the context of business logic there is still room for ABAP OO - and I dare say, not a small one.

      Kind regards

      Thea Hillenbrand

      Author's profile photo Bjorn-Henrik Zink
      Bjorn-Henrik Zink
      Blog Post Author

      Hi Thea,

      thanks for your brilliant comment - well, actually, it is more like a blog post than a comment. It by far exceeds my expectations!


      Author's profile photo Former Member
      Former Member

      Excellent blog... breaking a lot of myths about Hana and ABAP Objects..