How to handle the exception when the send port raises the error with suspended (resumable) status

Conditions:

1. Above orchestration is constructed with just default settings. 2. Logical port Port_2 is configured to use a Send Port with FILE adapter pointing to an unknown URI (purposely, to generate error) and RetryCount = 0 3. Logical port Port_5 is configured to use a Send Port with FILE adapter (normal valid setting).

Will the control flow get into exception handler?

In the above scenario the orchestration will complete successfully without throwing any exception even though the message is not transmitted successfully to the target recipient. The main reason for that is because the orchestration engine successfully persisted the message and state into the MessageBox database. So, from Orchestration perspective the transaction was successful.  But, when the send port picked up the message, it couldn’t transmit the message successfully due to the KNOWN URI configured in the FILE adapter, so it raised an exception and suspends the referenced message with Suspended (resumable) status. Later an adminstrator can correct the configuration in the send port with correct URI and resume the message from admin console, which then will transmit successfully. The end result is the control flow didn’t get into the exception block, even though logically there is an exception in the transmission.

So, how can I make the control flow to get into my exception block:

I made few changes to the Orchestration: 1. I set the “Delivery Transmitted” property to “Transmitted” for Port_2 2. Changed the exception handlers, “Exception Object Type” to “Microsoft.XLANGs.BaseTypes.DeliveryFailureException” 3. Created a new message using Orchestration View called EXC_MESSAGE (just System.String type), and modified the exception handler block as shown in the following figure, added a construct shape with follwing statements inside MessageAssignment soapExc = (System.Web.Services.Protocols.SoapException)delFailException.InnerException; EXC_MESSAGE = soapExc.Detail.InnerXml; where, delFailedException is the name of the catch exception block,  soapExc is a local variable of type SoapException. Now,  the message flow will get into the exception handler block and following ERROR message will be transmitted via the Send shape (eventually to the configured physical send port) configured in the exception handler. <?xml version=”1.0″ ?><string><ns0:NACK Type=”NACK” xmlns:ns0=”http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd”><NAckID>{8F3626A6-E110-49AF-802A-8E85BD5016C6}</NAckID><ErrorCode>0xc0c01c10</ErrorCode><ErrorCategory>0</ErrorCategory><ErrorDescription>The FILE send adapter cannot open file C:BTSSamplesListen Timeout ExceptionFile Drop32. OUT RES{66A1BABF-5509-42CE-82F8-0E100852C526}.xml for writing. Details: The system cannot find the path specified. </ErrorDescription></ns0:NACK></string> You can do lot of things with this error message now, like for example: you can email it to the adminstrator.

Summary:

So, there is nothing new here “Delivery Notificaition” and “NACK” messages are been there for a very long time. The reason for this post is a result of 2 questions raised in the newsgroup 1. My Control flow is not passing to the exception handler, and 2. How to handle Suspended (resumable) exceptions within orchestration. Nandri! Saravana