Hello all,
I join a project where they use BODS (Data Services) to sequence their data flow and use try/catch to list errors.
They feed a table for each flow with this technic and they ask me to find an another way to do that.
Does BODS doesn’t have a tool to follow and see errors? Do we really need to use try/catch to have acces to error log ? I’m very surprised of this behavior.
Thanks by advance to help to see more clearly the situation.
mbdsi (BOB member since 2016-12-01)
[Moderator Note: Moved from General Discussion to Data Integrator -> DI: Performance and Tuning]
Marek Chladny 
(BOB member since 2003-11-27)
You need to get your project to use the ‘Validation’ transform. Then you will be able to filter out your error records.
Nemesis 
(BOB member since 2004-06-09)
Thanks, i will tell about it to my team and try as soon as possible. I’ll come back to tell if it answer to our need.
mbdsi (BOB member since 2016-12-01)
Here’s a useful starting point:-
https://wiki.scn.sap.com/wiki/display/EIM/Data+Validation
Nemesis (BOB member since 2004-06-09)
To answer your question as stated - no, the try/catch functionality is not required to capture errors. These will end up in your error log regardless, though depending on the type of error the entries may be useful or not so much.
There is a difference between error logging, which is what the error log does of course, and error handling. If you have done any kind of programming, then the use of try/catch statements should absolutely not come as a surprise.
Without try/catch blocks, any error your ETL process encounters will be terminal, with your job execution halting right there and then. A Try/Catch block allows you to isolate the execution at whatever level your design requires. This can be an individual script, data flow or a more elaborate work flow or even the entire job itself. Once an error occurs, the catch block will allow you to take any measures required to handle this error.
Because error objects are contextual objects, the Catch block is also the only place in which you can trap the error metadata (e.g. error message, error context, error number, error timestamp) as these will be specific for the error caught in this particular Catch block. (Given the parallel nature of Data Services, it is entirely possible to have two parallel work flows that both trigger errors, therefore the catch block in each would capture the different error that occurred in each parallel stream.)
Once you have caught the error, possibly logged the error metadata in your own framework (e.g. a database table, a text file, etc.), perhaps did some e-mail notifications, you can then also include any steps that may be required to re-attempt the logic that failed, trigger something else, or just gracefully end the job all together. Whatever is required for your situation and design.
One thing to note that is that Data Services will consider the error as handled when it ends up in the Catch block. If you do nothing, the job execution will actually not be flagged as being erroneous - e.g. it will get a green light in your management console. Again, depending on your situation, you may want to manually raise an exception once you have “taken care of business” first.
ErikR 
(BOB member since 2007-01-10)