A few days ago, I blogged about splitting documents.
It seems that there’s a bug in BizTalk that means this approach won’t work. The typical pattern when defining an envelope schema is to define your repeating node as one schema, and xs:import it to your envelope schema (for details, see Jan Tielen’s excellent blog entry).
Unfortunately, if you create a map that maps to your envelope schema (for example in my case because the envelope schema is also the canonical batched data format), then that map is unable to execute in a receive port (and presumably a send port, although I haven’t checked). When a document is received, you will get the following error logged in the Application log:
Document type “uri:my-uri#Customer” does not match any of the given schemas.
(where uri:my-uri#Customer is the root node of the xs:imported schema).
Hugo Rodger-Brown also ran into this at the same time as me so we’re both left scratching our heads.
I can’t help feeling that this is somehow related to Scott Colestock’s old post where he notes that, unless you have a fully qualified assembly name, a pipeline will fail to load your schema because BTS simply doesn’t know which assembly to search for the type.
Obviously, receive port maps are run after the pipeline, but I still feel it’s all relating to the same kind of issue. If you open up the source of a .btm file, you’ll see that the node only references the type of the destination schema – it doesn’t use a fully qualified name. Unfortunately, editing the map source to use a FQN won’t work (the mapper shows an error in the designer).
So, in summary it looks like you simply can’t map to a schema that references other schema from within a receive (& send?) port. Note that it works fine from within an Orchestration – probably because the Orchestration has a reference to the correct assembly, and so it can resolve the type name successfully.