Data Warehouse InfoObjects can be defined as the data elements to populate the Data Warehouse layer of your Enterprise Data Warehouse. Please refer for a conceptual overview to my blog Introducing Data Warehouse InfoObjects - Part 1: Conceptual Overview. For SAP source systems it is advisable to take advantage of the structured and comprehensive ABAP Data Dictionary to generate these Data Warehouse InfoObjects. Please refer for more technical details to my blog Introducing Data Warehouse InfoObjects - Part 2: Technical Details.
I created an ABAP program to generate Data Warehouse InfoObjects for SAP source systems’ DataSources. This blog series explains how to use the program.
In Part 4 we will discuss how to optimize the results. Although the generation process is highly automated, from time to time a couple of manual interventions are necessary. Two typical examples are missing InfoObjects and missing key fields. This blog presents the way to handle these exceptions.
The blog series consists of the following blogs in addition to this blog:
- Generating Data Warehouse InfoObjects - Part 1: Introduction;
- Generating Data Warehouse InfoObjects - Part 2: Metadata Repository;
- Generating Data Warehouse InfoObjects - Part 3: Customizing.
I published the following 3 documents with detailed technical instructions how to create the ABAP program and all related objects:
- Implementing Data Warehouse InfoObjects - Part 1: ABAP Dictionary Objects;
- Implementing Data Warehouse InfoObjects - Part 2: ABAP Programming & Other Objects;
- Implementing Data Warehouse InfoObjects - Part 3: ABAP Developments in SAP Source System.
Missing InfoObjects
The majority of the Data Warehouse InfoObjects should be automatically generated and reused as designed. However, occasionally an InfoObject cannot be generated or reused. The application log will report such cases and manual postprocessing will be necessary.
Figure 1: Application log
The most frequent cause is that a particular data element is used more than once in the same extract structure. The program is not able to deal with this situation. The program uses the data element to generate an InfoObject and the metadata is stored in the respective metadata table. It cannot be stored more than once. Besides that, also the Template DSO cannot contain the same InfoObject more than once.
The solution in this case is to create a duplicate InfoObject manually. The easiest way is to create a new InfoObject with the generated InfoObject as template. Please note that you should avoid to create the InfoObject with reference.
Figure 2: Manually creating an InfoObject
It is advisable to use a separate set of InfoObject Catalogs so that the other InfoObject Catalogs are exclusively used for generated InfoObjects. The advantage of this way-of-working is that the InfoObject Catalogs and metadata tables can always be reconciled if necessary.
Figure 3: InfoObject Catalogs
Missing DSO Key Fields
A high-level analysis on SAP ECC and SAP CRM DataSources showed that approximately 40% of the DataSources have key fields specified. In such cases the program is able to generate a template DSO with corresponding key fields. For the other 60% of the DataSources the program will initially generate a write-optimized DSO.
Figure 4: Application log
It’s obvious that manual post-processing is necessary if key fields are missing. Hopefully you are able to determine the key fields via SAP Help. Otherwise, you have to identify the main table(s) and determine the key fields in another way, e.g. via a time-consuming SQL trace.
Protecting Mapping Rules
The advised way-of-working is to manually safeguard the manual enhancements in the Mapping Rules table YBWMAPPING.
Figure 5: Protecting enhanced mapping rules
The program normally deletes any existing mapping rules and generates new mapping rules. Without protection functionality, all manual updates will disappear. However, activating the Protect flag prevents deletion.
E.g. you can manually change the generated mapping rules which correspond to the key fields:
- Activate the Protection flag (field PROTECT);
- Activate the Key Field flag (field KEYFLAG).
Figure 6: Protecting a key field
After this the program can be executed again. It will from now onwards respect the “protected” mapping rules and is able to generate a standard DSO.
Conclusion
In this blog I discussed how to optimize the results. Occasionally, manual interventions are necessary. Two typical examples are missing InfoObjects and missing key fields. You learned how to identify these situations and how to post-process in such cases.
- SAP Managed Tags:
