In Solvay, the SAP can be divided into two main groups

1. SAP ECC (ERP Central Component) or ERP (Enterprise Resource Planning) such as PF1_020, WP1_400, and PI1_020  to keep the daily transaction from  Financials (FI), Material Management (MM), Sales and Distribution (SD). It is the data source of BW
2. SAP BW (Business Warehouse), such as WBP, load data from various source, including SAP ECC, to generate reports

Data flow from ECC to BW

SAP BW provides a high-performance infrastructure that helps you evaluate and interpret data. Decision-makers can make well-founded decisions and identify target-orientated activities based on the analyzed data. Also, by using HANA (in-memory technologies), you can enhance the performance of SAP BW. 

System Landscape of the main SAP systems

naming convention XXX_YYY

XXX = server name

YYY = client number

To connect to Talend

BW Layers

Layer

P = Propagation (normally same data as source without any change)

B = Business (apply business rules loading from propagation layer to specific application)

R = Reporting (same as business layer but with aggregate level eg. no document number - obsolete on LSA++)

V = Virtual (the view that combines tables, which mostly used to create query)

SAP BW Objects

All the object in Solvay, we have naming convention

Short summary

Note: this naming convention is apply only the customize objects. The standard object from SAP will start with 0 and it can be any objects.

1. InfoObject

Infoobjects are the smallest available information modules/fields in BW. It is needed in info-providers like InfoObjects, InfoCubes, DSOs, MultiProviders, Queries etc. These Info-Providers are made up of Info-objects.

InfoObjects can be classified into the following types:

• Characteristics (for example, customers)
• Key figures (for example, revenue)
• Units (for example, currency, amount unit)
• Time characteristics (for example, fiscal year)
• Technical characteristics (for example, request number)

Smallest InfoObjects will have only key. Then, we can add text, hierarchy, attributes, and compounding keys if we want.

InfoObject that add more infoObjects as attributes, normally, we do it for Master data that have more attributes such as customer

Table of the infoObject will have pre-fix :

Characteristic:
/BIC/P<InfoObjectName>     -- Master Data
/BIC/S<InfoObjectName>     -- Master Data IDs: SID table 
/BIC/X<InfoObjectName>    -- Attribute SID Table of the mater: 
/BIC/M<InfoObjectName>  -- Master data view (attributes)

Standard InfoObject will have name staring with 0 such as 0COMP_CODE, the table will start with /BI0/MCOMP_CODE (without 0)on the name

Text:

/BIC/T<InfoObjectName>  =  Name of of the key of the infoObject

Hierarchy:

/BIC/H<InfoObjectName>   = Hierarchy Table

/BIC/K<InfoObjectName>   = Hierarchy SID Table

/BIC/I<InfoObjectName>    = SID Hierarchy Structurer

2. DSO (Data Store Object)

It is a two dimensional Transparent Table which mainly stores consolidated and cleansed transaction data or master data on a lowest granularity

DSO has Overwrite and additive functionalities. If all characteristics are same, key figures are aggregated/overwritten based on the functionality chosen.

DSO Tables:
/BIC/A<dso_name>40  - New data table  (Activation queue - data will be deleted after activate the DSO)
/BIC/A<dos_name>00  - Active table
/BIC/B<random_number *dso_name*>  - Change log table
Standard DSO will have name staring with 0 such as 0COMP_CODE, the table will start with /BI0/MCOMP_CODE (without 0)on the name

Data Engineer should extract only activate table only

3. Cube

Cube is additive in nature. If all characteristics are same, key figures are aggregated. It can't be overwrite.

If we load data from ECC directly to a cube, the data will not change but it will aggregate by summation. The value will be incorrect.  This is why the data model it should load to DSO before Cube 

The structure of database will be star-schema, the real data will keep in Fact table but the fact table will keep only SID and each SID will linked to another dimension table. 

Data Engineer should not get cubes tables since it will be complicated.  Also, Cube is already obsolete in BW. We should use ADSO instead but Solvay don't converse the existing model to BW 4/HANA

4. ADSO (Advance Data Store Object)

This object is HANA object, which will replace on Cube, DSO.  It is the same DSO but the database structure will be column stored with in-memory technology

It can configure to be the same as DSO or Cube. 

ADSO tables:
/BIC/A<ADSO>1 inbound Table (new data)
/BIC/A<ADSO>2 Active data
/BIC/A<ADSO>3 Change log
/BIC/A<ADSO>6 View for extraction form datastore
/BIC/A<ADSO>7 View for reporting (datamart)

5. MultiProvider

A MultiProvider is a type of InfoProvider that combines data from a number of InfoProviders and makes it available for analysis purposes. The MultiProvider itself does not contain any data. Its data comes entirely from the InfoProviders on which it is based. These InfoProviders are connected to one another by a union operation as a view.

A MultiProvider can consist of different combinations of the following InfoProviders: InfoCube, DataStore object, semantically partitioned object, InfoObject, HybridProvider, InfoSet, VirtualProvider, and aggregation level.

6. Composite Provider

It replace MultiProvider in HANA. A CompositeProvider is an InfoProvider that which combines data from analytic indexes, or SAP HANA views or from other InfoProviders by Join or Union, and makes this data available for reporting and analysis.

Storing the data in the SAP HANA database or in BW Accelerator ensures faster access to data in the query. However, the object that will join to create composite provider, it must be only HANA object such as ADSO, calculation view.

7. Calculation View

A calculation view is a flexible information view that you can use to define more advanced slices on the data available in the SAP HANA database. Calculation views are simple and yet powerful because they mirror the functionality found in both attribute views and analytic views, and also other analytic capabilities.

For example, you can create calculation views with layers of calculation logic, which includes measures sourced from multiple source tables, or advanced SQL logic, and much more. A calculation view can include any combination of tables, column views, attribute views, and analytic views. You can create joins, unions, projections, and aggregation levels on its data sources.

8. Query

It is the report that end user will access by Analysis for Microsoft Excel. It is required to install in local PC to access the query. The query can have custom calcution and create new characteristic (member) as well.

What Object that Data Engineer need to Extract

The easiest way for DE to extract the data at the front end and get the same value as end user, it should extract from BW query to have all formula.  However, if we need to get sources data to GCP and build the logic in GCP, it is better to get from this decision flow.

Simple transformation means no abap coding (customize program) or a lot of formula in the query