BW/4HANA Architecture – Architectural proposal
In this video I describe in German one from my point of view lean and clear architecture for BW/4HANA. On the one hand, this consists of avoiding ABAP routines in transformations, on the other hand, layers should be used with determination and freed from any unnecessary ballast.
Avoiding ABAP (in transformations) by on-board means:
Transformations can be performed optimally for HANA by activating the check box within the transformation ‘SAP HANA processing possible’. In this case, the logic stored in the transformations is processed directly on the HANA DB, eliminating the need for a data roundtrip between the database server and the application server. This requires the strict avoidance of ABAP coding in start / end and expert routines.
The processing logic must therefore use BW/4HANA on-board resources, which is:
– Master Data Read
– Reading from the Advanced DSO
– Use of the formula editor.
If this is not the case, i.e. if ABAP coding is used, the application server has to deliver the processing to the row-based engine of the S/4HANA. The use of the column-based in-memory engine is not supported (data movement).
Use of lean and dedicated layers in BW/4HANA architecture:
A BW4/HANA architecture is more than just pushing the processing logic into the HANA DB. The layers must be largely tidy and be used decidedly.
a) The layers:
Obligatory is the Virtual Data Mart Layer (VDM), the EDW Layer (Enterprise Data Warehouse Layer, consisting of the Propagation Layer) and the DAL (Data Acquisition Layer).
There are 2 optional layers:
- The ADM layers (Architected Data Mart Layer, consisting of the Aggregated Data Mart Layer, formerly Reporting Layer, as well as the BTL, Business Transformation Layer.
- The QHL (Quality and Harmonization Layer) which extends the EDW Layer next to the Obligatory Propagation Layer.
b) Purpose binding and the properties of the layers
1.) DAL: The DAL contains exclusively field-based advanced DSOs (ADSO). The data sources are loaded directly into an ADSO with the source system type ODP using a data transfer process (DTP) and there is no persistent staging area (PSA). The connection of the Datasource (DS) to the DAL-ADSO is thus provided with a 1: 1 transformation.
2.) QHL: The QHL layer is used as an optional layer if technical manipulation is needed and persisted, such as special character removal or the harmonization and concatenation of keys.
3.) Propagator: InfoObjects and InfoObject-based ADSO’s represent the single point of truth in the propagator. There is only one delta loading.
4.) BTL: The BTL contains only infoobject based ADSOs. Basically, the propagator will be the last physical layer that provides the data for the VDM layers. However, if the propagation layer is too inoperative for reporting, or if special business requirements require complex computation / data links, such as the conversion from a measure model to an account model, BTL will provide the data in its physical infoproviders for the VDM. These should be ADSOs or, for non-migrated or optimized applications, HANA optimized InfoCubes.
5.) VDM: The VDM layer consists only of composite providers that contain objects of the EDW or ADM layer. Queries are created exclusively on composite providers. Whenever possible navigation attributes should be used.
c) The data channels over the layers, keep it simple
In the picture we see all conceivable possibilities of modeling. An ADSO serves 1: n ADSOs in the higher level and 1: n ADSOs could supply n: m ADSOs at the level above.
Shielding Infosources do not have to be used for self-purpose. It is important to avoid any unnecessary complication.
The VDM layer uses the physical InfoProviders of the ADM layer or the propagator. The DAL with its field-based ADSOs represents a 1: 1 correlation of the connected data source.
Since queries are already being read out on the VDM layer, workspaces or HANA views authorized on the fly that can be consumed via open ODS views are, in my opinion, unnecessary.