Thanks Stephen, that really was helpful
Yes; your understanding about the process design is correct. Let me just clarify the design a bit more.
One-time setup steps.
1. Create FILE Adapter Receive Port
2. Create a Receive Location on this port to look for *.xml files in a fixed folder.
3. Develop Orchestration.
4. In BizTalk 2006, setup each xml file arriving at the specified receive location to go to Orchestration (xml file schema described in my earlier post).
Here are the steps that my mapping team needs to perform for each new map.
1. Develop Schemas, Map & optionally Pipelines using Visual Studio 2005 (BT06 Project).
2. Deploy the resulting components in BizTalk 2006.
Here's the Orchestration Logic
1. Read XML file to extract & store <inputfilelocation> & <map name>.
2. Read the contents of the file pointed to by the <inputfilelocation> tag (yes, there's a separate .NET component to do this which is invoked by Orchestration).
3. Determine (using naming conventions etc.) if a pipeline is to be executed first.
4. If pipeline is required, invoke pipeline (that's where I have problems since the document contents are not XML and pipeline execution "apparently" requiers an XmlDocument)
5. Invoke map (transform)
6. Determine (again, using naming conventions etc.) if a pipeline is to be executed before sending the document out to send port.
7. Invoke pipeline if required.
8. Send the document out via the single Send Port (again a FILE Adapter).
Send Port uses the token %SourceFileName% to create an output file name so that its get easier for the system to relate an input file to the corresponding output file.
Please let me know if this could be improved or replaced by a better alternative.
The main objective behind designing such a setup is to reduce the amount of setup required on BizTalk 2006 Server. This allows our mapping team to continue to deploy new maps to our BT06 server without worrying about any other setup requirements there.
I am not clear about some of the points you have made and would be glad if you could explain it more.
"You should be able to construct an Xml Document inside an Orchestration and have it be anything" – Does this mean I can load an instance of System.Xml.XmlDocument with an arbitrary string or even a byte array? NO – I think I have misinterpreted your point here.
"You can do both inside the Orchestration, but that’s just not really the best place for them" – Humm! why? performance problems? or better alternatives exists? or something else?
Thanks a lot in advance