Start of Content Area

Function documentation Handling of Data Records with Errors  Locate the document in its SAP Library structure

Use

Using the error handling settings on the Update tab page in the data transfer process, when data is transferred from a DTP source to a DTP target, you can specify how the system is to react if errors occur in the data records.

These settings were previously made in the InfoPackage. When using data transfer processes, InfoPackages only write to the PSA. Therefore, error handling settings are no longer made in the InfoPackage but in the data transfer process.

Features

Settings for Error Handling

For a data transfer process (DTP), you can specify how you want the system to respond when data records contain errors. If you activate error handling, the records with errors are written to a request-based database table (PSA table). This is the error stack. You can use a special data transfer process, the error DTP, to update the records to the target.

Temporary storage is available after each processing step of the DTP request. This allows you to find out which processing step the error occurred in.

Checks for Incorrect Data Records

The following table provides an overview of where checks for incorrect data records can be run:

Where Is Check Run?

Examples of Incorrect Data Records

In the transformation

Field contains invalid characters or lowercase characters

Error during conversion

Error during currency translation

A routine returns a return code <> 0

Characteristic value is not found for master data

Error reading master data

Customer-specific formula results in error

When data is updated to the master data table or text table

Invalid characters in keys or navigation attributes

If no SID exists for the value of the navigation attribute

If no language field is defined for texts

Invalid "from" and "to" dates

Duplicate data records with relation to keys

Overlapping and invalid time intervals

When data is updated to the InfoCube

If no SID exists for the characteristic value

When checking referential integrity of an InfoObject against master data tables or DataStore objects

If no SID exists for the characteristic value

"Repairing" with Error DTP

You create an error DTP for an active data transfer process on the Update tab page. You run it directly in the background or include it in a process chain so that you can schedule it regularly in the context of your process chain. The error DTP uses the full update mode to extract data from the error stack (in this case, the source of the DTP) and transfer it to the target that you have already defined in the data transfer process.

Activities

...

       1.      On the Extraction tab page under This graphic is explained in the accompanying text Semantic Groups, define the key fields for the error stack.

This setting is only relevant if you are transferring data to DataStore objects with data fields that are overwritten. If errors occur, all subsequent data records with the same key are written to the error stack along with the incorrect data record; they are not updated to the target. This guarantees the serialization of the data records, and consistent data processing. The serialization of the data records and thus the explicit definition of key fields for the error stack is not relevant for targets that are not updated by overwriting.

The default value and possible entries for the key fields of the error stack for DataStore objects that overwrite are shown below:

Default Value/Possible Entries

Which Fields in the Source?

Default value for the key fields of the error stack (fields selected by the system)

All fields in the source that are uniquely assigned to a key field of the target. This means all fields in the source that are directly assigned to a key field of the DataStore object in the transformation.

Fields that can also be selected as key fields for the error stack

Fields in the source that are assigned to key fields of the DataStore object, but whose assignment is not unique.

An assignment is not unique if it is not a direct assignment. If the assignment is direct, it is also considered to be not unique if there is a start or end routine.

Fields that cannot be selected as key fields for the error stack

Fields in the source that are assigned to a non-key field of the target, to a data field in the DataStore object.

Note

The key should be as detailed as possible. A maximum of 16 key fields is permitted. The fewer the number of key fields defined, the more records are updated to the error stack.

The system automatically defines the key fields of the target as key fields of the error stack for targets that are not updated by overwriting (for example for InfoCubes or DataStore objects that only have fields that are updated cumulatively). In this case you cannot change the key fields of the error stack.

More information: Error Stack and Examples for Using the Error Stack

       2.      On the Update tab page, specify how you want the system to respond to data records with errors:

                            a.      No update, no reporting (default)

If errors occur, the system terminates the update of the entire data package. The request is not released for reporting. The system continues checking the records however.

                            b.      Update valid records, no reporting (request red)

This option allows you to update valid data. This data is only released for reporting after the administrator checks the incorrect records that have not been updated and manually releases the request by setting the overall status on the Status tab page in the monitor (QM action).

                            c.      Update valid records, reporting possible

Valid records can be reported immediately. Automatic follow-up actions, such as adjusting the aggregates, are also carried out.

       3.      Specify the maximum number of incorrect data records allowed before the system terminates the transfer process.

Note

If you leave this blank, handling for incorrect data records is not activated, and the update is terminated as soon as the first error occurs.

       4.      Make the settings for the temporary storage by choosing Goto Settings for DTP Temporary Storage. In these settings, you specify the processing steps after which you want the system to temporarily store the DTP request (such as extraction, filtering, removing new records with the same key and transformation). You also specify when the temporary storage should be deleted. This can be done either after the request has been updated successfully to the target, when the request is deleted or a specified amount of time after the request is processed. Under Level of Detail, you specify how you want to track the transformation.

       5.      Once the data transfer process has been activated, create an error DTP on the Update tab page and include it in a process chain. If errors occur, start it manually to update the corrected data to the target.

 

 

 

End of Content Area