Process Chain and Process
Variant 
Definition
Process chains (active object: RSPC / delivery object: DSPC) and process variants (active object: RSPV / delivery object: DSPV) are not source-system-dependent objects. However, they can reference source-system-dependent objects.
For more information about these BW objects, see 
Process Chains and
Processes.
Structure
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 chain 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 (see graphic).
When Content is activated the keys of these fields are reassigned 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.
The following graphic shows the individual steps in reassigning keys in the example above. GUID1 references the InfoPackage. When you copy this into the D version, GUID1 is converted to GUID2. As in the example given in InfoPackage, GUID2 is copied to GUID3 and GUID4 for the different customer source systems.
Example
The following example shows what you need to bear in mind when activating process chains using customer Content.
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, 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:
SAP recommends that you only activate process chains for one source system as otherwise the subsequent process steps may be executed more than once (if the process chain is a periodic process chain) or too early (after the first InfoPackage is processed).
1. Scenario: Customer system with one source system
Choose the source system before you activate the Content.
2. Scenario: Customer system with several source systems
This involves additional manual efforts for the customer. They have to re-enter the relations in process chain maintenance after the event.
Variant 1:
...
1. Select the relevant source system before you install the Content.
2. Collect the InfoPackage and activate it with the selected source systems.
3. Choose one of the source systems before installing the Content.
4. Collect the process chains and activate them with the selected source system.
5. Call up process chain maintenance. Add the InfoPackage process type “Load Data” to the process chain for the source system that you did not select before you activated the process chain. Add the process type “AND (Last)“ and include the necessary relations so that the new InfoPackages are included.
The following graphic shows how an InfoPackage is added subsequently for the source system at release 4.0B:
Variant 2:
...
1. Select the relevant source system before you install the Content.
2. Collect the process chains and activate them with the selected source systems.
3. Call up process chain maintenance. Delete the relations that come from the “Data Load“ process. Add the process type “AND (Last)“ and include the necessary relations so that the new InfoPackages are included.
Content Development System
Avoid changing the source system release after delivering your customer Content. This can cause errors in a customer system with just one source system. The D version in the customer system is replaced when a new delivery takes place; however the old active version is retained when you activate because the source system is not the same.
See also:
Transport and Delivery of Source-System-Dependent Objects