Handling of Data Records with Errors 

Use

Using the Error Handling function on the Update Parameters tab page in the scheduler, you can control the behavior of the BI system if data records with errors 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 data records with errors:

●      in the transfer rules

●      in the update rules

●      when data is updated to the master data tables, text tables, 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 not yet available for updating to DataStore objects.

Using the Error Handling function on the Update Parameters tab page in the scheduler, you can control how the system responds to incorrect data records.

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. However, the system continues to check the records.

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 (using a QM action, that is, by 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.

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 to the PSA (hierarchy or transfer method IDoc), an application log is written instead.

With options b) and c), a new request that is only updated to 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 entered as data targets the InfoCubes for which there were incorrect records. 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 in the PSA. These new requests can then be triggered again for updating to the InfoCubes.

       2.      Specify the maximum number of incorrect data records that are allowed before the system terminates the load process. In the PSA, you can display the errors that have arisen up to that point. If you do not specify the maximum number of incorrect records after which termination should occur, the handling of incorrect data records is inactive and the update terminates after the first error.

       3.      Define how the BI system should react if the number of data records received by the BI system is not the same as the number of data records updated in BI.

A difference between the number of received and updated records 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 indicator, the request is deemed incorrect if the number of received records is not the same as the number of updated records.

Regardless of this indicator, an error occurs if the number of selected records is not the same as the number of records received in the BI system.

Result

The monitor directs the user to 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 the method GET_ERRORS of class CL_RSSM_ERROR_HANDLER. The use of this method is documented in the RS_ERRORLOG_EXAMPLE.

More Information:

Checking and Changing Data Using the PSA APIs