| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ESQL Try Catch pitfall |
« View previous topic :: View next topic » |
| Author |
Message
|
| m.schneider |
 Posted: Wed Dec 03, 2008 6:29 am Post subject: ESQL Try Catch pitfall |
 |
|
Centurion
Joined: 10 Apr 2007
Posts: 132
Location: Germany
|
Hi,
I'm using a utility esql modul with procedures that are used from multiple flows. There can also be an error within this procedures. Which options do I have to catch this errors in the calling module?
1. Use an errorreference that gets passed into the procedure and is queried after leaving the called procedure.
2. Use an exit handler that catches an error thrown in the called procedure, ... This would be nice if it hasn't the implication that you have to uncheck the option on the flow that WMB handles DB errors, ... This would mean if I want to use an exit handler all db-operations needed to be checked manually as well, .... 
For me handling all db-operations is not an option, so back to good old passing of references and querying errorcodes.
How do you handle errors in utility-modules? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Dec 03, 2008 11:18 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You have at least a couple of options to catch DB errors in flows.
1) Leave the Compute/Database node to treat any errors as Fatal and throw an exception
2) Add a check on SQLState in the ESQL.
I prefer the second BECAUSE there are times when you may want to check the Error code that is returned from the DB and act accordingly.
For example,
An insert of a multiple record into a transient table. In this particular flow we didn't care if there was already a record with the same Primary Key in the table. So a check on this was made in the esql and ANY OTHER error apart from that was THROWN after collecting data about the DB operation.
Every DB operation had the same check and conditional code to all us to differentiate between the different calls so that investigation of the errors can be improved.
As a general point,
Anything in this area needs to be incorporated into your general schema for handling errors. If you can make it common over all your flows then things become much easier to manage in the longer term. You design one set of Error Handling SubFlows and consturuct all your main flows to use these common subflows. Nodes like EmailOutput & FileOutput are your friends there. Add the ZIP node and you can capture loads of detail from the flow (including the original message and the Exceptionlist)
Generally, I'd recommend putting a TryCatch at the point where any flow initialisation has completed. Hook the error code up to this.
Then if there are errors in your error handling, they will roll back to the node that started the flow. In the case on WMQ errors, I normally, let it roll right back out of the flow onto a BOQ which is externally monitored.
But, the overall business requirements will drive how you actually do all this 'stuff' but as you are already re-using subflows, I think you are on the right track.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| j.f.sorge |
| Posted: Thu Dec 04, 2008 12:12 am Post subject: Re: ESQL Try Catch pitfall |
|
|
Master
Joined: 27 Feb 2008
Posts: 218
|
| m.schneider wrote: |
...
2. Use an exit handler that catches an error thrown in the called procedure, ... This would be nice if it hasn't the implication that you have to uncheck the option on the flow that WMB handles DB errors, ... This would mean if I want to use an exit handler all db-operations needed to be checked manually as well, ....
... |
I think that when you define your own procedure where you call the utility method you should be able to define an exit handler which is only valid for this small block. But there is a problem when you call a db in the utility method. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
