Show TOC

Handling of Data Records with ErrorsLocate this document in the navigation structure

Use

Using the Error Handling function on the Update Parameters tab page in the Scheduler, you have the option of controlling the behavior of the BW system if incorrect data records occur in the data flow with 3.x objects (use of transfer and update rules) when you are loading data using the PSA.

The system checks for incorrect data records:

  • in the transfer rules

  • in the update rules

  • when data is updated into the master data, text, or hierarchy tables

  • when data is updated to the InfoCube

  • when checking for referential integrity within an InfoObject against the master data tables or DataStore objects on the communication structure level.

Features

Incorrect records arising in transfer rules, update rules, when updating to a data target, or when checking for referential integrity, are highlighted and returned to the error handler. The error handler locates the original PSA records and writes the corresponding log. This function is as yet unavailable for updating to DataStore objects.

You can control how the system responds to incorrect data records using the Error Handling function on the Update Parameters tab page in the Scheduler.

Activities
  1. Define how the system should react to incorrect data records:

    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. However, this data is only released for reporting after the administrator checks the incorrect records that are not updated and manually releases the request (by a QM action; that is, setting the Overall status on the Status tab page in the monitor).

    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.

    Note

    With option a) the incorrect records are marked in red in the PSA maintenance. You can display the relevant error messages amodally, edit the records, and update the request manually. If it was not possible to write into the PSA (hierarchy or transfer method IDoc), an application log is written instead.

    With options b) and c) a new request that is only read into the PSA is formed from the incorrect records. Here you can edit the records of the new request in the PSA and start the update manually.

    If errors arise when an InfoCube is updated, new requests are generated for incorrect records for each InfoCube combination. Among these requests, the incorrect records are updated to the PSA. These new requests have the InfoCubes for which there were incorrect records as their data targets. If, for example, a record was updated to two InfoCubes by mistake, a request is generated for this record that contains both InfoCubes as data targets. In the PSA tree, the requests appear as successfully updated to the PSA. These new requests can then be updated to the InfoCubes again.

  2. Specify the maximum number of incorrect data records allowed before the system terminates the load process. You can display the errors arising up to that point in the PSA. If you do not enter after how many incorrect records termination should occur, the handling of incorrect data records is not active and the update will terminate after the first error.

  3. Select how the BW system should react when the number of data records received by the BW does not match the number of data records updated in the BW.

    There can be a difference between the number of records received and updated. This can occur

    • in the transfer rules

    • in the update rules

    • when updating.

    Records are sorted, aggregated, or added.

    If you set the No Aggregation Permitted flag, the request is deemed incorrect if the number of records received does not match the number of records updated.

    Note

    Regardless of whether this flag is set or not, an error occurs if the number of records selected does not match the number of records received in BW.

Result

The monitor notifies the user of the relevant error case and enables a direct navigation into the PSA or the respective error request.

If you want to continue processing the incorrect data records in a program that you have written yourself, you can use method GET_ERRORS of class CL_RSSM_ERROR_HANDLER. Instructions for using this method is provided in program RS_ERRORLOG_EXAMPLE.

See also:

Checking and Changing Data Using the PSA APIs