Page History

In Place LSA Architecture for Solvay 

LSA approach with standardized design and structured data area into multiple layers is still the reference architecture to design consistent, complete, comprehensive DWH for Solvay.

LSA Principles applied by Solvay for his BW are still relevant in a BW running on HANA context, this architecture focus on Performance and Governance: Data Quality, DataOnwnership, Service Level…

However, as volume of information is particularly important for SAP HANA (RAM Based approach) and as HANA brings BW new performances concept and capacibilities current BW Modeling must be adapted to get use of HANA BW features:

• reducing number of persistent provider
• optimizing design and implementation of persistent provider
• reducing change impact on persistent provider.

Extended EDW and LSA ++ Concepts

LSA++ is the next logical step from LSA (Layered Scalable Architecture) based on the new technical possibilities provided by SAP HANA Database capabilities.

One of the major areas is the possible lower number of layers (simplification), but also the different access to the data.

LSA++ provides increased modelling flexibility, mixing BW and SAP HANA studio capabilities, decreasing load and activation time. Approaches which were technically not possible before are now possible with LSA++.

Image Added

With BW powered by HANA completely new options became available from an LSA perspective with regard to how to implement a BW EDW. The in-memory capabilities of HANA enable BW to expand it's focus to a more open logical architecture with less persistence and even more flexibility and scalability. The LSA++ is the reference architecture for implementing an EDW with BW powered by HANA. With LSA++ for BW on HANA there are huge opportunities developing the BW EDW further into a holistic data framework for consistent BI on the EDW, operational and agile BI.

Two challenges are building Time to Market Application and providing Real Time data where needed, like in operational reporting area.

Image Added

Data Modelling Objects in BW on HANA

The following objects are to be used in place of the old objects types

Image Added

1.       Advanced Data Store Object (ADSO): It is the central modeling object in SAP BW. ADSO is poised to replace all physical InfoProviders that used to store data in older versions of BW (likes of DSO, InfoCubes). 

• Compared to classic DSO, the ADSO provides faster activation and load times.
• It can be deployed in various layers of the LSA++ architecture.

2.       Composite Provider: Since the release of SP8 and BW 7.5 SP1, it has re-evolve completely to support the new modeling options. Composite Provider is an InfoProvider that combines data from both worlds (BW native models and HANA based views).

• Combine data from other HANA based applications on the same instance of HANA with data from BW
• Supports Unions and Joins
• Central interface for BW Queries
• Faster and simpler data modeling - successor to MultiProvider and InfoSet
• Reduce database size: virtual modelling capabilities as opposed to data flows
• Supports usage of inventory key figures and planning scenarios

3.       Open ODS Views: it enables one to define BW models for objects like database tables, database views, or BW DataSources (for direct access). It provides flexible integration without the need to create InfoObjects. The biggest benefit is its ability to consume external data sources into BW without the need for a separate BW persistence for the data.

• Virtualized access to various sources through SAP HANA Smart Data Access
• Flexible and easy integration of external data models
• Ability to switch from virtual to persistent mode.

LSA ++ Detailed Implementation for Solvay

Big Picture of LSA ++ implementation: A mix Modelling HANA Studio Approach is implemented.

Golden rules for modeling and data lineage are:

• Acquisition Layer  = Propagation Layer with Data Storage using ADSO : ADSO Field Based; write optimized option + cold zone (not in memory in SSD only) + no infoobject = field only (for example keep field coming datasouce  werks and not BW infoobject C_PLANT) + need to data cleaning (recurrent mode) + source system management
  
  
• Corporate Memory (used only if source system is archived and if there is a need of strong data recovery capabilities : Use of ADSO  image of Acquisition Layer.In this Layer, ADSO must be identical to ADSO of Acquisition Layer in terms of Keys. => No need for Solvay (WBP or WPX system)
  
  
• Enterprise Data Warehouse = Business Layer : Business Rules are Applied Here for storage part. Consist of ADSO Object for which and external SAP HANA View might be generated
  • → Propagation 1-1 from acqusition, key data + infoobject in the ADSO (for the reporting) + general rules example K4 fiscal period + conversion of date  → wait to take decision (only fields of key and infoobjects)
    → Business layer : + layers of Business as today, dedicated by application.
  • last level could be only the current & last year + another ADSO with all years (but need to put a limit max 5-8 years)
    
    
• Virtual Datamart Layer: This Layer consist of SAP HANA Artifacts, based on generated SAP HANA Views for ADSO. SAP HANA Artifacts are consumed in SAP BW using Composite providers for which each HANA Field is mapped with an Infoobject 
  
  
• SAP BW Queries are created on SAP Composite Providers. In some cases, a generated SAP HANA View bases on Query can be provided with some restrictions documented

Hence for any new project or important maintenance developments, the following level are to be used:

Image Added

The following infoareas & Hana packages are to be created

Level 1 : RAW Data acquisition = Propagation layer

DSO and nothing are done on the transformation between Datasource and this DSO (1 to 1 and no business transformation rules) because it could be the source for several project

This level can be build upon field (and not infoobjects)

Level 2 : Enterprise datawarehouse = Business Layer

DSO or several level of DSO if the transformation are complex and if data is to be historised

Level 3 : Virtual layer – application datamarts & application reporting

Hana views / Open ODS view

Composite providers  (based on union of DSO or Hana views)

Queries based on composite providers or Hana views based on queries (in exceptional cases)

 Level 4 : Open Hub Destination

In this level all open hub destination linked with composites , ADSO or queries based related to the infoarea will be stored.