BW on HANAUseful Design Patterns

Kevin SmallMarch 2015 (kevin_small@hotmail.com)

Introduction

This presentation contains some useful BW design patterns applicable to BW-on-HANA scenarios with minimum version BW 7.4 SP8 and HANA 1.0 SP8.

Contents

Useful Patterns for BW Master Data

1) Activation-less loading of master data

2) Modelling navigational attributes of navigational attributes

3) Horizontal master data partitioning

4) Vertical master data partitioning

Useful Patterns for BW Transaction Data

5) Modelling lifetime to date key figures

6) Handling BW extraction and HANA Live replication of similar data

Useful Design Patterns for BW Master Data (I)

1) Activation-less Loading / Near-Real Time BW Master Data

This pattern allows loading of BW master data without an activation step. It can also be used to provide near real-time master data.

2) Navigational Attribute of a Navigational Attribute

This pattern allows modelling a navigational attribute of a navigational attribute.

3) Horizontal Partitioning of BW Master Data

This pattern involves partitioning master data records by e.g. Region. Each partitioned InfoObject has the same structure. Useful for very large master data, this pattern is similar to the logical partitioning of InfoProvider data.

4) Vertical Partitioning of BW Master Data

This pattern involves partitioning master data records by attribute. Each partitioned InfoObject has a different structure but they share the same key. Useful for template configuration where separate backend global / local master data designs are desirable, but they need viewed as one object in reporting.

Useful Design Patterns for BW Master Data (II)

All the master data patterns hinge on the new Virtual Master Data option in BW on HANA:

InfoObject ZWBS is what gets used in BEx Queries

HANA View CV_WBS is what does the work to prepare the master

data.

What allows for useful design patterns is how data is fed into here covered on the next 4 slides.

1) Activation-less Loading of BW Master Data

The ZWBS InfoObject gets its data from AT_WBS which is an attribute view over the native HANA tables underneath.

ZWBS

AT_WBS

Data provided by SLT can be near real time.The end result is that ZWBS offers near real time master data in BW, without requiring an activation step. Of course the data does not need to arrive via SLT, any method will do, and there is always no activation step once the data reaches the HANA tables.

Use Case Master data needs to be very up to date,

with near zero latency.

Benefits Master data is very up to date, with near zero

latency.

SLT

Native HANA Persistent Tables

2) Modelling Navigational Attributes of Navigational Attributes

The ZWBS InfoObject gets its data from CV_WBS which is a join over the generated Analytic views of the InfoObjects underneath.

InfoObject ZRESPPERResponsible Person Master Data

InfoObject ZWBS_COREMain WBS master data

InfoObject ZPROJECTProject Master Data

ZWBS

CV_WBS

Here we have the scenario where: Region is an attribute of Responsible Person ZRESPPER. Responsible Person is a attribute of Project ZPROJECT. Project is a navigational attribute of WBS ZWBS_CORE. We want to be able to use Region as a navigational

attribute of WBS.

This join can be modelled in the CV_WBS HANA model. This effectively gives us a navigational attribute of a navigational attribute.

Use Case Scenarios where you need a navigational

attribute of a navigational attribute (no time dependency).

Benefits Attributes dont need to be copied around. In the above

example in normal BW you might need to copy the Region attribute from ZRESPPER to the ZPROJECT master data, in order to expose it as a navigational attribute there.

join

3) Horizontal Partitioning of BW Master Data

The ZWBS InfoObject gets its data from CV_WBS which is a union over the generated Analytic views of the InfoObjects underneath.

InfoObject ZWBSASIARegion Asia WBS Elements

InfoObject ZWBSEURRegion Europe WBS Elements

InfoObject ZWBSUSARegion US WBS Elements

ZWBS

CV_WBS

The ZWBS* InfoObjects all have identical structures. This is similar to database partitioning.

Use Case Master data is very large, 100s of millions of

rows. Master data can be separated into logical

partitions, for example split by region or source systems.

Benefits InfoObject master data can be loaded, and activated, by

parallel independent process chains running on independent schedules.

Reports only needing one region will retrieve data from only one InfoObject (presumably? needs tested).

