In a migration datafiles are flying across systems. And the process of preparing the migration, these files are "being build" and have a tendancy of getting larger and larger. The receiving system will need to consume all this data, in multiple rounds. Here's the thing: receiving data that is already in the system because it was made available in earlier rounds, is a time (and resource) consuming matter.
Would you like to process changes only ? That can be arranged, with datafile information only. Read on...
Imagine system X, which can be any system that can hold information. System X is used to pass migration files to and it passes these same files on for the next system to process them. The only difference between in and out files is that the out file only contains changed content. Lines on which something has changed (assuming the migration file is a text-based file, like the very common CSV files.
The "system-X" role has been developed and is captured in a single Abap report. Try it out !
Report comments:
This report transforms an input file into an output file which contains changed records only. Change tracking is done though SAP datasets. The purpose of this setup is to cater for "migration of changes". First prepare the migration steps that you need, feed the result files to this report and do the migration. So far nothing new. After a month, the whole process (creating files, feed them through file shadowing) is repeated, this time only changes will need to be migrated. Repeat as often as needed - the shadow of the file (files?) will be updated every time. When no output file is supplied, the changes are reported (output is dumped in a report). Note that logical file paths Z_DATAFILE_TRACKING_IN and Z_DATAFILE_TRACKING_OUT can be used (trx FILE).