Misleading exception in XML assembler: The document type does not match any of the given schemas

Misleading exception in XML assembler: The document type does not match any of the given schemas

Normally when you receive an exception with the message “The document type does not match any of the given schemas” in BizTalk, this means your schemas are not (yet) deployed, your are missing an application reference to the project containing your schemas or you have a configuration mistake in your pipeline.

This time, unfortunately, it was not the normal case.

The integration scenario

2015-11-29 13_40_01-Untitled Diagram.html - draw.io

The cause

In our ESB Itinerary Processing stage, we copy/alter most of the incoming context properties. One of the properties copied is the “DocumentSpecName”. This one, was the one responsible for chocking up our send pipeline. (Read this post by Johann for some more info on the subject and other possible scenarios where you might experience this behaviour)

The fix

We choose to reset (= write null) the value of the “DocumentSpecName” property in the “Pre-Assemble” stage in our send pipeline. To make sure the XML Assembler doesn’t choke up.

2015-11-29 12_54_34-Workstation - MultiDesk

The code used to reset the the DocumentSpecName in the “Set DocumentSpecName” PipelineComponent:

1
2
3
4
5
6
7
8
9
private void DoWrite(Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{ 
if (!string.IsNullOrEmpty(DocumentSpecName))
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", DocumentSpecName);
else
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", null);
 
outMsg = inmsg;
}

Misleading exception in XML assembler: The document type does not match any of the given schemas

Misleading exception in XML assembler: The document type does not match any of the given schemas

Normally when you receive an exception with the message “The document type does not match any of the given schemas” in BizTalk, this means your schemas are not (yet) deployed, your are missing an application reference to the project containing your schemas or you have a configuration mistake in your pipeline.

This time, unfortunately, it was not the normal case.

The integration scenario

2015-11-29 13_40_01-Untitled Diagram.html - draw.io

The cause

In our ESB Itinerary Processing stage, we copy/alter most of the incoming context properties. One of the properties copied is the “DocumentSpecName”. This one, was the one responsible for chocking up our send pipeline. (Read this post by Johann for some more info on the subject and other possible scenarios where you might experience this behaviour)

The fix

We choose to reset (= write null) the value of the “DocumentSpecName” property in the “Pre-Assemble” stage in our send pipeline. To make sure the XML Assembler doesn’t choke up.

2015-11-29 12_54_34-Workstation - MultiDesk

The code used to reset the the DocumentSpecName in the “Set DocumentSpecName” PipelineComponent:

1
2
3
4
5
6
7
8
9
private void DoWrite(Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{ 
if (!string.IsNullOrEmpty(DocumentSpecName))
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", DocumentSpecName);
else
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", null);
 
outMsg = inmsg;
}

Misleading exception in XML assembler: The document type does not match any of the given schemas

Misleading exception in XML assembler: The document type does not match any of the given schemas

Normally when you receive an exception with the message “The document type does not match any of the given schemas” in BizTalk, this means your schemas are not (yet) deployed, your are missing an application reference to the project containing your schemas or you have a configuration mistake in your pipeline.

This time, unfortunately, it was not the normal case.

The integration scenario

2015-11-29 13_40_01-Untitled Diagram.html - draw.io

The cause

In our ESB Itinerary Processing stage, we copy/alter most of the incoming context properties. One of the properties copied is the “DocumentSpecName”. This one, was the one responsible for chocking up our send pipeline. (Read this post by Johann for some more info on the subject and other possible scenarios where you might experience this behaviour)

The fix

We choose to reset (= write null) the value of the “DocumentSpecName” property in the “Pre-Assemble” stage in our send pipeline. To make sure the XML Assembler doesn’t choke up.

2015-11-29 12_54_34-Workstation - MultiDesk

The code used to reset the the DocumentSpecName in the “Set DocumentSpecName” PipelineComponent:

1
2
3
4
5
6
7
8
9
private void DoWrite(Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{ 
if (!string.IsNullOrEmpty(DocumentSpecName))
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", DocumentSpecName);
else
inmsg.Context.Write("DocumentSpecName", "http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", null);
 
outMsg = inmsg;
}

BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 2

BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 2

In a previous post I lamented that the JSON encoder pipeline component throws an error if a soap fault is sent to it. My colleague Deepa Kamalanthan has developed a workaround to this issue. The clue to this was taken from a previous post by Johann Cooper. The the JSON encoder pipeline component in our […]
Blog Post by: mbrimble

BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 1

BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 1

We have discovered that if a SOAP fault is sent to a pipeline using the JSON Encoder the following error occurs; A response message sent to adapter “WCF-WebHttp” on receive port “OrderAPI” with URI “/order/v2/Service1.svc” is suspended. Error details: There was a failure executing the response(send) pipeline: “Pipelines.CustomerDetails.Snd_JSON, Pipelines.CustomerDetails, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1bdcdd64c42ec63e” Source: “JSON encoder” […]
Blog Post by: mbrimble

BizTalk 2013 R2 JSON Encoder cannot process SOAP faults

BizTalk 2013 R2 JSON Encoder cannot process SOAP faults

We have discovered that if a SOAP fault is sent to a pipeline using the JSON Encoder the following error occurs; A response message sent to adapter “WCF-WebHttp” on receive port “OrderAPI” with URI “/order/v2/Service1.svc” is suspended. Error details: There was a failure executing the response(send) pipeline: “Pipelines.CustomerDetails.Snd_JSON, Pipelines.CustomerDetails, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1bdcdd64c42ec63e” Source: “JSON encoder” […]
Blog Post by: mbrimble

Microsoft Azure Logic Apps at Microsoft WebCamp Lisbon | December 2, 2015

Microsoft Azure Logic Apps at Microsoft WebCamp Lisbon | December 2, 2015

This post is for the BizTalk Server and other Portuguese Community, will be held on December 2, 2015 between 9:30 – 18:00 the Microsoft WebCamp at Microsoft Portugal in Lisbon. Microsoft WebCamp is the event we created for everyone who loves the Web. With more than 25 super-duper-expert-speakers, like Chris Heilmann and Jon Galloway, bringing […]
Blog Post by: Sandro Pereira

Microsoft Message Queuing Testing Tool updated

Microsoft Message Queuing Testing Tool updated

I just released yesterday, but I’ve decided to do a small update to this tool bringing new functionalities in order to solve some limitations, especially Character Encoding problem. Portuguese language have many letters with accents and while importing/reading the files in the previous version, all accented letters are printed as a question mark. It was […]
Blog Post by: Sandro Pereira