Steps to consider for Inventory Cubes (Non-Cumulative) during BW on HANA migration
Steps to consider for inventory cubes during HANA migration
- Inventory data load needs to be performed differently.
- As of BW 7.0, we have to compress the cube with respect to the marker.
- Instead of setting the flag for Marker update during the compression of an Info Cube, you now have to decide within the DTP (flag ‘Historical Transactions’) whether the records are treated to be historical transactions or deltas.
- That means the logic of the marker update had been pushed down to the data staging DTPs. Therefore, the flag ‘No Marker Update’ does not exists any longer.
- Compression of the Info Cube does not change the values of the reference points any longer. In principle, the calculation of non-cumulative in the query remains the same, but for the calculation of the current marker the system always has to take into account all movements (forward and backward calculation done during query
- In contrast to the non-HANA based Inventory Info Cube, the HANA based Inventory Info Cube has only one F fact table.
- You can check the partition in SE11 /BIC/DXXXX (Cube name)
Data Flow for Non-Cumulative cube
Extracting the inventory data:
following datasources are to be used in the extraction of an inventory scenario based on SAP ERP:
Material stock: Used to extract opening stock balance
Material movements: Used to extract material movement
- Initialization (2LIS_03_BX)
Once the filling of the setup table (MCNB) is finished, you can initialize the data upload for data-Source 2LIS_03_BX by starting the Info-Package in BW.
Extract Initialization records with Data-Source 2LIS_03_BX to PSA and start subsequent DTP for Initialization with the following info-pack setting.
- Historical Load
Once the setup table for 2LIS_03_BF is finished through the T-code OLI1BW in ECC, extract historic movements with Datasource 2LIS_03_BF to PSA
and start subsequent DTP for historic transactions (Delta DTP).
for historic transactions
- Delta initialization for
delta transactions can be extracted through the info-package till PSA.
the following setting to bring delta records on daily basis.
Difference between HANA based version and non-Hana based version of
Inventory data staging
Logic of ‘No marker update’ pushed down
Instead of setting the flag for Marker update during
the compression of an Info-Cube you now have to decide within the DTP whether
the records are treated to be historical transactions or deltas. That means the
logic of the marker update had been pushed down to the data staging DTPs.
Compression of the Info-Cube does not
change the value of the Initialization any longer. The concept of the previous
known reference point in infinity changed. Therefore the key figures of the
Initialization request remain unchanged during compression. This was completely
different before, as all the delta movements led to an update of the reference
No Marker Update in non-HANA based BW
There is no check box as “No Marker
Update” in HANA based BW versions
No ‘E fact table’ any longer
In contrast to the non-HANA based
Inventory Info-Cube, the HANA based Inventory Info-Cube has only one F fact
table. The fact table itself is partitioned having in total 4 partitions. The
purpose of the single partitions is summarized in Table 1: Partition purpose.
Partition (2) for Historical transactions
Collapse the Inventory Info-Cube
regularly to populate the relevant partitions.
Procedure to convert standard cube to HANA optimized
Transaction: RSMIGRHANADB (program
RSDRI_CONVERT_CUBE_TO_INMEMORY) or from Info-Cube maintenance:
After system migration to BW 7.3 on
HANA all Info-Cubes remain unchanged -> need to execute conversion to
After conversion Info-Cubes work w/o
disruption regarding data staging and querying (DB Changes are transparent to
- Compress the
Inventory Info-Cube regularly to populate the relevant partitions.
- All the request
should be compressed in the standard cube (Non-Cumulative) before migrating it to
- After conversion,
check if any transformation’s/DTP’s are inactive.
Conversion is executed as a Stored Procedure
within HANA and therefore shows an excellent performance.
Important SAP Notes