Skip to Content

Developer’s Journal: First Steps into the SAP HANA World


A long time ago when I first started blogging on SDN, I used to write frequently in the style of a developer journal. I was working for a customer and therefore able to just share my experiences as I worked on projects and learned new techniques. My goal with this series of blog postings is to return to that style but with a new focus on a journey to explore the new and exciting world of SAP HANA.

At the beginning of the year, I moved to the SAP HANA Product Management team and I am responsible for the developer persona for SAP HANA.  In particular I focus on tools and techniques developers will need for the upcoming wave of transactional style applications for SAP HANA.

I come from an ABAP developer background having worked primarily on ERP; therefore my first impressions are to draw correlations back to what I understand from the ABAP development environment and to begin to analyze how development with HANA changes so many of the assumptions and approaches that ABAP developers have.

Transition Closer to the Database

My first thought after a few days working with SAP HANA is that I needed to seriously brush up on my SQL skills. Of course I have plenty of experience with SQL, but as an ABAP developer we tend to shy away from deeper aspects of SQL in favor of processing the data on the application server in ABAP. For ABAP developers reading this, when was the last time you used a sub-query or even a join in ABAP? Or even a select sum?  As ABAP developers, we are taught from early on to abstract the database as much as possible and we tend to trust the processing on the application server where we have total control instead of the “black box” of the dbms. This situation has only been compounded in recent years as we have a larger number of tools in ABAP which will generate the SQL for us.

This approach has served ABAP developers well for many years. Let’s take the typical situation of loading supporting details from a foreign key table. In this case we want to load all flight details from SFLIGHT and also load the carrier details from SCARR. In ABAP we could of course write an inner join:


However many ABAP developers would take an alternative approach where they perform the join in memory on the application server via internal tables:


This approach can be especially beneficial when combined with the concept of ABAP table buffering.  Keep in mind that I’m comparing developer design patterns here, not the actual technical merits of my specific examples.  On my system the datasets weren’t actually large enough to show any statistically relevant performance different between these two approaches.

Now if we put SAP HANA into the mixture, how would the developer approach change? In HANA the developer should strive to push more of the processing into the database, but the question might be why?


Much of the focus on HANA is that it is an in-memory database. I think it’s pretty easy for most any developer to see the advantage of all your data being in fast memory as opposed to relatively slow disk based storage.  However if this were the only advantage, we wouldn’t see a huge difference between processing in ABAP.  After all ABAP has full table buffering.  Ignoring the cost of updates, if we were to buffer both SFLIGHT and SCARR our ABAP table loop join would be pretty fast, but it still wouldn’t be as fast as HANA.

The other key points of HANA’s architecture is that in addition to being in-memory; it is also designed for columnar storage and for parallel processing.  In the ABAP table loop, each record in the table has to be processed sequentially one record at a time. The current version of ABAP statements such as these just aren’t designed for parallel processing. Instead ABAP leverages multiple cores/CPUs by running different user sessions in separate work processes. HANA on the other hand has the potential to parallelize blocks of data within a single request. The fact that the data is all in memory only further supports this parallelization by making access from multiple CPUs more useful since data can be “fed” to the CPUs that much faster.  After all parallization isn’t useful if the CPUs spend most of their cycles waiting on data to process.

The other technical aspect at play is the columnar architecture of SAP HANA. When a table is stored columnar, all data for a single column is stored together in memory.  Row storage (as even ABAP internal tables are processed), places data a row at time in memory.

This means that for the join condition the CARRID column in each table can be scanned faster because of the arrangement of data. Scans over unneeded data in memory doesn’t have nearly the cost of performing the same operation on disk (because of the need to wait for platter rotation) but there is a cost all the same. Storing the data columnar reduces that cost when performing operations which scan one or more columns as well as optimizing compression routines.

