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.
From an Enterprise Data Warehousing perspective, the process of Data Unification can be classified as a modeling pattern. The Data Unification Services' ABAP building block and central control tables are designed to standardize and facilitate this process.
In this blog I will discuss Data Unification Services, the concept behind it and how to use it in the transformation.
I published document Implementing Data Unification Services - Supplementing Administrative Characteristics which covers all details on creating the ABAP Objects classes, including the source code and all necessary ABAP Workbench objects.
Conceptual Overview
Data Unification in an LSA context is all about supplementing data records with administrative characteristics. Usually it concerns the following characteristics:
- Data Domain;
- Organizational Unit;
- Request ID;
- Timestamp;
- Origin.
Data Domain is related to domain partitioning or strategic partitioning and is applicable to transactional data flows. Please refer to my blogs Pattern-based Partitioning using the SPO BAdI - Part 1: Introduction and Pattern-based Partitioning using the SPO BAdI - Part 4: Use Cases for more information.
Domain partitioning is not always applicable: Data Acquisition Layer, Corporate Memory Layer and master data flows in general. In these cases it's transparent to assign data to domain 'X' (cross-domain and domainless).
Data Unification Services is positioned in the Harmonization & Quality Layer.
Figure 1: Positioning in LSA (source: SAP AG)
The following figure shows an example of an LSA compliant transactional data flow.
Figure 2: Data Unification Services in the Data Flow
The yellow callout indicates where Data Unification Services is implemented. The transformation is positioned between the Data Acquisition Layer outbound InfoSource and the Harmonization Layer Pass-thru DSO.
For other data flows it is slightly different. In master data flows the transformation is positioned between the Data Acquisition Layer outbound InfoSource and the Harmonization Layer intermediate InfoSource. In Corporate Memory flows the transformation is positioned between the Data Acquisition Layer outbound InfoSource and the Corporate Memory DSO.
Note that in all cases this transformation is exclusively used for Data Unification Services.
Control Tables
For transactional data flows the basic rule is that domain partitioning is applied. Data Unification Services needs help to be able to determine Domain and Organizational Unit automatically. Therefore we have to introduce 3 control tables.
Exclusively for transactional DataSources the following control tables have to be maintained:
- YBWUNISRC - Domain Driving Source Field DataSource;
- YBWUNIVAL - Value Assignments;
- YBWUNIREF - Reference Domain Driving Characteristic.
Table YBWUNISRC is always mandatory to be maintained for every new transactional DataSource. It is used to store the domain driving source field of the DataSource and the corresponding InfoObject.
Figure 3: Control Table - Domain Driving Source Field DataSource
Table YBWUNIVAL is used to store the value assignments. It has to be maintained less frequently since already existing value assignments can be reused. E.g. InfoObject Company Code and its characteristic values are already maintained. Every next DataSource can reuse these value assignments, there is no need to maintain them more than once. There might be a future need to maintain the entries if new Company Codes are introduced.
Figure 4: Control Table - Value Assignments
In some cases you might encounter that multiple InfoObjects are used for the same entity. In such cases it must be avoided that the value assignments are entered more than once. That is why the reference domain driving characteristic functionality was introduced. Table YBWUNIREF is used for this purpose.
Figure 5: Control Table - Reference Domain Driving Characteristic
Using Data Unification Services
Prerequisite for using Data Unification Services is the presence of the administrative characteristics in the target structure of the transformation. I.e. you have to add these characteristics to the DSO or InfoSource (depending on the data flow). The example below shows a DSO where you have to add the characteristics to the Data Fields section.
Figure 6: Adding Administrative Characteristics to DSO
The Data Unification Services building block is realized as an ABAP Objects class. One of the following public methods has to be called in the transformation (end routine or expert routine):
- EXECUTE_END - Execute Transformation End Routine;
- EXECUTE_END_X - Execute Transformation End Routine (Only Domain 'X');
- EXECUTE_EXPERT - Execute Transformation Expert Routine;
- EXECUTE_EXPERT_X - Execute Transformation Expert Routine (Only Domain 'X').
You can see in the screenshot below an example of the limited source code to be entered here.
Figure 7: Example of Data Unification Services in the Transformation
The source code can easily be inserted by using the appropriate ABAP Pattern. Click on push button Pattern, choose option Other Pattern and select the appropriate pattern in line with the type of routine (end routine or expert routine) and domain.
Figure 8: Inserting the Data Unification ABAP Pattern
The following ABAP Patterns are available:
- YBW_END_UNI - Execute Transformation End Routine;
- YBW_END_UNI_X - Execute Transformation End Routine (Only Domain 'X');
- YBW_EXPERT_UNI - Execute Transformation Expert Routine;
- YBW_EXPERT_UNI_X - Execute Transformation Expert Routine (Only Domain 'X').
All Data Unification functionality is provided by the class. The source package and/or result package are processed dynamically. The relevant information is fetched from the control tables. Any exceptions are handled appropriately: they terminate the process in a controlled way and fill the monitor log with information on the errors.
Conclusion
From an Enterprise Data Warehousing perspective, the process of Data Unification can be classified as a modeling pattern. The Data Unification Services' ABAP building block and central control tables are designed to standardize and facilitate this process.
In this blog we discussed Data Unification Services, the concept behind it and how to use it in the transformation.
- SAP Managed Tags:
