Transport and Delivery of Source
System-Dependant Objects 
Use
To facilitate understanding of this topic, this section contains information on transports in general.
It is not objects themselves that are transported into a BW system but the meta information that is required to generate an object in the target system. Source system-dependant objects are notably dependant on circumstances in the target system. They can be distributed, even physically, to a BW system and a source system. As a result, particular requirements often exist in relation to source system-dependant objects, such as the following:
· An object that was created in the original system for a source system A, should be created in the target system for another source system B
· As the definition of a connection to a source system always depends on both sides, the source system and the BW system, an object that was created in both the source and target systems for one and the same source system physically has two different connections to this system.
Therefore, with source system-dependant objects, a logic runs that defines the name of, and connection to the source system for which the import and activation of the content is to be executed.
Delivery (content-specific)
As with the delivery of SAP Business Content, the name of the source system is normally also of little relevance with the delivery of customer Content. This is because the customer has other source systems connected as the Content development system. Therefore the source systems of source system-dependant objects are made anonymous before delivery and replaced by their release status. This means source system-dependant objects need to be delivered with their own tables. These carry the release instead of the source system in their key. These tables are called shadow tables.
Transport (general)
The key (name) of the source system-dependant objects in the target system differs from the key for the object in the original system. This means the meta information cannot be imported in the same version as it exists in the original system (A or M version). In the event, there could be other objects in the target system that have the same key as the object in the original system. Therefore source system-dependant objects are imported in their own version, the T (transport) version.
After-import methods act on the T version and generate the modified and active version from this.
Features
The following table offers an overview of the different types of source system-dependant objects:
Source system-dependant objects
|
Type of Object |
Example |
|
Source system-dependant object, carries the source system directly in its key |
Transfer rule DataSource BBS receiver for the InfoCube BBS receiver for the query |
|
Source system-dependant object, carries the source system in its key in coded form |
Transfer Structure |
|
Source system-dependant object, carries a GUID (Globally Unique Identifier) in its key |
InfoPackage |
|
Source system-independent object, refers to a source system-dependent object |
Process chain Process chain variants (PSA processes) |
In the first three cases the keys change. In this way, a distinction can be made between their D and A tables.
See also:
Process Chains and Process Chain Variants