Welcome back to the “Throwing typed WCF faults back to consumers in a BizTalk messaging only application” blog series.  This is the 2nd part in the series and specifically focuses on creating and publishing your typed fault so that it is available for use in further sections of the series.  If you haven’t yet read the prior entries in this series then follow the below links before you continue reading this entry.

Part 1 : Introduction

First things first, we need to create a class representation of the typed fault that we want to throw back to service consumers.  The details I want to share with consumers are a fault code, the list of possible fault codes being shared with service consumers through interface documentation, a reason, which serves as a summary of the error, and a message which contains the details about the particular fault.  In the case of an XML schema validation failure the object might be populated with a fault code of XMLVAL, a reason of Schema Validation Failure, and a message describing exactly which node in the XML message caused the problem and what the schema violation was.  Once the class has been created, the project should be built with a strong name key and the assembly should be added to the GAC.

Note that your class does not need to inherit from the System.Exception base class (in fact this might cause problems for the XML serializer, it definitely causes problems with the XSD.exe tool).  Rather it can be your own custom class with no inheritance requirements.

A few important notes.

  • In order for your class to be serializable it must implement a default constructor.
  • You will want to decorate your class with a DataContract attribute.  You might want to specify the Name property on the DataContract attribute if you want to use a friendlier name in your serialized XML representation of the class rather than the class name.  You will definitely want to specify a Namespace to avoid clashes with other classes with the same name.
  • Likewise you will want to decorate any properties in your class that you want to get serialized into your XML with a DataMember attribute.  I make it a habit to specify the Order property on the DataMember attribute to explicitly state how I want elements to be ordered in the XML rather than leaving it to the serializer to decide this (I believe the default ordering is alphabetical which might or might not work for you).  As with the DataContract attribute you might choose to override the Name of the element in the serialized XML.

After taking the above into account my class looked like the below.

ExceptionClass

In preparation for the next post in the series I used the XSD.exe command line tool to generate the schema representation of this class and added it to a BizTalk project which I would then deploy to my environment.  In order to do this I had to browse to the bin\debug folder into which the assembly that contains aforementioned custom exception class gets built to in a Visual Studio Command Prompt, and run the following command – “xsd.exe {Assembly name}.dll /type:{Fully qualified class name}”.  This utility will generate an XSD file in the same folder location which you can then rename appropriately and copy to the relevant BizTalk project folder and add it to your project.  What I did find was that the generated schema had an empty target namespace (possibly due to a mistake I’ve made in my exception class but I haven’t had time to figure that step out yet) so I added that to the schema manually.  The schema now looks like the below.

ExceptionSchema

We now have a custom exception class and schema created that represents our typed fault, which we can expose in the service’s WSDL and return in place of out of the box BizTalk exceptions which will be explored in the next entries in this blog series.

If you are interested in reading further then do follow the links to further entries in this blog series.

Part 3 : Publishing the typed fault contract in the WSDL

Part 4 : Creating a custom error handling service behavior

Part 5 : Creating an endpoint behavior to copy headers and the SOAP action from the request to the response

Part 6 : The client experience