Show TOC

Source System-Dependent 3.x ObjectsLocate this document in the navigation structure

Use

3.x DataSource

The following table provides 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 BW 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 provides 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

DataSource 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

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.

Note

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.

Recommendation

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 graphic 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.

Note

Make your program upwards compatible, that is additive.

Transfer Structure

The following table provides 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 delivery

SHTR

Object key

DataSource | Release of source system

DataSource 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 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. Table RSBASIDOC shows which source system and release a transfer structure prefix is assigned to.

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 field TRANSTRU 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.

Note

Avoid using the same DataSource with the same names, in different source systems that have the same release. See the information under Transfer Rule for more details.

The D version is delivered 1:1. The conversion on the right corresponds for all intents and purposes to that of the transfer rule. There are a few minor differences however as descrbed above (virtual key).