Enhancements to the BW Versioning Concept

Object Version for the Transport

T (Transport ) Version

Since the key (name) of source system-dependent objects in the target system differs from the key of the object in the original system, metadata cannot be imported in the same version as it exists in the original system (A or M version). There could be other objects in the target system that have the same key as the object in the original system. Therefore, source system-dependent objects are transported in their own version, the T version.

After-import methods operate on the T version and generate the modified and active version from this. This can be a set (table) of object keys if there are multiple source systems for an original object in the target system. In this case the transported object must be copied to all target objects (creation of the M versions), which are then activated one after the other. The transport version is then deleted. The information about which source systems of the target system of the transport are assigned to the source system of the imported object is stored in table RSLOGSYSMAP and maintained with the view V_RSLOGSYSMAP.

More information: Defining the Target Source System

Object Versions for Delivery and Activation

Shadow Version

When BI Content is delivered, a special "version" is used because the target system of the delivery probably has no source system with the same logical name as the source system for which the BI Content was developed.

Therefore, source systems are made anonymous before the delivery of source-system dependent objects and replaced by their release status. New objects for SAP NetWeaver 7.0, DataSources, transformations, and DTP, are replaced by the BI Content version of the DataSource. This means source system-dependent objects need to be delivered as individual object types that contain the release or BI Content version of the DataSource instead of the source system in their key. These objects are called shadow objects. Shadow objects are stored differently, depending on their object type; this will be explained in the following sections.

More information: Making the Source System Anonymous

Pseudo D Version

The actual BW versioning concept, and in particular transaction RSOR (BI Content activation), works with objects in the D version only, and not with shadow objects. These must have the same key as the corresponding object in the modified or active version. There are two strategies for doing this:

1. All the functions used by the object to communicate with BI Content activation dynamically determine the key of the D version from the key of the shadow object.

   This logic is applied in the 3.x transfer structure.

   More information: Source System-Dependent 3.x Objects

2. The shadow object is physically copied to the corresponding objects in the D version in the following situations:

   • When the BI Content is imported

   • If there are replicating source systems (SAP systems) during replication

   • If there are non-replicating source systems (non-SAP: File, UD Connect, DB Connect, Web Service) when the source system is activated or when the Content version is assigned to the source system

   Since this D version was only created in the target system and was not actually shipped, it is called a pseudo D version.

   This logic also applies to the other source system-dependent objects (transfer rule, DataSource, transformation, DTP, InfoPackage).

When you create the pseudo D version, how the source system was made anonymous when the shadow object was created is of paramount importance. More information: Making the Source System Anonymous.

If no BI Content objects were found when you collected source system-dependent, refer to the section Troubleshooting (Content Activation).