Evaluating Logs (SAP Library

Evaluating Logs

Use

Once an external data transfer has been completed, you can use this function to determine the result and to find and rectify errors.

Features

The system creates a list of all transfer runs in which you can see the statuses of the transfers. The status indicates whether a transfer was completed and whether errors occurred. The following statuses are possible:

Status	Meaning
Conversion error	The transfer was terminated in the conversion stage. No records were written to the database.
Canceled	The conversion was successfully completed, but errors occurred in the subsequent processing. The transfer was therefore not completed. It is possible that no records were written to the database. You can find further information concerning confirmed data records in the detail log.
Error	The transfer was completed, but there were business content errors. All of the data records except the ones containing errors were written to the database.
Warning	The transfer was completed, but warnings were output to the log. All of the records were written to the database.
OK	The transfer was completed without errors or warnings. All of the records were written to the database.

Two logs are written for each transfer. These represent the two logical parts of the transfer:

Conversion Stage:

The conversion log is created for every data transfer. The technical aspects of the transfer run are described step-by-step. Errors which prevented the program from running to completion are logged. In the conversion log, you can display all of the sender and receiver records, or just the ones containing errors.

Function Stage:

The detail log is only created if the conversion is completed successfully. It contains information about the checks and the saving of the data for each record which contains errors. If, during a transfer involving header and item structures, only one item from many is incorrect, the whole block will be listed. This includes the header and all items.

You must always use this log in evaluating whether the transfer occurred successfully, as the messages on the screen and those in the spool directly after the transfer run do not always match those in the log.

When evaluating log entries, note that the messages in an EDT log can change over the course of several releases. Both the content and the name of a message can change. If messages are used in programs you developed, you should check them after changing releases.

Error Correction

Sometimes the scope of the imported data does not match the system’s requirements. In this case, you may have to make certain "conceptual adjustments" before you actually correct any errors. You may have to either:

modify the system’s data requirements in Customizing (that is, modify the data requirements to more closely match the data in the operative system).
modify the imported data by changing or enhancing your data selection programs (that is, modify the data to be imported to more closely match the target system’s requirements).

Postprocessing

For transfers which end with status errors, it is possible for you to directly correct the data in each record containing errors. Afterwards, you can transfer the corrected data records to the R/3 data pool.

Output File

You can use the file to make corrections en mass using a small program, which you have written yourself. This would be the best option, for example, if a particular field contains an incorrect value in all of the data records. After running such a program, you can restart the data transfer using the output file with the corrected records as the new input file. The name extensions added by R/3 are listed in the detail log. Types of extensions include the external number, the client, the date, and indicators as to whether the data records were saved in sender or receiver format.

Restart

Under certain circumstances, the transfer can terminate in the conversion or function stage. This could happen, for example, if an overflow of table spaces in the database, a runtime error, or a power outage occurred.

If this happens, and no data records actually reached the database (which means that there would be nothing listed in the detail log about confirmed data records), then you can simply repeat the transfer after correcting the error(s).
If all of the data records have already been transferred, then the database condition is "consistent".
Problems can occur, however, if the transfer terminates during the function stage. If this happens, there is no way of immediately knowing how many records were actually written to the database. The program will thus note how many data records are confirmed (successfully committed to the database.)

A restart makes it possible to repeat the transfer in such a way that the function stage will only be carried out for those data records which were not confirmed the first (previous) time(s). This ensures that the database contains consistent records. Afterwards, if necessary, you can postprocess the data records which contain errors, just as with every other data transfer.