With SAP BW bridge as a feature on SAP Datasphere, 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.
Providing proven SAP BW-based data integration (Extractors) from SAP ECC and SAP S/4HANA via SAP-ODP
Integrate on-premises SAP Business Suite data with familiar connectivity and semantic richness – retaining instant access while expanding your analytics depth
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 Datasphere Core itself. Those layers will be managed in SAP Datasphere 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.
Important to understand is, that you are not doubeling the data between SAP BW bridge & SAP Datasphere 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.
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.
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.
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.
The objects can be used to model star schemas, associations between facts and master data, and master data with texts.
Remote Tables are the inbound artefact in SAP Datasphere 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 Datasphere 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 Datasphere.
Getting Started With SAP Datasphere, SAP BW Bridge
Using SAP BW Bridge in SAP Datasphere
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
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 Datasphere:
- 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 Datasphere - BW bridge
Modelling approach SAP Datasphere & 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 Datasphere Core itself. Those layers will be managed in SAP Datasphere 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 Datasphere Core and SAP BW bridge
Important to understand is, that you are not doubeling the data between SAP BW bridge & SAP Datasphere 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 Datasphere 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 Datasphere Core
The objects can be used to model star schemas, associations between facts and master data, and master data with texts.
SAP Datasphere - Data Builder Artefacts:
Remote Tables are the inbound artefact in SAP Datasphere 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 Datasphere 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 Datasphere.
Relevant and interesting Links:
Getting Started With SAP Datasphere, SAP BW Bridge
Using SAP BW Bridge in SAP Datasphere
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
- SAP Managed Tags:
3 Comments
