Did anyone else read Kevin Smith’s blog on ACK/NACK and run out to try it? Well, I sure did and found it a little more time consuming then I expected. I have put together a sample that shows how to catch the SOAP exception and get access to the error message. I hope that after looking at this sample Kevin’s excellent post on NACK’s will make a little more sense. It did for me.
DOWNLOAD:
Set-up is easy, just unzip the SampleNACK folder and put it on your C: drive. Then, build and deploy the SampleNACK project. You will need to manually create a Send Port. I set up a File Send Port going to c:\some_location_that_does_not_exist. Set retries to 0. To run it, drop the StartFile.xml message into c:\SampleNACK\In. Your NACK will show up in c:\SampleNACK\Out. Do not forget to look inside the expressions shapes inside the Orchestration for comments. If all else fails, read the ReadMe.txt file.
CRITICAL: Getting at the HTTP error using Delivery Notification will not work for transport type of HTTP or SOAP due to an “issue”. For more information please see Microsoft KB840008.
Key Take Home Points:
- Delivery Notification is not available on Early Bound Ports.
- Must import System.Web.Services to cast the SOAP exception
- Set Send Port retries to 0
- Must use a Synchronized scope
Under the covers:
Ok, so you ask what is BizTalk doing inside the little Delivery Notification property? Keep in mind this is my interpretation.
When a message is sent through a send port with Delivery Notification set to transmitted, a correlation set is initialized. A correlation token is assigned to the outbound message. A subscription is started based on this correlation token. This token is stored in the context property of the ACK/NACK and promoted. When the ACK/NACK is returned, it is routed back to the calling Orchestration. You get all this just by setting a little property to “Transmitted”! Cool!
Take Away: Delivery Notification is an easy way to catch exceptions as long as you understand how to get at the error message.