The following table provides an overview of the InfoPackage 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 |
GUID |
Active Object |
|
Transport object |
ISIP |
Object key |
Logical InfoPackage ID |
Source system reference in data part |
Field LOGSYS in primary table: Reference to source system |
Reference to shadow object |
RSSHIPDVERS Table |
Primary table |
RSLDPIO |
Import version |
A |
Object versions in primary table |
A | Pseudo D |
Shadow Object |
|
Transport object for delivery |
SHIP |
Object key |
Logical InfoPackage ID |
BI Content version reference in data part |
Fields SRCREL | CONTSRCTYPE | CONTSRCVERS in the primary table |
Identification for shadow version |
Separate tables |
Primary table |
RSLDPIOSH |
Pseudo D version |
SAP systems: Is created by replicating the corresponding DataSource or by replicating the source system Non-SAP systems: Is created by activating the source system Alternatively: Is created by executing the function module RSSM_SHIP_PSEUDO_DVERSION_WRI or when the InfoPackage is repaired with the report RSSM_SHIPDVERS_CLEANUP |
Maintenance |
The following example shows what you need to bear in mind when delivering InfoPackages.
The content development system is connected to the Q1 source system. There is exactly one InfoPackage with GUID1 for this source system.
In the customer system, this InfoPackage is to be activated for several source systems with the same release status:
Source system X1, Release 4.0
Source system X2, Release 4.0
Accordingly, the InfoPackage is copied twice to the A version. The logic is similar to the logic for transfer rules (more information: Source System-Dependent 3.x Objects). Conversion is carried out by the RSSM_SHIP_PSEUDO_DVERSION_WRI function module. The copies get GUID3 and GUID4.
If there is another delivery, you have to know from which InfoPackage GUID3 and GUID4 are derived. This information is stored in the RSSHIPDVERS table:
LOGDPID_SH |
LOGSYS |
LOGDPID |
GUID2 |
X1 |
GUID3 |
GUID2 |
X2 |
GUID4 |
Using the RSSM_SHIPDVERS_CLEANUP report, you can display and repair inconsistent InfoPackages if necessary. For more information, see SAP Note 844739.