When
using Data Transfer
Processes (DTPs) to load data, there is an important feature called "Reparability" If a data load
request fails, it appears in red status, indicating that the data was not
loaded correctly into the target destination. Such failures can occur due to
various reasons, such as extraction issues, network errors, database locks,
data transformation errors, or data integrity issues, such as missing master
data.
However, this repair option is only available in specific cases, typically when the data is still present in the DTP's temporary storage. There are two particular
scenarios that need to be met for successful data repair:
1.
The source of the extracted data must hold the data in a table with a technical
key (request, data package). Additionally, each data package in the source must
be uniquely assigned to a data package extracted by the DTP. In case of
incorrectly processed data packages, they can be reconstructed uniquely in
another attempt using selections from the source data.
2.
If the source does not have this property, there is still an option to
reconstruct the incorrect data from the temporary storage created at runtime by
the DTP. However, this is only possible when all the data from the source was
extracted in the first attempt and when at least one temporary storage was created
for all data packages.
The technical evaluation of the data load request for the "Repairable" flag is carried out using the ABAP method IF_RSBK_REQUEST~GET_REPAIRABLE in the
class CL_RSBK_REQUEST_RED. The flag itself refers to the data element RSBKREPAIRABLE (Indicator: Request Is Repairable) in the data dictionary.
Inconclusion, the reparability feature of data load requests in DTPs provides a
valuable way to address and correct data load failures, ensuring smoother data
integration into the target destination.
