6

Good afternoon all,

I've got an issue with a BizTalk orchestration that's really odd.

The first receive shape of my orchestration fails with the following message:

There was a failure executing the receive pipeline:
 "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines
Source: "XML disassembler"
Receive Port: "ReceiveCanonicalPort"
Reason: Finding the document specification by message type
"http://www.openapplications.org/oagis/9#ProcessInvoice" failed.
 Verify the schema deployed properly.

I put together a test document with the first few lines like this:

<?xml version="1.0" encoding="utf-8"?>
<ProcessInvoice
  xmlns="http://www.openapplications.org/oagis/9"
  releaseID="9.0"
  targetNamespace="http://www.openapplications.org/oagis/9"
  >

What I've checked already:

I've checked the schema: The target namespace is 'http://www.openapplications.org/oagis/9' The root node is 'ProcessInvoice'

The schema validates.

My input file validates against the schema.

I've checked the schema is deployed.

I've looked to see if there is another schema with a duplicate namespace and root node.

I've restarted the host instances and redeployed several times.

I tried setting the xml disassembler 'allow unrecognized message' property to true. This results in an object not set to an instance exception instead. Which would seem to indicate that it's not de-serializing it.

I've prayed to the great god Boogie.

Any other ideas?

Thanks

Jay
  • 13,803
  • 4
  • 42
  • 69

1 Answers1

8

You must have another version of that schema defined somewhere in another assembly.

Are you sure you have checked every possible application (include BizTalk Application 1)?

The only other thing I can think of is maybe you have an assembly redirect in the config file which is redirecting to a version which does not exist, however I am not certain you would even get your observed behavior if this was the case.

Another thing - maybe an older version of the schema is GAC'd and a host instance still has hold of it. Try rebooting to ensure.

Hope this helps.

tom redfern
  • 30,562
  • 14
  • 91
  • 126
  • Thanks, I'll check that again. To check for a duplicate I looked at the "" section and sorted the Schemas by the namespace. – Jay Sep 30 '11 at 21:07
  • All Artifacts should have done it. I am out of ideas. It is very bizarre. How about maybe an older version still GAC'd and a host instance is still hanging onto it? – tom redfern Sep 30 '11 at 21:10
  • 1
    I believe I've found it. There's another assembly with a different schema in it but the same namespace. That results in two different schemas in two identically named assemblies. The schema I'm not using for this project has a later version number. So I'm thinking the other schema is hiding this one because of the name collision and the version number. – Jay Sep 30 '11 at 21:23
  • I also faced same kind of issue and it was the issue with assembly. I did the silly mistake of not restarting the host instances and I suppose it was referring the older schema in cache (I may not be right here). After restarting the host instances, issue was resolved. – v_kumar Feb 21 '19 at 09:05