To migrate an existing data flow, we recommend using the system-backed automatic migration in transaction RSMIGRATE. More information:Migrating Data Flows.
The following sections outline what you need to consider and how you proceed when migrating a data flow manually.
In the procedure outlined here, we make the following simple assumptions:
- You intend to migrate the data flow without making any changes to the transformation logic and the InfoSource (which is optional in the new data flow) is to be retained.
- In the data flow, one DataSource is connected to multiple InfoProviders. All objects required in the data flow exist as active versions.
Carry out steps 1-6 and 8-9 in the development system:
- For each InfoProvider that is supplied with data from the DataSource, generate a transformation from each of the update rules.
Copy the 3.x InfoSource to a new InfoSource.
- Generate a transformation from each of the corresponding transfer rules.
Remember to use the existing InfoSource that was created when the update rules were migrated.
- Make any necessary adjustments to the transformation.
You need to postprocess a transformation if you use formulas or inverse routines in your transfer rules for example. You can also adjust the routines to improve performance.
For more information about steps 1-3, seeMigrating Update Rules, 3.x InfoSources and Transfer Rules.
- Create the data transfer processes for further updating the data from the PSA.
In the new data flow, the data transfer process uses the settings from the InfoPackage that are relevant for updating the data from the PSA. More information:InfoPackage -> Data Transfer Process.
- In InfoPackage maintenance, navigate to the Data Targets tab page.
- Create a data transfer process for each of the InfoProviders that is supplied with data from the InfoPackage.
- To do this, choose Error! Objects cannot be created from editing field codes. under Create/Maintain DTP with the quick info text Create New Data Transfer Process for This Data Target.
- Check all DTP settings that you want the DTP to use in the new data flow for the InfoPackage.
- On the Update tab page, check the settings for error handling.
- On the Extraction tab page, check the extraction mode.
For more information about data transfer processes, seeCreating Data Transfer Processes.
- In the InfoPackage, check on the Data Targets tab page that any InfoProviders that are supplied with data by means of update rules are not selected. This allows you to ensure that the InfoProviders are subsequently only supplied with data by the new data flow.
- Check the process chains that are used in the data flow and make any necessary adjustments.
- Open the process chain from InfoPackage maintenance by choosing Process Chain Maintenance.
- Insert the DTPs into the process chain directly after the InfoPackage.
- Make any adjustments required in the subsequent process (previously InfoPackages, but now DTPs).
If the process variants previously referred to the object type InfoPackage, you now need to specify the corresponding DTP, when activating the data in the DataStore object for example.
- Test the data flow.
- If you have a two-system landscape, run the test in the development system.
- If you have a three-system landscape, first transport the affected objects to the test system and test your new data flow there.
- Migrate the DataSource.
The migration process generates a new DataSource. The 3.x DataSource and the transfer structure and mapping are deleted. The PSA and InfoPackage are used in the new migrated DataSource.
When the DataSource is migrated, the InfoPackage is not migrated in the sense of a new object being created. After migration however, only the specifications about how data is loaded into the PSA are used in the InfoPackage. Existing delta processes continue to run. The delta process does not need to be reinitialized.
You can convert a migrated DataSource to a 3.x DataSource if you export (restore) the 3.x objects during migration.
More information:Emulation, Migration and Restoring DataSources andMigrating 3.x DataSources Manually (SAP Source System, File, DB Connect).
XML and UD-Connect 3.x DataSources cannot be migrated. Conversion to the new DataSource concepts is made by copying the 3.x DataSource to the new object type. More information:Emulation, Migration and Restoring DataSources andMigrating 3.x DataSources (UD Connect, Web Services).
- To ensure greater transparency, you should delete the 3.x InfoSource and update rules.
- If you have a three-system landscape, transport the migrated DataSource and the deletion of the 3.x InfoSources and update rules into the test system.
- Examine the data flow for completeness and check that any objects that are no longer required are deleted.
- In a two-system landscape, do this in the development system.
- In a three-system landscape, do this in the test system.
- Finally, transport the objects and deletions from the development or test system into your production system.
You have migrated a 3.x data flow and can now benefit from the features of the new concepts and technology.
Migrating Data Flows That Use the Data Mart Interface
You cannot migrate export DataSources that are used when the data mart interface is used to update data from one InfoProvider to another InfoProvider. However, a data flow that uses export DataSources can be migrated to the new object types, because the export DataSource and its transfer and update rules can be modeled in the new data flow using DTPs and transformations. The data flow can be migrated as outlined above. However, the actual migration of the DataSource and the corresponding steps involved are omitted.