Reprocessing Rejects
Reprocessing Rejects in an SR·Agent Script
There are many different reasons why rows would be rejected during a
transport. Here are some possibilities:
- referential integrity is violated
- the row doesn't pass business validation, either within the transport or
in database rules
- the row was corrupt in the file
- out of disk space
- the database or fileserver became unavailable (crashed)
Some problems that cause rejected records require manual intervention. Other problems can be handled within the script. Here is an example script which attempts to fix a referential integrity problem and then re-runs the rejected records.
The script assumes that most rejects are caused by invalid ship_codes in the invoice.data file. Most often, you know what errors are common from direct experience, especially if a transport is run regularly.
The script handles these errors by creating any missing ship_code records (the records are marked as being automatically created), and then re-transporting the rejected records. For example, we may be transporting old invoices with ship_codes that are not in our current ship_codes.
#!/bin/sh
srtransport invoice.transport SOURCE invoice.data \
TARGET -password ""
# if there are any rejected records...
if [ ! -z invoice.reject ]; then
mv invoice.reject invoice.reject.data
# insert any missing ship_codes
srtransport -t invoice_ship_codes.transport \
SOURCE invoice.reject.data \
DEST -password [password]
# retry the rejected records, hoping that the newly inserted
# ship_codes will allow some of these rejects to be transported
srtransport invoice.transport \
SOURCE invoice.reject.data \
DEST -password [password]
# any records rejected here, are rejected for different reasons
fi
|