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: “http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo#StoredProcedureName“.
Cause
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.
Solution
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!