For these reasons, developers (and especially ABAP developers) will need to begin to re-think their applications designs. Although SAP has made statements about having SAP HANA running as the database system for the ERP, to extract the maximum benefit of HANA we will also need to push more of the processing from ABAP down into the database.  This will mean ABAP developers writing more SQL and interacting more often with the underlying database. The database will no longer be a “bit bucket” to be minimized and abstracted, but instead another tool in the developers’ toolset to be fully leveraged.  Even the developer tools for HANA and ABAP will move closer together (but that’s a topic for another day).

With that change in direction in mind, I started reading some books on SQL this week. I want to grow my SQL skills beyond what is required in the typical ABAP environment as well as refresh my memory on things that can be done in SQL but perhaps I’ve not touched in a number of years. Right now I’m working through the O’Reilly Learning SQL 2nd Edition by Alan Beaulieu. I’ve found that I can study the SQL specification of HANA all day, but recreating exercises forces me to really use and think through the SQL usage. The book I’m currently studying actually lists all of its SQL examples formatted for MySQL. One of the more interesting aspects of this exercise has been adjusting these examples to run within SAP HANA and more importantly changing some of them to be better optimized for Columnar and In-Memory. I think I’m actually learning more by tweaking examples and seeing what happens than any other aspect.

What’s Next

There’s actually lots of aspects of HANA exploration that I can’t talk about yet. While learning the basics and mapping ABAP development aspects onto a future that includes HANA, I also get to work with functionality which is still in early stages of development. That said, I will try and share as much as I can via this blog over time. Already in the next installment I would like to focus on my next task for exploration – SQLScript.

