Post mapping for Reject records!!

Question

hi
I would like to capture all the rejected records when I am loading the fact table. I know I can get this information from WB_RT_ERRORS and WB_RT_ERROR_SOURCES. But, what I would like to do is to have Post mapping process which and the action set to "on error", I would like to capture all the reject records into a flat file. Is there a way I can identify reject in the post mapping process other than referring to WB_RT_ERRORS and WB_RT_ERROR_SOURCES in runtime.Because this is what client is requesting for , Any help on this would be greatly appreciated.
Please mark me directly also since I do not get emails sometimes through the distribution list.
Thanks in Anticipation,
Balaji

Answer 1

Reposting the response from M.Van Der Wiel:
2 comments:
- Ideally, you would explicitly capture the errors, and insert those into a separate table. This would enable you to run the mapping in set-based mode (traditionally this means: no error logging) for optimal performance, and you still get the errors. This does mean you would have
to explicitly design what may go wrong, so you should know what your data looks like. Your flat file could then be created out of the explicit error records, which is probably a bit easier (and faster) than to go from the WB_RT_ERRORS.
- The mapping errors out once the maximum number of errors is reached (as passed at runtime; is defaulted by the configuration setting). Anything in between 0 and the maximum number of errors will result in a status warning.
To do what you want to do, you could indeed use the post mapping process, but perhaps you want to design a separate mapping to write the errors to a file, and use a process flow (with conditional sequencing) to run the second mapping (only if the first one fails or results in a warning). This may be a nicer solution than to write the code manually and implement it as a standalone post-mapping process.
Finally, notice that WB_RT_ERRORS and the like are not tables you should directly query (they will change in the future). Rather you should use the ALL_RT_<something> views to access the same information. Going forward, as the customer desires to migrate to a later release, it is
more likely that their customizations still work.
Thanks,
Mark.
PS.
Another possiblity - if the errors violate a key constraint - would be to configure the mapping target with the constraints parameter set to false and redirect the error records to a error table (this can be done in the mapping configuration - sources and targets section). This configuration will disable the constraints during the load and re-enable them after the load, putting the offending records in the error table. You can then download the records from the error table into a flat file in a separate mapping or in a post-mapping process.
Regards:
Igor