Migrating a Data Flow
Since SAP NetWeaver 7.0, new concepts and technologies are available for the data flow. These include the data transfer process, the transformation and the new DataSource (object type R3TR RSDS). If you want to benefit from these new features while working with an existing data flow, we recommend switching to the new concepts and technology. An interface is available for creating and executing migration projects for automated migration (transaction RSMIGRATE).
The following objects are supported by migration.
|
Object |
Object Type |
|
3.x InfoSource |
R3TR ISTD |
|
Transfer Rules |
R3TR ISTS and R3TR ISMP |
|
Update Rules |
R3TR UPDR |
|
InfoPackage |
R3TR ISIP |
|
VirtualProvider |
R3TR CUBE (cubetype=V, cubesubtype=S) |
|
Process Chain |
R3TR RSPC |
|
Process Chain Variant |
R3TR RSPV |
|
3.x DataSource Note
The options and restrictions for migrating a 3.x DataSource (depending on the source system type for example) are the same as for individual DataSource migration. More information: Emulating, Migrating and Restoring DataSources. |
R3TR ISFS |
To perform the data flow migration, create a migration project. For 3.x objects and 3.x DataSources, InfoSources and transfer and update rules, you can use migration projects to create objects from the new data flow concept and adapt InfoPackages, process chains, process variants and VirtualProviders to the migrated data flow.
Starting from a source object, the other objects from the data flow and any associated process chains are displayed in a tree display and can be selected for the migration project. To perform the migration, select the various steps, creation of data transfer processes from InfoPackages for example or migration of DataSources with object type R3TR ISFS to DataSources with object type R3TR RSDS.
You can perform the migration in a customer system. During migration, objects will then be created in the A version, or the A versions will be adapted to the affected objects. In a content development system, the D versions of the objects will be migrated. Consistent transports will be created for the migrated objects.
For a migration project that has migrated a 3.x data flow, you can also recover the pre-migration state. We recommend only recovering if errors occur with the migrated data flow.
Notes and Restrictions
Take note of the following points when performing automatic data flow migration:
-
During automatic migration, the structure of an existing data flow will be retained. For the various objects, either new objects will be created if a 3.x object type is replaced by a new object type, or existing objects will be adapted. There is no further optimization of the data flow.
-
Problems can arise if parts of process chains are divided over multiple migration projects. Consistent data recovery would then only be possible if it was performed in the opposite order to the migration of the individual migration projects. We therefore recommend creating the migration projects in such a way that all migration-relevant processes in the participating process chains are migrated in a single project. This means that multiple data flows might be migrated together in a single migration project.
-
Hierarchy DataSources and their associated transfer rules cannot be migrated automatically. These objects cannot be selected in a migration object.
-
Create a migration project.
More information: Creating and Editing Migration Projects.
-
Execute the migration project.
More information: Executing Migration Projects.
-
Check the execution of the migration project.
More information: Monitoring Migration Projects.
-
Check the migrated data flow.
You can use this function to check whether the transfer and update rules have been migrated correctly to the transformation rules.
More information: Checking Migrated Data Flows.