Process Chains and Process Variants
The process chain and process variant are not source system-dependent objects, but they can refer to source system-dependent objects.
Process Chain
The following table gives an overview of the process chain properties that are relevant for transport, BI Content delivery, and BI Content activation.
|
Classification |
|
|
Degree of dependency |
Indirectly dependent |
|
Type of dependency |
Dependency in the data part |
|
Key technology |
Transparent (source system invariant) |
|
Active Object |
|
|
Transport object |
RSPC |
|
Object key |
Process chain name |
|
Source system reference in data part |
Field VARIANT in table RSPCCHAIN: InfoPackage and data transfer process |
|
Reference to shadow object |
- |
|
Primary table |
RSPCCHAINATTR |
|
Import version |
M |
|
Object versions in primary table |
A | M | D |
|
Delivery Object |
|
|
Transport object for delivery |
DSPC |
|
Object key |
Process chain name |
|
BI Content version reference in data part |
Field VARIANT in table RSPCCHAIN: InfoPackage and data transfer process |
|
Identification for shadow version |
- |
|
Primary table |
RSPCCHAINATTR |
|
Pseudo D version |
- |
|
Maintenance |
Special Features
Process chains and process variants are normal transport objects. The key of these objects is the same key in the target and original system. However, process chains and process variants can reference source-system dependent objects.
A process chain that references source-system dependent objects (which have a GUID in the key) has this GUID in the VARIANT data field of table RSPCCHAIN (see graphic).
When BI Content is activated, the keys of these fields are converted in the same way as the corresponding source system-dependent object. The same differences exist between the A and D versions of the process chains and process variants.
Process Variant
The following table gives an overview of the process chain properties that are relevant for transport, BI Content delivery, and BI Content activation.
|
Classification |
|
|
Degree of dependency |
Indirectly dependent |
|
Type of dependency |
Dependency in the data part |
|
Key technology |
Transparent (source system invariant) |
|
Active Object |
|
|
Transport object |
RSPV |
|
Object key |
Process type and variant name |
|
Source system reference in data part |
Field FNAM in table RSPCVARIANT: PSA of the DataSource, InfoPackage or data transfer process |
|
Reference to shadow object |
- |
|
Primary table |
RSPCVARIANTATTR |
|
Import version |
M |
|
Object versions in primary table |
A | [M] | D |
|
Delivery Object |
|
|
Transport object for delivery |
DSPV |
|
Object key |
Process type and variant name |
|
BI Content version reference in data part |
Field FNAM in table RSPCVARIANT: PSA of the DataSource, InfoPackage or data transfer process |
|
Identification for shadow version |
- |
|
Primary table |
RSPCVARIANTATTR |
|
Pseudo D version |
- |
|
Maintenance |
Special Features
Generally all configurations of process types are called process variants. There is also a special transport object that transports and ships all the process types that are saved with the generic variant service, such as PSA deletions or DataStore activations. Similarly, the process type is part of the object key.
The modified (M) version of the process variant is generally only used for the transport. The process can also use the M version for maintenance, but this is not generally done since process variants do not need to be activated explicitly.
The figure below shows the individual steps of the conversion. GUID1 references the InfoPackage. When you copy this to the D version, GUID1 is converted to GUID2. As in the example for the InfoPackage, GUID2 is copied to GUID3 and to GUID4 for different customer source systems.
All the source systems that you have selected as default systems are included when you activate a process chain in the customer system. For example, if you selected one SAP source system with Release 4.0B and one with Release 4.5B in the Select Source Systems as Default dialog box, the object collector collects one InfoPackage for each source system. If you activate a process chain with this same setting, both InfoPackages are transferred to the process chain. At the same time, an AND process is inserted, which links the InfoPackages and the subsequent processes.
Note that automatic insertion of the AND process only works if you selected the option Match when you activated the process chain from the BI Content. Otherwise the additional object is inserted into the chain, but you must postprocess the chain in order to connect it properly with the objects that already existed. If you did not modify the process chain, you should copy the chain again without the Match option when you add a new source system.