Skip to Content

In Berlin I attended  two SAP HANA on BW sessions. On Wednesday there was a session on the SAP BW product + roadmap session by Lothar Henkes and on Thursday there was an End to End scenario session by again Lothar Henkes but mainly Marc Harz. Additionally I started the opensap course this week after the Teched&&Dcode where I saw a familiar face… Hello Marc!

In this blog I share some of my thoughts on what I saw in Berlin. As I found some things in Opensap quite important in reiterating what SAP BW is supposed to do I included a paragraph on that subject.

BW_Overview.jpg

Source: SAP.

In the image above you see the main points of the new things that have been developed in SAP BW 7.4 up until SP8.

In the first presentation the new developments where grouped in a couple of themes. As I was actually impressed at the time at the structured manner of the presentation I will follow that structure and reference the other sessions.

SAP BW

But before we dive into the things I heard in Berlin, I will point at the opensap course that just started a couple of days ago. As SAP BW is clearly going through some rapid changes it was good to go back and look at what the goal of the application is. In one of the first slides in week 1 this overview was givern:

/wp-content/uploads/2014/11/opensap_overview_586437.jpg
Source: SAP.

SAP BW is an application on top of a database. What it wants to do is help you to manage the data warehouse.

As it is an application BW basically lays an abstraction layer over the database. In the past due to all kinds of technical constraints BW felt more like a technical exercise to get performance or to get it to work period.

Now that HANA is doing the heavy lifting, BW seems to get its focus back to what it is originally meant to do. Create a business layer over your database to easier build a data warehouse.

You can find the course here: SAP Business Warehouse powered by SAP HANA – Marc Hartz and Ulrich Christ

Try it. It is free and the first week looked very promising.

Virtual Datawarehouse

The virtual Data warehouse is a layer that is able to  work because of SAP HANA. Only with SAP HANA you are able to get the performance you need to use virtual layers. What SAP BW delivers is ways to create virtual objects that leverage the technology. Utilizing this technology you can think of creating separate views for different departments without having to copy the data. Additionally it creates more flexibility as in the past data reloading was a big part of the time needed to get changes done.

BW_VIRT.jpg
Source: SAP.

In SP8 you have two main objects for your virtual view. The Composite Provider and the Open ODS view. The latter is meant for virtual access to external sources.

The Composite provider looks like the main tool for modelling. It enables you to combine info providers with JOINS (merging) or UNIONS (appending). You can even use other composite providers as source. Note however that this currently is UNION only.

Basically this means that you theoretically can store data only once and build virtual layer upon layer on top of that.

Personally I think that you will keep some kind of staging area around, when you don’t know if the source system is going to retain the data, use transformations to create a persistent single version of the truth, things like cleansing and checking the data,  and from there go with virtual layers.

Simplification

The picture seems clear enough. From a large number of objects we go back to only a couple :

DS_simplification.jpg

Source: SAP.

I was really enthusiastic about this and now after a few days I still am. However I do need warn you that there still is a lot of complexity hidden within the objects. The Advanced Datastore Object (ADSO) for example has three checkboxes that can be set on independently of each other. This checkboxes determine which of the three tables underneath the application layer will actually be used. This means that you have 2^3 16 different setups to choose from. In the presentation there was a mention of templates for different situations. That should help in that case. From an architecture point of view You have to look at the options and determine which options should be used in which circumstances.

All in All it looks good. In the End to End session Marc Harz showed us a live demo where he showed the editor of the composite provider.

/wp-content/uploads/2014/11/screenshot_composite_586443.jpg

Source: SAP.

This looks a lot better than the old editors for multiproviders. Now with the ability to use compositeprovider as source for other compositeproviders you can create simple building blocks that together build your application.

Big Data

For Big data management SAP BW differentiates between three types of data based on the amount of usage: Hot, warm and cold. Hot data will be in HANA in memory, warm data will be in HANA, but on disk and finally cold data is stored in Near line storage on separate servers.

This should help you to achieve a more efficient usage as you’re only investing in expensive equipment for the hottest data and can keep a more modest budget for the rest.

BW_datamanagement.jpg

Source:SAP.

In this image you see an example how you could manage this. Basically you have different persistent objects that do or don’t reside in memory. Based on the usage you move the less used data to the warm objects. From these objects you get a flow to the near-line storage based on age and /or usage.

Performance

To be short. Run on HANA and hold on for dear life 😉

Basically SAP BW was a 2 tier system, which you had to manage carefully to keep performance. A lot of ABAP code was all about collecting a lot of data and changing it on the application layer. As a BW consultant you often used ABAP just to increase the performance a bit. For example before the improved master data lookup you actually avoided the standard transformation and used abap in the start routine to collect a lot of data in a variable so in the transformation youcould use an abap function to read the variable.

Now with BW on HANA everything gets pushed down from the application server to HANA. This means that for performance you are best of to avoid your own coding as much as possible. Standard transformations can be pushed down to HANA. Your own creations less so. For these the old transfer to application layer and back still goes.

In the presentation note 2063449 was mentioned. This note will tell you what has been pushed down and what is still to do. But as a rule of thumb develop like it is already pushed down, eventually it will be pushed down and if you already did it the right way you won’t have to redo it to get all the performance.

Planning

Also here a pushdown to HANA is taking place. The PAK should be feature complete now in comparison to BW-IP. Furthermore the FOX formula handling is improved and you can use a composite provider for planning scenario based on unions.

That you are also able to enter comments is a very nice feature. Customers for design studio are often asking for precisely this feature.

Conclusion

SAP BW is reinventing itself and focusses on its core function. Offering an application or business layer over your database. HANA is the driving force behind this by providing the heavy lifting needed. In the future more and more functions will be done on HANA itself. I am just wondering how they will balance between the customers on HANA and those on other databases.

To report this post you need to login first.

1 Comment

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

Leave a Reply