How do you handle your errors?

[TechnoCat]

Hi all,
I was just wondering how you guys are taking care of errors in collaborations, Marshal/Unmarshal - execution - connection, etc...

Just to provide a starting point I'll describe how we are handling them inside our application:
At the moment we are using a java class that independently from configured ETs in the collaboration sends an error ET to an error queue, this is done via a JMS client implementation....
Subsequently the error events are read off the queue by a SQL server eWay and stored in a DB...

This seems to be the suggested implementation by Seebeyond (at least the first portion), apart from the fact that they use an ETD that is configured in every collaboration as an output instance.

I was wondering if anybody else had come up with some esoteric alternative to this?

We are also thinking of implementing retrying to process messages that erred more than once and message replaying, as we call it, meaning the possibility to reintroduce the
msg after being edited...

Got any bright design idea?

Any thought highly appreciated!
Let's share!

Happy coding....

Technocat

 

[DevIntProd]

Technocat,

We do a few things...


In some instances we write the error out to a file, while generating an email to be sent out to support. You can then manually take that file, do any manipulation of data needed and save it. We created a file eWay to then read the file and write it back into the system.

We also write messages out to different files based on the type of exception thrown, some messages we know will not be useful and are just archived to a file, and others are then fixed and re-entered into the system in the manner described above.

In some cases we handle certain errors differently, for instance in one case where most errors seem to be due to a split second SQL error or network problem, we catch the exception and re-try each message up to 4 times pausing 5 seconds each before actually throwing the exception. This solution takes care of most errors due to network latency, SQL timeouts, etc... becuase if it doesn't work in 20 seconds then something is seriously wrong with the application we are calling.

Sometimes we know certain exceptions are thrown that aren't really errors, and we would like to continue processes, so those errors are ignored.


We also write error events to a queue in some instances as well, which are then read by a support application and pages the support personnel that was configured for that given alert.

Hope this helps...

DevIntProd

 

[TechnoCat]

Hi DevIntProd,
thanks for the reply, much appreciated...

I'm new to asynchronous software integration, you conforted me I didn'y get the all thing wrong...

In fact I think our approach is fairly similar...

Thanks.

Happy coding! - Technocat