There was a failure executing the send pipeline: Microsoft.BizTalk.DefaultPipelines.XMLTransmit, Microsoft.BizTalk.DefaultPipelines, …. – This Assembler cannot retrieve a document specification using this type: namespace#rootnode

I wrote this issue many years ago in this blog post, and I’m revisiting it to add more information about it because today I got the same error while trying to communicate to a SQL Server and call a Stored procedure:

There was a failure executing the send pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLTransmit, Microsoft.BizTalk.DefaultPipelines, …” Source: “XML assembler” This Assembler cannot retrieve a document specification using this type: ““.


The causes I wrote in the previous blog post are still valid:

  • The Application made a reference to another Application that contained one schema with the same namespace#rootnode name
  • The Application has different resources (DLL) that contain more than one schema with the same namespace#rootnode name
  • The schema defined by namespace#rootnode does not exist (not my case, because it was deployed)

But in my case, it was a slightly different reason:

  • I had a different BizTalk Server application, another BizTalk Server Visual Studio Solution, that called that exactly stored procedure. That means that I had the Stored Procedure schema with the same namespace#rootnode deployed in two different applications (in two different DLLs or assemblies)

In fact, the solution I was creating was version 2 of that previous application, but both needed to run side by side for a short period of time.


Once again solution that I described in the previous post is valid:

  • You need to change the namespace or the root node of one of the schemas. If it’s a common schema, you can deploy it separately to a common application and add a reference to that application.

But in my case, that would break the existing application deployment logic, and I wanted to keep everything the same. So, the solution was to recreate a copy of that Stored Procedure in the database with a different name and generate the schema for that. Since this was a new solution, it was an easy fix and solved all our problems. It was even better because we didn’t break the existing application if we needed to change something on the SQL part.

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

Leave a Reply

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


Back to Top