Latest news

You can edit the content of this box by changing the 'description' custom option for the page or post.

Getting your head around SAP BW and HANA – a new development approach

Emily Kucukalic Tuesday, October 10, 2017 Blog

As more businesses get ready to make the move to SAP BW on HANA or BW/4HANA (and for those who already have), in this blog we review a great way for you to adopt HANA data modelling into your BW development approach. It is one of several so-called “Mixed Scenarios” which SAP are happy to promote as a good way to get the best of both worlds and we agree that it is a good way go!

Traditional BW Modelling Approach:

In a very generalised summary, the traditional approach to building a BW model involves:

  1. Gathering business requirements
  2. Coming up with a design for the data flow (and reporting)
  3. Building a BW solution to acquire, transform and stage the data with 1 or more final providers for reporting
  4. Adding a virtual provider over the top (eg. Multi-provider), then create queries & reports

Modelling is all done in the BW application. In BW transformations you will need to include rules and filters, if these are complex it will likely involve ABAP coding. The development effort will be largely dependent on overall complexity and the number of data sources, dimensions, measures and calculations involved. Data may be persisted in the BW database several times along the way as original source data, staged data and the final reporting data. There is nothing wrong with this traditional approach, it is just what is needed to build your solution.

Considerations for BW on HANA

When you move to BW on HANA or BW/4HANA one of the key differences you need to get your head around is the fact that you really now have 2 systems instead of 1. The first is the BW application which is just an improved version of the BW you have always known and loved. The other is the HANA platform itself. HANA is more than just a database and has the ability to be used directly for many things, including virtual information modelling (and potentially as a complete data warehouse in its own right). Because HANA runs an in-memory database, we are obliged to think differently about how we design BW data models used in reporting. There are 3 main objectives we suggest should be considered:

  1. Make the most of the HANA platform by doing as much processing as possible directly in the HANA platform, because it will be faster and more efficient.
  2. Avoid data redundancy. If we persist the same or similar data in several places then that data redundancy means we are using up memory unnecessarily.
  3. Use the new BW modelling tools because they will make the development process faster and easier (and with BW/4HANA they are mandatory :))

The Scenario:

SAP have branded the term “mixed scenario” for any data modelling approach that uses a combination of the BW application and HANA platform in a way that makes the best use of both. There are several use-cases. Here we will focus on just one in particular;

  • Assume you have used BW for several years and therefore you already own an SAP BW data warehouse that hosts a wealth of information. You are going to migrate your BW system to HANA and want to continue reporting through the BW application for all the advantages it offers, but also want to adopt the best use of HANA as part of your BW development strategy. BW end users should continue to use BW without any obvious impact from HANA other than faster reporting. Is there a development strategy we could adopt to make the best use of both BW and HANA that also delivers advantage?

The Solution:

In this solution, steps 1,2 and 4 from the traditional approach above don’t change that much. But for step 3 which is the build of your BW model, a new development approach can be suggested as follows:

  • First ensure that all the data you need is available through the HANA database (depends on ETL but could already in BW/DSO tables as shown in diagram above or directly imported into HANA or virtual tables via SDA connection, etc.)
  • You design & build a HANA information model. This is akin to building a BW dataflow except you are using the HANA modelling tools and the end result will be a virtual model without any data persistence. This effectively replaces the propagation and reporting layers in the traditional approach.
  • The equivalent steps of BW staging and transformations are all created in the HANA model – mostly using joins, unions and calculated fields inside views. Where rules are more complex, functions or procedures can be written in SQL and used in the model.
  • A final HANA view is created which has equivalent structure to the final cube in the BW model, ready for consumption.
  • You connect the final HANA view back to BW using an Open ODS view or Composite Provider (new BW tools). Where appropriate, fields are mapped to BW infoobjects.
  • You create bex queries and reports over your Open ODS view or Composite Provider. These will effectively work like any other info provider – but under the covers everything is running in the HANA model.
  • Keep in mind the approach described above is just one of several ways to handle mixed scenarios but very suitable for an established BW customer. Your situation may differ, so it is worth considering other mixed scenarios use cases too.

Why Should You Adopt This Approach?

Our belief is that this approach has the following advantages:

  • It satisfies the 3 objectives stated earlier – shifts processing to HANA, removes need for data persistence, uses new BW tools
  • Development effort is simpler & faster and involves less coding than traditional BW transformations. HANA models are built graphically, mostly using calculation views. Easier to understand and support.
  • Your BW developers will adapt to the new practice fairly easily but will need to learn HANA modelling technique and best practice. Concepts are the same but the way of achieving a solution is quite different from BW and generally easier to achieve.
  • The modelling skills acquired by your BW developers can also be used in any of your other HANA-based systems and of course any information models will run directly on tables that are being updated real-time.
  • You have direct access to all your existing BW data since it is already in tables in the HANA database but can also use any other data stored directly in the HANA database.
  • You get the advantage of using your existing BW OLAP engine so from a reporting perspective there is no change in approach eg. existing master data attributes and hierarchies can all still be used. End users are unaffected.
  • You should find at run-time that reporting is faster! Because by pushing all the data processing down to the HANA layer you are fully optimising everything (depending on many factors of course – eg. volume, complexity, processing power, using best practice modelling design).

If you want to talk more about your development approach, SAP BW and HANA or the SAP BI landscape you can contact me here

Andrew Rankin – SAP BI Consultant at Plaut

Andrew is an SAP enthusiast with a passion for understanding data and the pursuit of common sense solutions.

Find more about Andrew here

Leave a Reply

Your email address will not be published. Required fields are marked *