I recently had a need to create a send port that could output a flat file but I could not determine which flat file schema to use at design time. Or at least I didn’t want to. I wanted to process multiple flat file formats with the same orchestration process and output with the same send port. I have my orchestration dynamically mapping the document to the appropriate flat file document schema. The generated orchestration message type is set to System.XmlDocument so the orchestration can handle the varying message schema types, but how to output them with a single port.
The problem is with the pipeline. The port uses a custom pipeline that uses a flat file assembler to generate the flat file. In the configuration of the assembler the flat file document schema to be generated is specified. So how to dynamically set the pipeline… I have yet to find an answer to this problem (I’ll let you know when I do!).
There is an easier solution to this problem. It is very simple once you know how the assembler and for that matter the receive pipeline disassemblers work. When we specify the schema in the components we are basically telling the pipeline which schema to use to process the message. So what happens if we do not specify a schema?
This is the interesting part, especially for the assembler component. BizTalk already knows which schema to use. Using the schema type (the combination of TargetNameSpace#RootNodeName) form the message, BizTalk can ask the configuration database which schema to use. Therefore by not specifying a schema in the flat file assembler you create a pipeline that can assemble any flat file BizTalk has a schema for. Although this works well for the XML disassembler as well it is not so easy for flat files. Like most the other pipeline components the disassembler can contain multiple disassemblers but unlike the rest the message flows through differently. As the message hits the first disassembler it tries to process the message, if it fails, it will try the next disassembler. When is succeeds in identifying the message and applying the schema it ignores the rest of the disassembler components and carries on down the pipeline. All other multiple pipeline components are processed sequentially. This information is displayed in the pipeline designer, but I never realised the significance.
Note the benefit of specifying the schema is for performance. There is more overhead if the pipeline has to search for the schema to use.
Hope this helps