Start of Content Area

Procedure documentation Transitive Attributes as Navigation Attributes Locate the document in its SAP Library structure

Use

If a characteristic was included in an InfoCube as a navigation attribute, it can be used for navigation in queries. This characteristic can itself have further navigation attributes, called transitive attributes. These attributes are not automatically available for navigation in the query. As described in this procedure, they must be switched on.

Example

An InfoCube contains InfoObject 0COSTCENTER (cost center). This InfoObject has navigation attribute 0COMP_CODE (company code). This characteristic in turn has navigation attribute 0COMPANY (company for the company code). In this case 0COMPANY would be a transitive attribute that one could switch on as navigation attribute.

This graphic is explained in the accompanying text

Procedure

In the following procedure, we assume a simple scenario with InfoCube IC containing characteristic A, with navigation attribute B and transitive navigation attribute T2, which does not exist in InfoCube IC as a characteristic. Navigation attribute T2 should be displayed in the query.

This graphic is explained in the accompanying text

1.       Creating Characteristics

Create a new characteristic dA (denormalized A) which has the transitive attributes requested in the query as navigation attributes (for example T2) and which has the same technical settings for the key field as characteristic A.

After creating and saving characteristic dA, go to transaction SE16, select the entry for this characteristic from table RSDCHA (CHANM = <characteristic name> and OBJVERS = 'M') and set field CHANAV to 2 and field CHASEL to 4. This makes characteristic dA invisible in queries. This is not necessary technically, but improves the readability in the query definition since the characteristic does not appear here.

Start Transaction RSD1 (InfoObject maintenance) again and activate the characteristic.

2.       Including Characteristics in the InfoCube

Include characteristic dA in InfoCube IC. Switch on its navigation attribute T2. The transitive navigation attributes T2 are now available in the query.

3.       Adjusting Update Rules

Now adjust the update rules to the InfoSources for InfoCube IC so that the newly included characteristic dA is computed in exactly the same way as the existing characteristic A. The values of A and dA in the InfoCube must be identical.

This graphic is explained in the accompanying text

4.       Creating InfoSources

Create a new InfoSource with flexible updating. Assign it the DataSource of characteristic A.

Note

Since a DataSource can only be assigned to one InfoSource at a time, you must cancel the existing assignment of the DataSource of characteristic A to the InfoSource (with direct updating).

5.       Load data

Technical explanation of the load process:

The DataSource of characteristic A must define the master data table of characteristic A as well as of characteristic dA. In this example the DataSource delivers key field A and attribute B. A and B must be updated in the master data table of characteristic A.

A is also updated in the master data table of dA (namely in field dA) and B is only used to determine transitive attribute T2, which is read from the updated master data table of characteristic B and written into the master data table of characteristic dA.

Since the values of attribute T2 are copied to the master data table of characteristic dA, this results in the following dependency, which must be taken into consideration during modeling:

If a record of characteristic A changes, it is transferred from the source system when it is uploaded into the BW. If a record of characteristic B changes, it is also transferred from the source system when it is uploaded into the BW. However, since attribute T2 of characteristic B is read and copied when characteristic A is uploaded, a data record of characteristic A might not be transferred to the BW during a delta upload of characteristic A because it has not changed. But the transitive dependent attribute T2 might have changed just for this record and the attribute would not be updated for dA.                                       

The structure of a scenario for loading data depends on whether or not the extractor of DataSource A is delta-enabled.

Loading process:

1.       Scenario for non-delta-enabled extractor

If the extractor for DataSource A is not delta-enabled, the data is updated in the two different data targets (master data table of characteristics A and dA)  using a flexible InfoSource and two different update rules.

This graphic is explained in the accompanying text

2.       Scenario for delta-enabled extractor

If it is a delta-enabled extractor, an ODS object from which you can always execute a full update in the master data table of characteristic dA is used. With this solution, the data is also updated in two different data targets (master data table of characteristic A and new ODS object which has the same structure as characteristic A) with a new (flexible) InfoSource and two different update rules using a delta update. Update rules from the ODS are also used to write the master data table of characteristic dA with a full update.

This graphic is explained in the accompanying text

For both solutions, the update rules in the data target master data table of characteristic dA must cause attribute T2 to be read. For complicated scenarios in which you read from several levels, function modules will be retrieved that execute this service.                                   

This graphic is explained in the accompanying text

It is better for the coding for reading the transitive attributes (in the update rules) if you include the attributes to be read in the InfoSource right from the beginning. This means that you only have update rules that perform a one-to-one mapping. The additional attributes that are included in the InfoSource are not filled in the transfer rules. They are only computed in the update rules in a start routine that must be created. The advantage of this is that the coding for reading the attributes (which can be quite complex) is stored in one place in the update rules.               

In both cases the order at load time must be adhered to and must be implemented either organizationally (load times in the scheduler) or by process chain. It is essential that the master data to be read (in our case the master data of characteristic B) already exist in the master data tables in the system when the data providing the DataSource of characteristic A is loaded.                                                                  

Note

Change the master data from characteristic B so that it is also visible with the next load into A / dA.

 

End of Content Area