Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

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.

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...

TableNotional Description
KNC1Customer Account Balance
LFC1Vendor Account Balance
GLT0GL 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...

TableNotional Description
BSISSecondary Index for G/L Accounts
BSIDSecondary Index for Customers
BSETTax Data Document Segment
BSIKSecondary Index for Vendors
BSAKSecondary Index for Vendors (Cleared Items)
BSASSecondary Index for G/L Accounts (Cleared Items)
BSADSecondary 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”.

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?

Labels in this area