Tallan Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

WCF-WebHttp and custom JSON error messages

I’m currently working on a solution that exposes a BizTalk Orchestration as a RESTful webservice using WCF-WebHttp.  Upon successful processing of the message, the service returns binary data for the client to download.  However, if the processing fails, I wanted the service to return application/json data with an error message that would be suitable for consumers – I did not want Stack Traces or other internal details to be provided that could potentially be used by malicious consumers.  Further, I wanted to ensure this information was sent in the same session.

Initially, I created a schema with my sanitized error information, set the Fault Operation Message Message Type to that schema, and enabled “Include exception details in faults.”  While this did end up including my custom error message, it also included the extra information I was trying to avoid.  It also meant always sending back the error reply using HTTP status code 500, which is undesirable if the error is actually in the message submitted.  Finally, the message was being returned in XML, which would be more challenging for my JavaScript-based clients to parse.

To resolve these issues, I created a custom WCF Behavior with three classes.

The class which does most of the work, SanitizedJsonFaultHandler, implements IErrorHandler, and contains a subclass JsonErrorBodyWriter to help with JSON serialization.  In the ProvideFault override, I parse the exception message into an XDocument.  One of the fields in that document is the HTTP Status Code I wish to use for that message (400 if the validation of the file failed, 500 if an internal exception occurred); this field gets removed, as it would be redundant to include it in the message body.  I then set the fault message using the JsonErrorBodyWriter class to serialize the XML message to a JSON message.  The message has only a root node and string value child nodes.



Two other classes help make this behavior available to the BizTalk adapter.  One implements IEndpointBehavior, adding my custom error handler to the endpointDispatcher:


And another overrides BehaviorExtensionElement so that this behavior will be visible to the system:


Finally, I added the following line to my machine.config files (32 and 64 bit; replace FULLNAMESPACE with your namespace and FULLY_QUALIFIED_NAME with the FQN of the DLL you create and GAC.  This information can be found by running the command ‘gacutil /l | find "WCFBehaviors"‘).

<add name="SanitizedJsonFault" type="FULLNAMESPACE.WCFBehaviors.SanitizedJsonFaultBehaviorElement, FULLY_QUALIFIED_NAME"/>

With this done, I restarted IIS and BizTalk.  Then I was able to add the endpoint behavior by right clicking on EndpointBehavior:


Now, my orchestration can log the sensitive information for later review (or send it to an administrator directly), and the fault message is sent back to the client like so:

500 error:



400 error:HTTP500


Learn more about Tallan or see us in person at one of our many Events!

Share this post:

5 Comments. Leave new

Tomer Schwartz
February 5, 2015 5:27 pm


What would be the Raw Http response in that case?
I am getting a root element with a single child element which is a Json format. It seems like a Json within an xml. As follows:
{“ErrorCode”:”UnsupportedRequest”,”Description”:”Some Description”}

Is there any way to get rid of that root element and still have a valid Json body?


I’m not sure I’m entirely clear on your question. Are you using Fiddler to view the raw HTTP response? Is the JSON wrapped in an XML tag?


Very useful for added security on regular (non-biztalk) WebHttp services as well. Thank you!

how to read these errors in bitzalk orchestration

Neal Walters
April 3, 2018 11:28 am

Will the IErrorHandler fire when calling an external web service? I added IErrorHandler similar to yours, but it’s not firing (I do see it added to the ChannelDispatcher.ErrorHandlers. Your example is great but it’s an orch published as a web service, where as I have an orch calling an external webservice. I’m catching a 400 error, but it’s leaving the WCF-SendPort suspended, and I’m trying to avoid that. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>