Like most of you, we have the standard try/catch - Seq (success) /Seq (failure) / seq (done) logic to catch errors, and handle them it need be. I some of the cases we will catch and error and depending on the error, fix it right on the spot programmatically.
Now here’s the problem:
It still goes to the error log and since have set up e-mail notifications, someone gets a message for an error that has already been handled. Is there anyway in the seq (done) step to tell IS not to treat this as an error, since it has already been caught?
Great question. We abstracted the Exception event and created our own services to send error emails. It’s part of our Sarbanes-Oxley compliance program. We don’t use the out-of-the-box error email functionality provided by Integration Server.
In our catch block, we get the last error, grab the interesting info from the error document, and create/send an email to the interested parties using pub.client:smtp.
I just realized that I gave the abbreviated version of our error handling. I am conditioned to simplify topics when talking to users. There is no need to simplifiy with this audience.
We grab the error info in our catch block and build an Exception document which we then publish to the Broker. We have a few different triggers listening for exception events. Some take the Exception document and send out emails. Some triggers only subscribe to Exceptions that have a critical status. These triggers use SNPP to send info to pagers. As we build out, we could conceivably have triggers listening for exceptions that will send via SNMP.
Actually, we already do something like that in our catch statements, as well as throwing errors when data violate our business rules. Of course some errors are caught and handled by the program logic without sending a message, because we anticipate certain errors. The out of the box IS e-mail is used to catch things that may not be part of a catch block (and hence wouldn’t be caught any other way). The problem with this is twofold:
There is no key information in this notification like there would be when a document is generated from a catch block.
There is not indication that this particular error may have already been caught and handled (either with corrective logic or by sending a more informative message).
It sounds like our only recourse is to make darn sure the all errors are caught and then turn off the out of the box functionality.