Recently I needed to include exception handling in a web service call to an external party. I learned a couple of things and thought I’d highlight them here.
Exception handling doesn’t always behave the way you expect when you are trying to catch exceptions when calling a web service. While using one is very useful some things must be considered or you will not get the result you wanted.
Here is one way to do it as well as a few things to keep in mind when you want to set one up:
- Include the external web service call (both send and receive shapes) in either a non-transactional scope shape or a long running transaction.
- Decide if you need to catch any specific exceptions, if you don’t, using the General Exception will suffice. If you need to catch specific errors, you can use multiple catch exception blocks.
- It may sound obvious to say this, but make sure your orchestration doesn’t have a timeout that is the same length (or shorter) than the timeout of your scope transaction.
- Most important: in your send port which holds the reference to the web service, make sure you are not using any retries (unless, of course, you explicitly need to). If the web service fails with an error such as “There is an error in XML document (5, 10)” and you have retries enabled you will only see warnings in your event viewer (which means the exception block won’t be activated until the SOAP timeout).
Contents
ReBlogger Contents
Email TopXML