Source System-Dependent 3.x Objects 

3.x DataSource

The following table gives an overview of the properties that are relevant for transport, BI Content delivery, and BI Content activation.

Classification
Degree of dependency	Directly dependent
Type of dependency	Dependency in object key
Key technology	Transparent
Active Object
Transport object	ISFS
Object key	DataSource | source system | object version
Source system reference in data part	-
Reference to shadow object	With algorithm using the source system release
Primary table	RSOLTPSOURCE
Import version	T
Object versions in primary table	A | M | T | Pseudo D
Shadow Object
Transport object for delivery	SHFS
Object key	DataSource
BI Content version reference in data part	-
Identification for shadow version	Separate tables
Primary table	RSOLTPSOURCESH
Pseudo D version	SAP systems: Is created by replicating the DataSource 3.x or by replicating the source system Non-SAP systems: Is created by activating the source system Alternatively: Is created by executing the function module RSAOSINT_PSEUDO_DVERSION_UPD
Maintenance	Indirectly using transfer rule

Special Features

Since a 3.x DataSource (SHFS) is delivered in the BI system only for file or BAPI systems, the release (in contrast to a transfer rule) for this object is always initial. Therefore, the release of the source system as individual field is missing in the key.

Transfer Rule

The following table gives an overview of the properties that are relevant for transport, BI Content delivery, and BI Content activation.

Classification
Degree of dependency	Directly dependent
Type of dependency	Dependency in object key
Key technology	Transparent
Active Object
Transport object	ISMP
Object key	DataSource | source system | object version
Source system reference in data part	-
Reference to shadow object	With algorithm using the source system release
Primary table	RSISOSMAP
Import version	T
Object versions in primary table	A | M | T | Pseudo D
Shadow Object
Transport object delivery	SHMP
Object key	DataSource | Release of source system
BI Content version reference in data part	-
Identification for shadow version	Separate tables
Primary table	RSISOSMAPSH
Pseudo D version	SAP systems: Is created by replicating the corresponding DataSource 3.x or by replicating the source system Non-SAP systems: Is created by activating the source system Alternatively: Is created by executing the function module RSAOSINT_PSEUDO_DVERSION_UPD
Maintenance	Function module RSO_ISMP_MAINTAIN More information: Processing Transfer Rules

Special Features

Since the concept of a BI Content release type and version was only introduced at a later date, transfer rules do not use this concept. Instead, they only use the Basis release of the source system to make the source system anonymous at delivery.

Example

The following example shows what you must take into account for transfer rules when you directly ship source system-dependent objects with a transparent key (DataSource 3.x, transfer rule).

The BI Content development system is connected to the following source systems:

●      Source system Q1, release 3.1

●      Source system Q2, release 4.5

●      Source system Q3, release 4.5

The customer target system is connected to the following source systems:

●      Source system X1, release 3.1

●      Source system X2, release 4.0

The left side of the following figure shows the conversion from the A version to the shadow version in the BI Content development system. The result of this conversion is that the source system is replaced by its release. Since Q2 and Q3 have the same release, the shadow version only contains two data records.

The shadow table is automatically generated when this is activated.

Avoid using the same DataSource with the same names, in different source systems that have the same release. In this case, only one delivery object is generated in the shadow tables that is combined from the information in different source systems. If this leads to a conflict, the most recently activated object has priority. - This is also true for the transfer structure.

We recommend that you set up a BI Content development system for each release.

The shadow version is delivered 1:1. The right side of the figure shows the process flows in the customer system. The D version is generated from the imported shadow version in the first after-import step. The system searches for the appropriate release in the BI Content for source system X1 and finds 3.1. Since there is no release 4.0 in the BI Content, the system takes the next lowest release for source system X2, which is also 3.1. When activating the BI Content, the D version is copied to the A version.

Make your program upwards compatible, that is additive.  

Transfer Structure

The following table gives an overview of the properties that are relevant for transport, BI Content delivery, and BI Content activation.

Classification
Degree of dependency	Indirectly dependent
Type of dependency	Dependency in object key
Key technology	Coded
Active Object
Transport object	ISTS
Object key	Transfer structure name | Object version
Source system reference in data part	-
Reference to shadow object	By algorithm with transfer rule
Primary table	RSTS
Import version	T
Object versions in primary table	A | M | T
Shadow Object
Transport object for delivery	SHTR
Object key	DataSource | Release of source system
BI Content version reference in data part	-
Identification for shadow version	Separate tables
Primary table	RSTSSH
Pseudo D version	Dynamic
Maintenance	Indirectly using transfer rule

Special Features

The pseudo D versions are not stored physically for the transfer structure since the name of the active object is determined with a heuristic that uses a number range if the allowed key length is exceeded. In contrast to BI Content activation, it works with a virtual key (DataSource | Logsys) for which there is no physical counterpart. This name is the same as for the assigned transfer rule.

Transfer structures can reference routines or formulas. If there is more than one target source system, the routines and formulas for each target source system are also copied during a transport or during BI Content activation. The copies are entered in the modified and active versions of the relevant (target source system-specific) transfer structure. When a transfer structure is deleted in which the referenced routines and formulas are also deleted, this prevents the other transfer structures that were created from the same shadow version or transport version from becoming inconsistent.

Example

The following example aims to show what you need to paid attention to when delivering transfer structures within BI Content.

The BI Content development system is connected to the following source systems:

●      Source system Q1, release 3.1

●      Source system Q2, release 4.5

●      Source system Q3, release 4.5

The transfer structure does not have the source system (field LOGSYS) in its key, but the name of the DataSource to which transfer structure has been added. The RSBASIDOC table shows to which source system, in which release, a transfer structure prefix is assigned.

RSBASIDOC Table

SLOGSYS	SAPREL	TSPREFIX
Q1	3.1	QA
Q2	4.5	QB
Q3	4.5	QC

The customer target system is connected to the following source systems:

●      Source system X1, release 3.1, transfer structure prefix XA

●      Source system X2, release 4.0, transfer structure prefix XB

The left side of the following figure shows the conversion from the A version to the D version in the BI Content development system. Note that only the first column (TRANSTRU) is a key field. The system writes the name of the DataSource (OLTPSOURCE) to the TRANSTRU field in the D version and determines the release of the source system (SAPREL) from the transfer structure prefix. As a result, the name of the transfer structure is replaced in the D version with the name of the transfer rule for which the transfer structure is valid. Since Q2 and Q3 have the same release, the D version only contains two data records.

Avoid using the same DataSource with the same names, in different source systems that have the same release. Also refer to the information in the section Transfer Rule.

The D version is delivered 1:1. The conversion on the right side corresponds, in principle, to that of the transfer rule. However, it actually shows the features described above (virtual key).