We will also create a Property Schema (in the corresponding BizTalk project) that will allow us to retrieve the message header from the message contexts once it arrives to the orchestration.
Finally we will just need to deploy the projects (the WCF extension assembly into the GAC and the Schemas project into BizTalk) and modify the machine.config file so BizTalk is aware of our new binding element extension:
"adrb.CustomWebHttpBinding.WebRequestInterceptorBindingExtensionElement, adrb.CustomWebHttpBinding, Version=22.214.171.124, Culture=neutral, PublicKeyToken=0b236f220eb351a7"
In order to test this solution, we will modify the sample ConsumeGET.odx orchestration include in the bLogical REST Start Kit for BizTalk to check for the existence of that custom WCF message header we add when a ProtocolException happens and capture the
status code from it. We need to add a reference to the schemas project (adrb.Schemas) where the property schema was created to define the message header context property.
We will just retrieve the WCF header from the message context of the response message we will receive (that in case of a service failure will be the custom fault message we create in the channel), get the status code from it and suspend the orchestration
(but we could be creating a ESB Toolkit fault message that mentions the status code, trace the information in our logs…)
Read suggested related topics:
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is
BizTalk Server Resources on the TechNet Wiki.
Good article and very helpful. I just update the tags to maintain the conformity with all other articles in the TechNet Wiki.
Thanks for sharing. This has really got me thinking what I am going to do in BizTalk 2013
Great article.. My current client is implementing BTS 2013 and this is extremely helpful
TNWiki Spotlight article: blogs.technet.com/.../tnwiki-article-spotlight-biztalk-server-rest-services-error-handling.aspx
Hi everybody! Thanks Andres for this great article. Could someone have any idea about how to handle errors in the opposite direction? i.e when BizTalk server exposes REST service. The goal is to be able to handle HTTP response status code to set for example 400 value in case of an applicative error managed into the orchestration.