Working with Fault messages & BizTalk 2006 R2

by | Aug 27, 2008 | BizTalk Community Blogs via Syndication | 0 comments

A while ago I needed for several request/response orchestrations to create a fault message.

When an exception occurs in an orchestration it’ll timeout and won’t send a soap fault message. At least what you want to do is send a message that something went wrong. In my case I wanted to send the detailed exception as well.

I found several sources on the Internet but they weren’t all that complete.

My scenario works at least for the following scenario:
I have a request/response orchestration, hosted as WCF receiveport. All underlying webservices are WCF hosted services.

The Fault messaging howto

Btw, this howto assumes some basic knowledge of BizTalk 2006 R2 and WCF

  1. First your orchestration needs to be long running. This is due to the fact that the send port is encapsulated by an atomic scope.
  2. Create an scope were all ‘the magic’ happens. (see screenshot)
  3. Now create the exception handler.
    You can choose exception or in my case I choose SoapException.
  4. Now create your request/response port. When that’s done, give a sane name to the operation and right click to create a Fault message.
    You can choose to create a string as fault message or something else. But a different approach can also be very handy.
  5. Create you own custom fault contract within WCF, example code:
    [DataContract(Namespace = "http://mynamesapce/2008/08/Faults", Name = "OperationFault" )] 
    public sealed class OperationFault
    {
        private string _message = String.Empty;
     
        /// <summary>
        /// Creates a new, uninitialized instance.
        /// </summary>
     
        public OperationFault()
        {
        }
     
        /// <summary>
        /// Creates a new instance.
        /// </summary>
        public OperationFault(string message)
        {
            _message = message;
        }
     
        /// <summary>
        /// Creates a new instance.
        /// </summary>
        public OperationFault(Exception error)
        {
            if (error != null)
            {
                _message = error.Message;
            }
        }
     
        /// <summary>
        /// Gets or Sets the message
        /// </summary>
        [DataMember]
        public string Message
        {
            get { return _message; }
            set { _message = value; }
        }
    }

  6. Create a message within the orchestration and choose the OperationFault class as your message.
  7. Assign the message to the Fault port.
  8. Now comes the part were we take a look at the exception scope handler. If we look at the scope exception handler below:

    This is the send share with the atomic scope around:

    So if the send did not succeed. (e.g. An exception occurred earlier). At the moment the exception raises we need to construct the Fault message.

    The code for the messageassignment looks like this:

    FaultMessage =

    new MyNamespace.FaultContracts.OperationFault(soapException.Message + soapException.StackTrace);

    Btw you can put any kind of message you like.

    The extra decide is necessary to let the orchestration/compiler believe that the send only executes if the other didn’t complete or didn’t start.

    The code for the decide:

    !succeeded(TransactionName)

  9. Now you’re done for the orchestration part!. So for a recap the complete orchestration (Sorry without the connected receive and send shapes.)
  10. If you make from the orchestration call to external webservices via WCF, don’t forget to NOT enable this setting:

    Propagate fault message.

    This options is used if you want to have separate handling of (typed)exceptions from a (wcf) webservice. Theirs only one disadvantage that you can’t handle generic soapexception quite easy.



  11. On the consumer side of the BizTalk orchestration you can use the OperationFault class to catch the exception.

Sources

I’ve to thank my former colleague: Fedor Haaker Together we implemented this kind of error handling. (Although he came up with operationfault solution.)

So big up for Fedor J

Submit a Comment