In an Enterprise Data Warehousing context, InfoObjects often play an arbitrary double role: they are used for modeling the Data Warehouse Layer and multi-dimensional modeling the Reporting Layer. In my blog Introducing Data Warehouse InfoObjects - Part 1: Conceptual Overview I advised segregation of duties by introducing a dedicated, independent set of InfoObjects: Data Warehouse InfoObjects.
But how about those Reporting InfoObjects? Should we simply activate all the Business Content InfoObjects we need? Or do we have to introduce our own set of InfoObjects, customized and fit to the Business Users’ requirements? Or a combination of both? In this blog I would to like to present an alternative approach.
I created an ABAP program to generate Reporting InfoObjects based on Business Content. This blog series explains how to use the program. In Part 3 we will have a look at the generation of attributes and “unluckily” generated technical names. Furthermore, we have a look at some special features which are not covered by the program: Master Data Read Class, geographical attributes and Transfer Routine. Manual postprocessing might be necessary here. Finally, we have a look at manually created InfoObjects and migration.
The blog series consists of the following blogs in addition to this blog:
- Generating Reporting InfoObjects based on Business Content - Part 1: Introduction;
- Generating Reporting InfoObjects based on Business Content - Part 2: Metadata Repository & Customizi....
The document Implementing Reporting InfoObjects based on Business Content provides detailed technical instructions on how to create the ABAP program and all related ABAP Workbench objects.
Generation of Attributes
For Characteristics, generation of attributes needs some explanation. The following 4 cases can occur:
- Characteristic has one or more attributes which are generated;
- Characteristic has one or more attributes which are not yet generated;
- Characteristic is referencing another Characteristic which has one or more attributes;
- Characteristic does not have any attributes.
The program evaluates the field Attributes Generation Status in the central Metadata Repository table YBWREPIOBJ to decide what to do. Next to that, an administrator can also use it for informational purposes. E.g. to determine for which Characteristics no attributes have been generated yet.
Figure 1: Attributes Generation Status
The first case corresponds to status ‘X’ (Attributes generated). The second case corresponds to status ‘ ’ (i.e. blank; Attributes not yet generated). The third case corresponds to status ‘R’ (Attributes via Reference Characteristic). The fourth case corresponds to status ‘-’ (Attributes not applicable).
Note that status ‘-’ (Attributes not applicable) is also used for Units and Key Figures.
Only in case 2 (i.e. status “Attributes not yet generated”) the program is able to generate attributes retrospectively. Prerequisite is that the Characteristic is on the highest level. A common approach is to process these Characteristics selectively using the “InfoObjects only” mode of the program.
"Unluckily" Generated Names
Generally speaking, the generated technical names of the new Reporting InfoObjects are recognizable and meaningful acronyms. However, there are some cases where the generated technical name is a bit “unlucky”. This is due to limited length of 9 characters in a normal situation, e.g. with a customer namespace ‘R’.
Some random examples:
- 0DBADDRES1 will generate RDBADDRES;
- 0DBADDRES2 will generate RDBADDRE1;
- 0DSCT_DATE1 will generate RDSCTDATE;
- 0DSCT_DATE2 will generate RDSCTDAT1;
- 0GL_ACCOUNT will generate RGLACCOUN.
The first 4 examples show that the numeric suffix at the end of the name is not respected at the moment. An enhanced algorithm for generating the technical name will certainly pay off here. I am planning to implement it in a future version of the program.
The last example is hardly to prevent and might even depend on someone’s preference. In such a case a manual intervention is the only solution.
The suggested approach consists of 3 steps (based on the 0GL_ACCOUNT example):
- Manually create a new InfoObject (e.g. RGLACCNT) as a copy of the generated InfoObject RGLACCOUN (as shown in figure 2);
- Modify the central Metadata Repository table YBWREPIOBJ to reflect the new assignment (0GL_ACCOUNT should refer to RGLACCNT);
- Delete the unused InfoObject RGLACCOUN.
Figure 2: Create new InfoObject based on Template
I recommend to create the new InfoObject in the same InfoObject Catalog. This way it remains possible to reconcile the central Metadata Repository table YBWREPIOBJ with the corresponding InfoObject Catalogs.
Master Data Read Class
The feature of master data read class is not covered by the program. This functionality can be found in 227 Characteristics (SAP NetWeaver 7.3 BI Content 7.37) on the Master Data/Texts tab. E.g. it can be found in Characteristic 0CRMSACTF.
Figure 3: Master Data Read Class (1)
The program will show appropriate warning messages in the application log. It’s up to you to recreate such a Master Data Read Class using the new Reporting InfoObject.
Figure 4: Master Data Read Class (2)
Geographical Attributes
The feature of geographical attributes is not covered by the program. This functionality can be found in 48 Characteristics (SAP NetWeaver 7.3 BI Content 7.37) on the BEx tab. E.g. it can be found in Characteristic 0CUSTOMER.
Figure 5: Geographical Attributes (1)
The program will show appropriate warning messages in the application log. It’s up to you to activate this functionality.
Figure 6: Geographical Attributes (2)
Transfer Routine
The feature of Transfer Routine is not covered by the program. This functionality can be found in 23 Characteristics (SAP NetWeaver 7.3 BI Content 7.37) on the General tab. E.g. it can be found in Characteristic 0DOC_CATEG.
Figure 7: Transfer Routine (1)
The program will show appropriate warning messages in the application log. It’s up to you to activate this functionality using the new Reporting InfoObject.
Figure 8: Transfer Routine (2)
Manually Created InfoObjects
We have seen that the program stores the generated InfoObjects in a dedicated set of InfoObject Catalogs. Hopefully there will be a limited need for any additional InfoObjects.
However, if you have to create any additional InfoObjects, I suggest to use a separate set of InfoObject Catalogs. This way you will be able to distinguish between the generated InfoObjects and the manually created InfoObjects, e.g. for reconciliation purposes.
Figure 9: Manual InfoObject Catalogs
Migration
Last but not least, I would like to say a few words on migration. In some cases you already have (quite some) InfoObjects which were originally based on Business Content. You might want to migrate them in order to reuse them. Theoretically it is possible but can turn out to be quite cumbersome to execute.
You will have to maintain the central Metadata Repository table YBWREPIOBJ. Insert the InfoObjects in a similar way as the program would do. Pay special attention to the Attributes Generation Status. You might want to use a special creation date/time (e.g. 01/01/2000, 00:00:00) to easily identify the migrated content.
Conclusion
In this blog I showed how to optimize the results. We discussed the generation of attributes and “unluckily” generated technical names. Furthermore, we had a look at some special features which are not covered by the program: Master Data Read Class, geographical attributes and Transfer Routine. Finally, we discussed manually created InfoObjects and migration.
- SAP Managed Tags:
4 Comments
