Copying queries between CompositeProviders using RSZC

Last week one of my colleagues had trouble copying queries between two CompositeProviders using RSZC. Searching accross the internet and SCN ended up in people stating to have the same problem. It seems that still a lot of people are unaware of the fact that the technical name of an CompositeProvider is different than the technical names of any other InfoProvider.

When creating a CompositeProvider the system automatically adds a additional prefix of @3 to the InfoProvider name as mentioned in the SAP Help. So in case of a CompositeProvider with the name CP_0003 the real technical name is @3CP_0003. Using this complete technical name it is possible to copy queries between CompositeProviders using transaction code RSZC.

Copying queries between CompositeProviders using RSZC

Quickly find queries which use specific InfoObjects

When it comes to deleting InfoObjects from SAP BW it is necessary that these are not used anymore by other objects in the system. The standard where-used functionality could supply sufficient insight. However the standard where-used functionality is not always accurate when a person wants to know in which SAP BW queries an InfoObject is used. For this specific case you have the ability to use one of the following two function modules.

Technical nameType

By filling in the right parameters the function module delivers a table of queries using the specified characteristic or key figure.

SAP tables related to transports

In some cases it might be interesting to know which SAP BW objects are attached to a specific transport for e.g. release management. Instead of copy and pasting object values mentioned in the SE10 transaction SAP tables can be used.

All information related to SAP transports is stored in E07* tables. An overview of these tables is shown below. Along with this information and this table overview you have the ability to compose an overview of objects (including their functional description) belonging to specific transport.

E070Change & Transport System: Header of Requests/Tasks
E070AChange & Transport System: Attributes of a Request
E070CCTS: Source/Target Client of Requests/Tasks
E070CREATEChange & Transport System: Creation Date of Request
E070CTVGenerated Table for View E070CTV
E070DEPChange & Transport System: Dependencies of Requests
E070LCTS: Index for Assigning Numbers to Requests/Tasks
E070MCTS: Target Package/Layer for Requests
E070TCHelp Table for E070 for Client-Specific Imports
E070USEUse of Current Requests by Users
E070VGenerated Table for View E070V
E071Change & Transport System: Object Entries of Requests/Tasks
E071CChange & Transport System: Client-Specific Lock Flag
E071ELang. Transport: Positive List for Generic Object Selection
E071KChange & Transport System: Key Entries of Requests/Tasks
E071KCChange & Transport System: Key Entries of Requests/Tasks
E071KFChange & Transport System: Nametab Info. on (CHAR)Key Fields
E071KFINIChange & Transport System: Nametab Info. on (CHAR)Key Fields
E071K_30Change & Transport System: Key Entries of Requests/Tasks
E071K_KEYE071K Key Fields
E071SSystem-Specific Import Status of Objects
E071VGenerated Table for View E071V
E07TChange & Transport System: Short Texts for Requests/Tasks
E07T_OLDE07T Before TRKORR Extension

Thanks to for supplying this helpful overview.

The power of navigational attributes

Remember the time when all additional functionality had to be programmed manually in SAP BW? With SAP Business Warehouse 7.3 (and above) many of custom ABAP code could be replaced with standard functionality. One real-life example is the retrieval of a navigational attribute from a navigational attribute.

In the good old days this could be done by using custom ABAP code. With SAP BW 7.3 you can now easily achieve the same result by using navigational attributes. By activating a navigational attribute in the source InfoProvider (like a DataStore Object) you will get the possibility to use the attribute as a source in a transformation.
Using navigational attributes instead of ABAP
With this in mind you now have the capability to use the default “read from master data”-option when modelling a transformation. This makes it possible to read a navigational attribute from a navigational attribute.

The activation of navigational attributes also enables you to use these in a DTP or start routine. This might come in handy when filtering out invalid records.
Using navigational attributes as DTP filter option

RSRQ: a useful transaction for tracing back records

It might happen that when you are unit testing reports or data models you will probably encounter various issues. Tracing back the data is one of the steps you can execute to find the cause of an issue. In order to trace back the data you will have to know from which source it is coming from, at least when a data object is loaded from multiple sources.

Add request ID as characteristic
By selecting the request ID as a characteristic you will be able to see which specific data load is responsible for a record. With the use of the SAP BW transaction RSRQ along with the request ID, you will be able to go straight to the monitor of the data load and determine that source of a record. Hopefully this information will help you in your journey of solving SAP BW data issues!

RSRQ data load monitor for single request