union

4) Vertical Partitioning of BW Master Data

The ZWBS_US InfoObject gets its data from CV_WBSwhich is a join over the generated Analytic views of the InfoObjects underneath.

InfoObject ZWBS_COREAttributes common to all regions. This is the core template WBS Element.

InfoObject ZWBS_US_LOCAttributes that are local to Region US

ZWBS_US

CV_WBS

The ZWBS* InfoObjects have different structures. ZWBS_CORE is the core template InfoObject with attributes common to all regions. ZWBS_US_LOCcontains the localisations, so attributes specific to just the region US. The InfoObjects have the same key (so they can be joined) but have different attributes.

Use Case Deployment of BW template configuration,

where InfoObject has many rows and localisations should be supported.

Benefits The ZWBS_CORE InfoObject is owned and transported in

from a template system, whilst localisations can independently be added to ZWBS_US_LOC.

In cases where master data volumes are large, there is minimum redundancy, data is not stored twice.

join

Useful Design Patterns for BW Transaction Data

5) Modelling Lifetime to Date Key Figures

Sometimes inception to date or lifetime to date key figures are required in reports over document transaction data. To produce these key figures, every document must be read and aggregated across the whole of time. This could be expensive in terms of memory cost, this design pattern describes an alternative solution.

6) Handling BW Extraction and HANA Live Replication of Similar Data

There is a design challenge when the same source ECC data is extracted via HANA Live/SLT and via normal BW extractors. There is redundancy if the same data comes into BW via two different routes. This design pattern explains the problem and a possible solution for certain cases.

5) Modelling Lifetime to Date Key Figures

Say we have a lifetime to date key figure, to calculate it we must sum every transaction from all of time. It is only viewed in reports at an aggregate level.

Semantically Partitioned Object (SPO) is partitioned by year. Generated SPO Partition DSOs contain year data each.

Data is moved to memory if it is used. See http://scn.sap.com/docs/DOC-49992 How and when HANA SP7 loads and unloads data into memory. For the current year most fields are likely to be kept in memory if a lot of reporting is being done.

But for prior years, only the columns needed to report the lifetime to date key figure are in memory. Other key figures and characteristics from prior years are held quietly on disk, in compressed format.

Column held in memoryColumn held on disk

Use Case Lifetime to date or inception to date key

figures, where a single key figure must be summed across every transaction document for all of time.

Benefits In a non-HANA BW system, there may be a temptation to

model this by adding a bespoke balance carry forward process. In a BW-on-HANA scenario the above described solution means no such additional process is needed, and memory use is still kept to a minimum.

2015

2014

2013

SPO

Partition DSOs

6) Handling BW Extraction and HANA Live Replication of Similar Data

Consider the case where a BW-on-HANA system also has HANA Live installed. A traditional BW flow would take e.g. FI-GL data from ECC, pass it through some layers and report from BEx. If HANA Live is also present, then the same FI-GL tables might already be replicated into HANA.

To avoid this redundancy, the traditional BW flow could be replaced by an alternative BW flow.

The critical part is that the business logic used in the traditional BW flow needs replicated in HANA models in the alternative flow. In some cases this may not be easy, or possible, so this design pattern is not always applicable*.

Use Case BW on HANA systems where HANA Live is also used.

Benefits Avoid redundantly extracting the same data twice into

the HANA system.

SLT

Composite Provider

BEx QueryBEx Query

HANA Table copies of BKPF BSEG etc

HANA Models

BKPF BSEG etc

BW on HANA

ECC

Traditional BW Flow Alternative BW Flow

Inbound DSO

FI-GL DataSource

Business Logic

HANA Live

Business Logic

Business Logic

DSO

* A further wrinkle is that there may be multiple architected data marts using FI-GL data, and they may depend on deltas flowing into them. These would also need addressed, either by generating deltas, or also replacing them with HANA models.

Disclaimer

As far as possible these design patterns have been tested using BW 7.4 SP8 on HANA 1.0 SP8.

Not everything described could be tested, so there may be limitations on some patterns in real-world scenarios (e.g. performance).