Product Information
Layers shift – Modelling approach SAP Data Warehouse Cloud & SAP BW bridge
With SAP BW bridge as a feature on SAP Data Warehouse Cloud, we have implemented a solution, that provides a path to the public cloud for SAP BW NetWeaver & SAP BW/4HANA customers in an easy way.
You can leverage SAP BW data structures, transformations, customizations, and skills – quickly extending your SAP BW investments to the public cloud. Beside of this, you can Empower your business to rapidly innovate on BW data with an open, unified data & analytics cloud service – scaling innovation and efficiency in the cloud.
Concrete offerings of SAP BW bridge with SAP Data Warehouse Cloud:
- Connectivity & Business Content
Providing proven SAP BW-based data integration (Extractors) from SAP ECC and SAP S/4HANA via SAP-ODP
- Enterprise-ready staging layers of SAP BW
Integrate on-premises SAP Business Suite data with familiar connectivity and semantic richness – retaining instant access while expanding your analytics depth
- Tool-supported move of SAP BW-based integration and staging
SAP Data Warehouse Cloud – BW bridge
Modelling approach SAP Data Warehouse Cloud & SAP BW bridge
A classic modeling approach in the context of SAP BW was always LSA/LSA++. Within the public cloud, however, there are completely new possibilities and a rethinking of the modelling is required.
As mentioned above, SAP BW bridge is a Staging Layer with all the modeling capabilities from SAP BW/4HANA. You should follow the same Layered modeling approach like in SAP BW/4HANA, an Operational Data Store Layer (Inbound Layer) and a Propagation/Harmonization Layer should be implemented.
The Architected Data Mart Layer as well as the Virtual Data Mart Layer on the other hand, should be moved from the classic SAP BW world to SAP Data Warehouse Cloud Core itself. Those layers will be managed in SAP Data Warehouse Cloud Core as federated Remote Tables based on the Propagation-/Harmonization Layer.
The corresponding Views on top of the Remote Table in the target Space should be persisted and used as the basis for reporting in SAP Analytics Cloud.
Layers Shift – SAP Data Warehouse Cloud Core and SAP BW bridge
Important to understand is, that you are not doubeling the data between SAP BW bridge & SAP Data Warehouse Cloud Core.
The new type of modeling approach also has the potential to concentrate on data which is relevant for reporting and optimize the performance of data consumers on top like SAP Analytics Cloud.
Layers concept:
SAP BW – bridge – Operational Data Storage
From a business point of view, the BW entry layer in the LSA++ for SAP BW∕4HANA on is a purely passive layer best described as the acquisition layer. The role of the acquisition layer is to meet the prerequisites for consistent processing of data in the Data Warehousing Architecture by implementing BW requests:
The data acquisition layer takes the data from the source – logged and checked by request, package, and record number – and distributes it in the SAP BW bridge system. The layer allows you to consistently fill all targets separately from each other, and even at different times.
SAP BW bridge – Propagation & Harmonization
The data propagation layer serves the persistent architected data marts and is a basis for the Virtual Data Mart Layer.
The data is saved and consolidated in standard DataStore objects (advanced) and in InfoObjects.
SAP BW bridge – Architected Data Mart –> Moved to SAP Data Warehouse Cloud Core
In the LSA++, the system initially always tries to satisfy the requirements based on the Propagation Layer and the Virtual Data Mart Layer. A persistent architected data mart layer is only built if the service level and/or business requirements cannot be fulfilled.
SAP BW bridge – Virtual Data Mart Layer –> Moved to SAP Data Warehouse Cloud Core
The objects can be used to model star schemas, associations between facts and master data, and master data with texts.
SAP Data Warehouse Cloud – Data Builder Artefacts:
Remote Tables are the inbound artefact in SAP Data Warehouse Cloud which offers federated as well as replicated access to the source. With SAP BW bridge, you can use federated access if the performance works well. If your report on top of SAP Data Warehouse Cloud is not performant, you should replicate the data.
Analytical DataSet is used to leverage selected attributes and measures from the Remote Table and can be enriched with Dimensions. Analytical Datasets can be used for reporting in SAP Analytics Cloud.
The NEW Analytic Model (currently available under controlled release) will replace the analytical dataset which is exposed for consumption. Analytical datasets will continue to exist, but you should now use the analytic model instead.
The analytic model offers more calculations and greater functionality. You can prune what you want to expose in your object, thus avoiding unnecessary calculations and in turn achieving a better performance. It also offers calculated measures and restricted measures, and an analytical preview.
Checkout also the Entity Import & Model transfer for SAP BW bridge in SAP Data Warehouse Cloud.
Relevant and interesting Links:
Getting Started With SAP Data Warehouse Cloud, SAP BW Bridge
Using SAP BW Bridge in SAP Data Warehouse Cloud
Acquiring and Preparing Data in the Data Builder
Please let me know, if you have any detailed question regarding the the new modelling approach in our public cloud offering.
Regards
Dominik
Thanks for the good blog.
When new data is loaded into ADSO in the Propagation & Harmonization Layer, it would be nice if there was a function that could automatically perform View Persistency of ADS in the DWC.
Thanks for the feedback.
Currently we have a little bit another approach, we are triggering the process from SAP Data Warehouse Cloud Core in the Entity Import for SAP BW bridge where you have to select a tagret Space for the ADS. In your approach, it would be the other way around.
Dear Dominik,
now that the Analytic Model & Fact have fully taken over the role of the Analytical Dataset in SAP Datasphere data layer - which of the two artifacts do you recommend for a persistence in SAP Datasphere?
Is it rather the Fact or better the Analytic Model?
Thank you
Frank
Layer Shift Architecture