Using BizTalk 2006 Mapping Engine

Unfortunately I disagree with Stephen on this one:

The biztalk Mapping engine just uses Xsl Transformations to convert from one Xml format into another (mostly). The work of creating an Xml document from a non-Xml document is done by parsers in the Disassemble stage of the pipeline. To convert messages from one format to another they must be converted into Xml first.

The mechanism of sending Biztalk a message with a file name that Biztalk then processes thru a pipeline seems like a lot of work  for not much gain. Why not have multiple receive locations all looking at a directory and using a file mask. So Xml files are *.xml, Excel files are *.xls, flat files are *.txt, etc. Each receive location would include a pipeline for handling a particular message type. If you wish to add a new message type simply add a new receive location.

1. Is this the correct way to utilize just the mapping engine of BizTalk 2006?
I don't think so

2. Can an XLANGMessage object be initialized with ONLY XML format messages? How can I construct an XLANGMessage for a non-XML file?
Biztalk is able to move a non-Xml message from Receive port thru an orchestration and out a send port without ever converting it into an Xml message. You only need to convert into Xml if you wish to use access data from within the document or to change the Xml format using the mapping engine. To use non Xml messages just use the Pass-Thru pipeline to accept messages.

3. I may need to use a Pipeline at Send Port too (e.g. for CSV to EDI mapping where both the input and output formats are non-XML). Can I use the same mechanism at the Send Port as well?
To convert from CSV to EDI you will need to write your own custom code to do this. You can either write generic code that can handle  any CSV to any EDI, but then you would need a mechanism (like a schema for defining the input and output formats). Or you could write specific code to convert from one specific CSV format to one specific EDI format.

4. If this does not seem to be a proper solution, can anybody recommend a simple & practical approach to utilize BT06 Mapping Engine for translating different types of documents (EDI, CSV, TXT, XML etc.)?
The Biztalk Messaging engine has been designed to do just this. However it does not have a many to many translation capability. It will accept a message in many formats using a disassembler to convert to Xml (this is extensible as you can write your own disassembler. It can then  process and transform the message and then send it using an Assembler to convert into many formats, again you can add you own assemblers.

Can you explain a bit more about the overall purpose of your solution. What are you trying to do?

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

The messages passed thru Biztalk are a serializable .Net class that contain a message context (dictionary of name/value pairs) and a stream of bytes.

In an orchestration you can receive a message of type XmlDocument. This does not mean the message has to be Xml. It means there is no MessageType on the messagebox subscription, so it will accept any type of message, even an image file. You will still have access to all the message context properties promoted by the adapter and pipeline components, including the FILE.ReceivedFileName if the message came from a file adapter.
So your mechanism of sending an Xml file with the file name, which then uses a .Net component to read the file is not needed. You can simply have a single receive location with a file mask of *.* , a pass-thru pipeline and an orchestration accepting untyped messages, you will have achieved the same result.
You could still use other receive locations on this receive port to accept xml files for example. Have a single receive location with the XmlReceive pipeline, which would determine the message type for you. In the orchestration you could check to see if BTS.MessageType property is set this would save you calling a receive pipeline first. Otherwise you can use your custom logic inside your orchestration to determine the pipeline to call to process the input file, perform some logic and and call the output pipeline and send the output. You still need to have a lot of configuration, that will enable you to determine which pipelines to call.

Personally I would use as much of the functionality in the product as possible. The configuration setup is a one-off task that will probably be less effort than writing, testing and maintaining your own version of message routing.