Standardization is a key aspect of SAP BW Layered, Scalable Architecture (LSA), SAP’s best practice in Enterprise Data Warehousing. One of the ways to realize standardization in the data staging process is developing generic, reusable ABAP building blocks with a comprehensive interface.
In every data flow we have to deal with the first inbound mapping of DataSource fields to InfoObjects within the transformation. Therefore, it makes sense to identify this process as a modeling pattern and use such a building block to facilitate the process. Let’s call it Mapping Services.
I developed a working version of the Mapping Services which I would like to share via a document. Implementing Mapping Services - Inbound Mapping of DataSource Fields to InfoObjects covers all details on creating the ABAP Objects classes, including the source code and all necessary ABAP Workbench objects.
Conceptual Overview
Although Mapping Services can be used in any data warehouse architecture, I will explain using this building block in the context of LSA. From a modeling perspective, the mapping can be time-consuming, difficult and error prone, especially if the DataSource contains many fields. This is often the case in an LSA context since it’s the best practice to extract all available fields. The transformation might turn out to be difficult to manage: it's hard to keep the overview and the transformation can easily become a spider web.
Mapping Services are positioned in the first LSA layer: the Data Acquisition layer.
Figure 1: Positioning in LSA (Source: SAP AG)
The DataSource delivers its data in the Persistent Staging Area (PSA). From here, the data staging in BW continues with an obvious requirement to map the DataSource fields to InfoObjects. Normally the inbound mapping is done manually within the first transformation: one has to map the various DataSource fields to the corresponding InfoObjects using the graphical user interface.
The following figure shows an example of an LSA compliant transactional data flow.
Figure 2: Mapping Services in the Data Flow
The red circle indicates where Mapping Services is implemented. The transformation is positioned between the DataSource and the Data Acquisition Layer outbound InfoSource. Note that this transformation is exclusively used for mapping DataSource fields to (Data Warehouse) InfoObjects.
Please refer to the following blogs of Jürgen Haupt for more information on LSA:
- SAP NetWeaver BW: BW Layered Scalable Architecture (LSA) / Blog Series;
- SAP NetWeaver BW: What is the BW Layered Scalable Architecture (LSA) all about?;
- SAP NetWeaver BW: BW Layered Scalable Architecture (LSA) Building Blocks.
You can also refer to SAP Help for more details on the Data Warehouse Concept.
Mapping Control Table
The mapping rules are stored in a central control table. You can find below some example mapping rules.
Table 1: Mapping Control Table
The first three columns uniquely identify the DataSource fields. The last two columns contain the InfoObject and the technical field name where the DataSource field should be mapped to.
Using Mapping Services in Transformation
This building block is realized as an ABAP Objects class. A public method has to be called in the transformation expert routine. You can see in the screenshot below the limited source code to be entered here.
Figure 3: Using Mapping Services in Transformation
All mapping functionality is provided by the class. The source package and result package are processed dynamically. The relevant mapping rules are fetched from the central control table. Any exceptions are handled appropriately: they terminate the process in a controlled way and fill the monitor log with information on the errors.
From an LSA perspective, the "real" transformations are concentrated in 2 places: Harmonization layer and Business Transformation layer. Here you will need the full transformation functionality. As you can see in figure 2, Mapping Services is encapsulated in the transformation from DataSource to Acquisition layer outbound InfoSource, i.e. before the Harmonization layer. The only function of this transformation is to map DataSource fields to (Data Warehouse) InfoObjects.
That's why an expert routine is used: the mapping is executed without any additional overhead. As a positive side effect, the performance will increase with 20 to 30% compared to a normal transformation (based on unofficial measurements).
The trade-off is that the mapping rules cannot be viewed on the transformation screen. However, it's possible to look at the mapping rules in the central control table. It's advisable to consider Mapping Services as a generic modeling pattern, to be used system-wide. Only then it will be transparent for everybody that you always have to look for the inbound mapping rules in the control table (with a filter on DataSource and Source System).
Conclusion
From an Enterprise Data Warehousing perspective, the process of inbound mapping DataSource fields to InfoObjects can be classified as a modeling pattern. The Mapping Services' ABAP building block and central control table with mapping rules are designed to standardize and facilitate this process.
Moreover, Mapping Services perfectly complements the Data Warehouse InfoObjects’ approach. The automated generation of InfoObjects based on DataSource fields can easily be extended to also fill the Mapping Services’ central control table in one go. The technical ingredients are exactly the same. The combination reinforces the power of this approach.
Please refer to my blogs Introducing Data Warehouse InfoObjects - Part 1: Conceptual Overview and Introducing Data Warehouse InfoObjects - Part 2: Technical Details for more information on the Data Warehouse InfoObjects’ approach.
Last but not least, please refer to my blog Generating Data Warehouse InfoObjects - Part 1: Introduction for more information on generating the Data Warehouse InfoObjects and the related mapping rules which can be consumed by Mapping Services.
- SAP Managed Tags:
