by Jeroen | Nov 29, 2015 | BizTalk Community Blogs via Syndication
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
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.
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;
}
|
by Jeroen | Nov 29, 2015 | BizTalk Community Blogs via Syndication
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
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.
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;
}
|
by Jeroen | Nov 29, 2015 | BizTalk Community Blogs via Syndication
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
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.
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;
}
|
by community-syndication | Nov 28, 2015 | BizTalk Community Blogs via Syndication
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
by community-syndication | Nov 25, 2015 | BizTalk Community Blogs via Syndication
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
by community-syndication | Nov 25, 2015 | BizTalk Community Blogs via Syndication
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
by community-syndication | Nov 25, 2015 | BizTalk Community Blogs via Syndication
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
by community-syndication | Nov 25, 2015 | BizTalk Community Blogs via Syndication
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
by community-syndication | Nov 24, 2015 | BizTalk Community Blogs via Syndication
In the last couple of days I been working (migrating a BizTalk Solution from BizTalk Server 2004 to BizTalk Server 2013 R2) in a solution that works deeply with Microsoft Message Queuing (MSMQ). It receives messages from private queue with the use of the MSMQ Adapter and send messages to other Queues (among other channels) […]
Blog Post by: Sandro Pereira
by community-syndication | Nov 23, 2015 | BizTalk Community Blogs via Syndication
I don’t know how you all keep up with technology nowadays. Has there ever been such a rapid rate of change in fundamental areas? To stay current, one can attend the occasional conference, stay glued to Twitter, or voraciously follow… Read More ›
Blog Post by: Richard Seroter
