If you remember older releases of SAP NetWeaver BW hierarchies could only be loaded through the old 3.x data flow. In this case you needed the so called direct update functionality of the corresponding InfoSource for uploading the hierarchy. This InfoSource 3.x was connected to an 3.x DataSource through update rules.
Limitations of 3.x data flow for hierarchies
This data flow has to be used in SAP NetWeaver BW 7.x, too, and could not be migrated to the new data flow. Consequently you always had to deal with two types of data flows in your system. Besides the heterogeneous aspect the 3.x data flow for hierarchies had a lot of disadvantages:
- First, hierarchy DataSources were available only for flatfile and SAP source systems. Besides, end users could only create own hierarchy DataSources for the flat file system.
- Second you could not take full advantage of the new data flow, even some old data flow features (e.g. the start routine) could not be used. Furthermore, to change the structure of hierarchies during runtime you had to implement complex scenarios (e.g. with the help of the analysis process designer APD). The direct update functionality didn’t allow you to load the hierarchy to a DSO or an other arbitrary object and manipulate it according to the end users’ needs.
- Third, monitoring was often unclear because the framework was not optimal for segments.
The new BW 7.30 hierarchy framework
With SAP NetWeaver BW 7.30 the hierarchy framework has been improved, you could now use the 7.x data flow with all its advantages.
First you are able to use any BW object as source for a hierarchy, you are not limited to a DataSource for hierarchies. This leads to simpler scenarios if you want to transform your hierarchy according to your needs. You just have to connect your hierarchy through a transformation and a data transfer process.
Within this transformation you are able to use all features of a transformation, for example start, end or expert routines. You are not limited as you were in the 3.x data flow.
You can use any DataSource as a source for your hierarchy, you are not restricted to hierarchy DataSources any more. This makes hierarchy extraction of SAP source systems possible, too.
Last but not least you are now able to take full advantage of all capabilities of the new data flow. You can distribute the data loaded from one DataSource to several hierarchies and you can use an arbitrary number of InfoSources in between the DataSource and your hierarchy. A very useful feature is the automatic filling of the fields CHILDID, NEXTID and LEVEL through the framework if they are not filled by the source (e.g. if only the PARENTID is provided).
New DataSource structure
If you are familiar with the old hierarchy framework you will notice a new segmentation format for the hierarchy structure. Let’s have a look at the old structure which is shown in the figure below on the left hand side.
The hierarchy structure contained of the five fields NODEID, IOBJNM, NODENAME, LINK and PARENTID. The NODEID was the internal number for your node, the field IOBJNM contained the InfoObject name for your node. The NODENAME contained the value in compounded format (if compounded InfoObjects were used). This is the case if you use e.g. cost center hierarchies which are compounded to the controlling area.
The new framework now uses more fields to describe the hierarchy structure. Whereas the first five fields are the same, the new structure now contains fields for every InfoObject of a compounded structure. For example, if you use the cost center which is compounded to the controlling area, the new structure contains both InfoObjects.
New rule type “hierarchy split”
In SAP NetWeaver BW 7.30 both structures are available, the old one and the new one. Please be aware that most of the DataSources of the Business Content have not been migrated to the new structure. That could lead to a problem because you have to map the old DataSource structure to the new structure within the hierarchy. To avoid the problem SAP has introduced a new rule type which automatically maps the old structure to the new one (see figure).
This new rule type is called “hierarchy split”. To use the new rule type you have to map the field NODENAME to every InfoObject of your structure, in this case the controlling area and the cost center. The hierarchy split automatically transforms the value of NODENAME to the corresponding values of controlling area and cost center.
Please remember that this functionality only works if you haven’t changed the length of the corresponding InfoObjects. For example, if you changed the length of the controlling area to 5 digits instead of 4 you cannot use this feature.
Creating a new DataSource for hierarchies
If you want to create a new DataSource for hierarchies just navigate to transaction RSA1 and open a DataSource tree of a source system, for example a flat file source system. Right-click on a display component and create a new DataSource for hierarchies:
After choosing the correct type of DataSource you can edit the properties of your DataSource. The main properties can be found in the tab “extraction” which is shown in the following figure.
In the top of the screen you can provide information on full/delta loading and the direct access, both you will know of other DataSources. The interesting parts are highlighted. If you select “hierarchy is flexible”, the DataSource will be created in the new structure, if you leave it blank the DataSource will consist of the old structure. Second you are now able to create the hierarchy header directly from the DataSource. In older releases you had to maintain the hierarchy header in the InfoPackage. I think the other parameters are known, if not just feel free to ask me.
Creating transformation and DTP
After activating your DataSource you can create a transformation between your new DataSource and the hierarchy of an InfoObject. The following picture shows how this is displayed in the system.
Within the transformation you have to map the corresponding segments to each other. The interesting one is the mapping of source segment “hierarchy structure” to the correspondent target segment.
You can see that there are a lot of 1:1 rules within the transformation except the mapping of field NODENAME to 0COSTCENTER and 0CO_AREA. Here, the new rule type “hierarchy split” has been set.
Maybe you have noticed that the key field 0OBJECTID has not been mapped. This field will be used to load more than one hierarchy to have a unique key. Please be aware that in this case each data package has to contain exactly one complete hierarchy.
Now let’s have a look at the corresponding data transfer process (DTP). There are two major changes when loading data through a hierarchy DataSource:
- If you select full extraction mode in the DTP there’s a new flag called “only retrieve last request”. This flag is helpful if you don’t want to clear your PSA before loading the new hierarchy. Only the newest request in the PSA will be selected and loaded.
- In the update tab of your DTP (see figure) you can decide how to update your hierarchy (full update, update subtree, insert subtree). Furthermore you can activate the hierarchy from within the DTP, no separate process step in a process chain is necessary to activate the hierarchy!
Now you are able to load a hierarchy from a hierarchy DataSource to an InfoObject.