I’m thinking this is a bad thing if you want dynamic resolution.
I’ve experienced this with both the XMLReceive and a Custom Flat File Receive Pipeline
(I built).
1. Both worked a treat – ‘5 minutes ago’ as I’ve been working away.
2. Went into the BizTalk Admin console and ‘adjusted’ a property on the pipeline at
the receive location ->clicked on the ‘…’ button next to the pipeline.
3. Even if you dont change anything and hit OK…you’re affected.
4. XMLReceive + FlatFile both complain about ‘blank document
schema‘ which must be specified.
(as in this case I’d changed a few things coding….it took me AGES to come back to
here)
I even explicitly supplied the correct schema as a property on the FFDASM component
I was using and no go!
5. Resolution: go back to the pipeline within the receive location (or send
port) and select another pipeline from the list. Click OK to close the property window,
then repeat and add your original pipeline but dont go into the pipeline per instance
properties pages
Why does this happen??? (yeah good question 🙂
Basically both the XMLDASM and the FFDASM take precedence with Per instance pipeline
config properties than *anything* else you provide.
e.g. Dynamically processing a flat file – check the SDK example, but here’s a pseduo
version.
…..
//Flatfile schema resolver – normal technique.
DocumentSchema docSpec = ……determine which deployed schema to use.
//this line basically tells the Disassemblers which schema to apply.
msg.Context.write(“DocumentSpecName”,”<system namespace xml-norm>”,docSpec.DocSpecStrongName);
_myFFDasm.Disassemble(msg); // line – *
These above lines will work for a year and a day (I’ve tested this) and in both 2004
+ 2006, but NOT when you add perinstance pipeline configs – it seems all ‘dynamic-ness’
has gone out the window.
When per instance pipeline config is specified, this config data is provided as
a Message Context Property (ReceivePipelineConfig) and XMLDasm + FFDasm only look
at this for their values – painful.
So as in my case, I hadnt specified a Document Schema within the pipeline config as
this pipeline was dynamic (c.f. like the xmlReceive).
I explicitly assigned a Schema to the FFDasm.DocumentSchema property and still
got the same error as before.
Removing the Config Data did the trick 🙂
Given that this is the case – I think when you hit ‘OK’ to save the pipeline config
data a warning/message of some description should come up as you may be wanting to
modify ‘one’ value – ‘omit xml declaration’ for example. The rest of the properties
are written in as blanks.
Hopefully I’ve saved you a bit of pain from mine.