You must be Logged on to comment or reply to a post.
  • Well, while I can't see that happening to give us all the latest thoughts on HANA - I thought I would add some of the independent questions/thoughts I would have about HANA.
    Firstly I realise your example is just an example, but my expectations with future ERP on HANA is that the ABAP inner join you show will be sent directly to HANA so the rethinking is really to not be afraid of these inner joins (within reason).
    Secondly, the business logic aspect within HANA is great and scary at the same time, so I wonder if we'll start to see Object Oriented Stored Procedures being invented (if they don't exist already).  Even better would be integration with se24 objects so that methods can be "redefined" within HANA so at least we get consistent control within ABAP land.  Obviously redefinitions may need to support landscapes that don't have HANA which is where an overall HANA switch framework option may come in handy.
    Anyway, just dreaming of the possibilties - Great blog.
    • >but my expectations with future ERP on HANA is that the ABAP inner join you show will be sent directly to HANA

      Absolutely the ABAP inner join would be passed through to HANA. I didn't intend to give the impression otherwise.  I was simply trying to compare two approaches.  The first step for ABAP developers is to embrace features in Open SQL which they might have been reluctant to use in the past. But that's just the tip of the iceberg as there are some fantastic new possibilities which will eventually leverage new features in both ABAP and HANA. That's what I want to continue to share as those features come closer to customer availability.

      >so I wonder if we'll start to see Object Oriented Stored Procedures being invented

      There's defintely lots of ways we can go with this. That's one of the things I love about this new role I have at SAP: I get to be involved with gather requirements and thoughts from the community which will directly impact that direction. Its early in the lifecycle and we can still influence so much. That said, some of first ABAP for In-Memory applications already have some interesting approaches to his and I can't wait to explore them and share those experiences in the future.

      • Thanks Thomas.  I realised you didn't intend to do this, and the example is good, but wanted to make it clear regardless.
        In terms of getting community requirements - provided "customer" custom development is still fully supported in a maintainable way - I'm more than happy.
        • I assume you will be at Mastering SAP Technologies in March. That's my first opportunity to sit down with a group of customers and get their ideas and feedback around what should/shouldn't be in the HANA developer tools.  We will repeat this process at SAPPHIRE/ASUG Annual Conference in Orlando in May.  I hope to see you there for these conversations.
  • As an old ABAPer (and I do mean old) you've made HANA processing so much more comprehensible to me.  Can't wait for more journal entries and delighted with this format.  I love your writing style and look forward to understanding through your experiments, discoveries, and tire-kicking.  Bravo!
    • I was always a pretty big believer in ABAP database views. I like them because they make the join logic more reusable.  I had a tendency to write the joins in-line on first pass, test and then convert to a database view once I got it right. They should have the same advantage with ABAP running on HANA as well.  However I think we might find that HANA specific view capabilies (like Calculation Views) or SQLScript gives us funtionality that goes beyond a Join condition or what you can do in the database view.

      So pros and cons - ABAP database view would still be database type independent. But HANA specific View types (which I will talk about more in future blogs) could give you more power/performance but at the cost of making your ABAP coding HANA specific. This is the balance we (SAP, Customers, and Partners) will face in the future.

  • Thomas,

    thanks for this blog entry.
    Firt of all I am no an ABAPer. I have never written any ABAP in my life even during SAP training .. I must miss something 8:)

    My understanding :
    + in order to take full advantage of HANA capabilities you need to write different piece of code
    + SAP ERP philosophy has been more or less DB agnostic
    + SAP Vision : SAP ERP Module on HANA (it may come sooner)

    My current vision :
    1. ERP on HANA will be available but most of the moduled will still have the DB agnostic pattern (so not leveraging the HANA power and capabilities)
    2. new "functions/modules" will be developed to take full advantage of HANA
    3. some existing functions/modules will be enhanced to take advantage of HANA. Will it be one piece of code or two pieces of code (one for HANA, one for non HANA) ?  

    If 1 is not correct I have hard time to understand how the same code (especially the database portion) could be used for HANA and non HANA database. 

    As you it is "naive" question from a non SAP "geek" .... looking forward your future blog.

    • Your impression is very accurate. ABAP (and therefore ERP) has traditionally been very DB agnostic.  The first step toward HANA is getting ABAP and ERP running using the database abstraction layer.  Next step is for SAP to do as much optimization within the abstraction layer and in the ABAP VM as possible for HANA without requiring changes at the ABAP coding layer.  Finally we reach the most optimization for HANA by rewriting existing ABAP code or introducing new logic. This isn't a process which will happen overnight, but it is something we are moving toward rapidly.  One of my goals is to share my experiences to help ABAP developers out there begin to prepare for changes in design and coding to better take advantage of HANA once we reach these final stages of integration.
  • Hello Thomas,

    ABAPers have been hearing HANA for quite a while and I always wondered how will I fit in until I got access to Online Innojam HANA Sandbox. This is the first blog I have read which correlates ABAP and HANA. Please accept a hearty Thanks for writing the blog. Very delighted to read this.
    When you correlate in-memory with buffering, question arises - buffering at times may not pick the latest updated data and we have to bypass buffer many of the times.I may have to understand the term in-memory better.
    You may laugh at my exp. with writing SQL in HANA sanbox:
    1. Ending statements with period (.).
    2. CREATE TABLE - This is disaster as I should always write CREATE COLUMN TABLE
    3. While creating joins and views in HANA studio,defining cardinality etc. I remembered how easy are they to create in ABAP.
    I completely agree that we will get to know more about direct database processing.


    • >When you correlate in-memory with buffering, question arises

      That's true that there are vast differences between complete in-memory database and a solution that uses heavy buffering.  Overall In-Memory is certainly going to be superior.  However on a read-only operation In-Memory alone might not necessarily be faster than heavy buffering.  However this is why it is important to understand that HANA is more than just In-Memory.  It is the combination of In-Memory + Column Store + Parallelization that work together to provider overall better performance.

  • Hi Thomas,
    It's good to see you back blogging. I hope you'll be able to do it more often 🙂
    Is there any sneak preview for HANA planned?
    Or it's depends also on the ABAP for Eclipse availability? Or it requires a special hardware?
    It would be great to have the possibility to play around with.
  • Hi Thomas..

    Always reading ur blog is a great pleasure.. Especially valuable comments section which will extend for pages together detailing all your patient replies to every query. Its extremely exciting that you are into HANA now. Going forward learning HANA will be like eating scoops of Honey !!! That is how we feel after reading your down to earth .. simple & all informative blogs..

    You have always been so kind in sharing the essence of your knowledge with people around the world.

    Longing to see the whole picture of ICEBERG ...

    Good Day Thomas..

    - Bharath