Skip to Content
Author's profile photo Graham Robinson

SAP HANA Explained – Again

I was fortunate to be invited to take part in the SAP Influencer Program at SAPPHIRE NOW and ASUG Annual Conference last week.

During his keynote, Hasso Platner described how HANA provided the opportunity to completely redesign applications in a way that is much simpler than ever before. Some people I spoke with afterwards told me this was the moment that crystallised for them that HANA more than just another database.

I encourage you to watch the replay of the keynote, but I think it worth taking some time to go through the example Hasso provided again.

Hasso started with something we are all familiar with – SAP Business Suite. When we post the simplest invoice transaction we need to do a couple of things. We create the invoice document in the header table – known as BKPF. And we create three entries in the segment table – known as BSEG. One entry is for the customer, one for the profit account and one for the tax record.

Screenshot 2014-06-08 13.19.22.png

Sometime later we will need to do some querying and reporting that will include this transaction data – for example get the balance of one of the accounts it effects. With traditional databases it is impractical to calculate the balance at runtime by doing a sum of all transaction values. This means we build aggregates to hold the current balance which we update each time a transaction is executed. So, after inserting the transaction data, we need to also update data in tables such as…

Table Notional Description
KNC1 Customer Account Balance
LFC1 Vendor Account Balance
GLT0 GL Account Balance

We also need fast access to the transactional data from various other areas so we use some secondary indexes. This means inserting records in tables such as…

Table Notional Description
BSIS Secondary Index for G/L Accounts
BSID Secondary Index for Customers
BSET Tax Data Document Segment
BSIK Secondary Index for Vendors
BSAK Secondary Index for Vendors (Cleared Items)
BSAS Secondary Index for G/L Accounts (Cleared Items)
BSAD Secondary Index for Customers (Cleared Items)

So now our code to post the original transaction is getting a lot more complex. And this additional work can take some time so we have to use other techniques, like passing off some processing to the update task to perform asynchronously so we can provide the end-user with acceptable response times. Our code for the simple invoice posting transaction is now getting very complex, it is located across several different places, it has to provide choreography between loosely related steps, support complex error handling, etc.

HANA provides us with the opportunity to radically simplify out invoice posting application. Because all these aggregates can actually be immediately calculated on the fly as they are required there is no need for the tables that hold this data at all. The same applies to the secondary index tables. We can simply get rid of them and replace them with identically named views. This means there is no change required to any of the code that reads these tables because whether you are reading data from a table or a view the SQL syntax remains the same.

But that is not where the real advantages are. The real advantage is that all the code that creates those aggregates and secondary indexes is no longer required. Instead of calculating and updating the many aggregates the invoice transaction effects we simply have to insert the header and item data into their respective tables. There is no need to create secondary index entries either. That’s it, job done. We have a simpler data model, simpler code, much less code and therefore a significantly simpler application. It is easier to build, easier to test, easier to change, and much less error prone. In Hasso’s words “there is almost nothing that can go wrong”.

Screenshot 2014-06-08 13.20.00.png

By way of example – think about what would happen if a bug was introduced into the code that calculates one of those pesky aggregates. In the traditional model this would immediately introduce errors in the data stored in the database. So a fix to the code would have to include a suitable correction program to check all the aggregate data stored in the database and correct it to eliminate the error and its’ effects. In the new simplified design the algorithm that calculates the aggregate can be fixed and then the correct aggregates would be available immediately.

Pretty simple eh?

Assigned Tags

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

      A great summary, Robbo. Anyone who has seen the keynote, or not seen it, should read this post for a quick 5 mins recap.

      I must admit feeling quite sad reading this, with the prospect of saying goodbye to well-known friends (BSIS, BSID, etc) and processes (V2) from my earlier career 🙂

      Seriously though, this really is at the heart of a lot of the simplification message.

      But I wanted to call out a part of what you wrote, because it could be lost amongst the other stuff, and I think it's actually the most important part, particularly for existing SAP customers, and those customers who are concerned about possible disruption:

      "... replace them with identically named views ..."

      This is the most amazing thing. As you mention, it means that there is minimum impact on required programming changes (for SAP and customer developments alike). As usual, the beauty of abstraction, the power of which has been a cornerstone for SAP tech since I started over 25 years ago, is plain to see.

      People, please read this and contemplate the significance. It is not a trifle.

      Author's profile photo Fred Verheul
      Fred Verheul

      Totally agree DJ, this part was an eye-opener for me (hadn't thought about it yet).

      Author's profile photo Henrique Pinto
      Henrique Pinto

      Even though you can do that, as Robbo said himself, you don't even need to do that anymore. Simplifying the data model is good, but reducing the amount of code you need to maintain is key for a more efficient SW lifecycle. This means we'll have less developers having to mess with cumbersome code for 6.0x, x >= 0 for every single SAP Note that is released, enabling those developers to invest their precious time in delivering actual value, in the forms of newer SAP Fiori apps, the other modules of sERP, or maybe the next big thing that we don't even know about yet.

      Author's profile photo Former Member
      Former Member


      Sounds like what you're describing is a journal entry or the simplest business transaction there is, "invented" some 500+ years ago and still forming the basis of our economic system, including the now defunct Marxist communist formulas.



      Author's profile photo Abdul Hakim
      Abdul Hakim

      Very good recap.

      Author's profile photo Former Member
      Former Member

      As an ABAPer, I can say that this post is really easy to understand. Now I guess this is only a small part of what can be achieved through the capabilities of SAP HANA, right? Kind of, just the tip of the iceberg thing?


      Author's profile photo Graham Robinson
      Graham Robinson
      Blog Post Author

      Thanks for your comment Guillermo. You are right that this is just the tip of the iceberg - but importantly it shows that HANA does not mean the end of road for the existing Business Suite applications that support the huge customer installed base.


      Graham Robbo

      Author's profile photo Abdul Hakim
      Abdul Hakim

      I agree with Robbo. To add whatever SAP brings in such as HANA etc will revolve around ABAP based applications and enrich / empower them. ABAP is the King of SAP Business Software and others follow suit 😆

      Author's profile photo Sudarshan B
      Sudarshan B

      This is by far the best and simplest explanation I ever read about SAP HANA. Thanks @Graham Robinson for summarizing this 🙂


      Author's profile photo Graham Robinson
      Graham Robinson
      Blog Post Author

      Thanks Sud