Modelling in LSA++

Transform classic LSA Data Models in LSA++ 

Data Models for BW/4HANA

With BW/4HANA the number of modelling object types was reduced from 10 to 4. That means common objects like the InfoCube, MultiProvider or PSA table are not available any more. Complex data structures like the star schema are obsolete with HANA’s row based in-memory technology.

For modelling data flows SAP raises the new Layered Scalable Architecture++ (LSA++) into orbit as extension to the classic LSA. The LSA defines an implementation standard for separation of data of different maturity level. It offers best practice guidelines for so called layers as well as services provided by them.

The LSA++ is an extension of the classic LSA specific for SAP BW on HANA systems. The three most important advantages of LSA++ are:

1. The number of redundant objects is reduced means less memory consumption.
2. The administration effort is reduced.
3. Data models are more flexible.

For global BW system landscapes following the classic LSA principles the transformation to LSA++ in combination with a HANA DB can be done in two steps:

1. Mapping of existing objects
2. Simplify the data flow

1. Mapping of existing objects

The mapping of old objects to a BW/4HANA objects is provided by SAP. It offers a migration tool to transfer an existing data flow to a HANA data flow. The t-code is RSB4HTRF.

© 2016 SAP AG. All rights reserved.

2. Simplify the data flow

The second step is the more interesting step. Here the real simplification takes place. I give you a bunch of transformation mappings to use.

Mapping 1:

The starting situation is a 1:1 transformation to the Architected Data Mart layer from the Business Transformation Layer. In LSA++ the Business Transformation Layer can be omitted. The reporting-optimized InfoCubes are no longer supported in the BW/4HANA architecture.

Mapping 2:

This is similar to Mapping 1. For a 1:1 transformation in the business transformation layer, the Architected Data Mart layer can be omitted. The ADSOs are directly consumed by the CompositeProvider.

Mapping 3:

In the case of simple merging scenarios in the business transformation layer (for example, fields from Status are required in the Order Item), the business transformation layer and the architected data mart can be omitted. Merging scenarios can be represented by a JOIN in the CompositeProvider.

Mapping 4:

The PSA as an input object is no longer supported with a BW/4HANA architecture. The input data can be loaded into a write-optimized ADSO. The field-based structure allows the ADSO to be generated automatically according to the structure of the data source. The write-optimized ADSO also serves as a corporate memory.