Show TOC

InfoPackageLocate this document in the navigation structure

Use

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

Creating InfoPackages

Example

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

Note

Using the RSSM_SHIPDVERS_CLEANUP report, you can display and repair inconsistent InfoPackages if necessary. For more information, see SAP Note 844739.