- This topic has 3 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
Hi all,
I have the scenario where I have at least 17 suppliers of data, sometimes flat file, some in xml and some in other formats entirely. What I would like to do is transform all these formats into one format which I can then send through the process.
I assume I have to define a schema for each and every source, that’s cool I got that sorted.
Now how do I convert all these various messages into a single schema?
Do I have to create an orchestration for each and every input schema to call do a transform through a map into the format I want?
What is the best practise for doing this in biztalk 2004?
I would really appreciate guidance and direction on this one …
Thanks
Ryan -
Thanks Greg;
I was hoping to avoid having multiple receive locations for each provider. I was thinking of trying to manually assemble the flat files into xml, similar to how i imagine the flat file pipeline does it. Once i had it into XML i could then do the transforms dynamically.
Do think this approach will work?
Or should i just stick with multiple receive locations?
-
Ryan,
There are a number of ways of handling this:
1. One receive port, with one inbound map for each document type, that maps into you internal format. The port will apply the map whose input schema matches the message type of the received message. You can have one or more receive locations, but each one must have a pipeline that will identify the message type e.g using the Xml Disassembler, FlatFile Disassembler
You have one main process orchestration that binds to this receive port.
[list:0e4927cbca]Advantages: Additional suppliers just require a new map and config changes to the receive port and possibly a new receive location
Disadvantages: Issues with document validation in pipeline, requiring custom pipeline components – although this issue is addressed in BTS2006[/list:u:0e4927cbca]
2. One orchestration for each document type containing a Transform shape to map into your internal format. Plus your main process orchestration. You can use Direct ports between your transform orchestrations and the main process orchestration. You can have one or more receive ports in this scenario, each transform orchestration can bind to the same or different ports. Again you will need pipelines to identify the message type
[list:0e4927cbca]Advantages: Additional suppliers just require a new map, new transform orchestration and config changes to the receive port and possibly a new receive location. You can also use an extra transform (XSLT) for document validation.
Disadvantages: Issues with document validation in pipeline, requiring custom pipeline components – although this issue is addressed in BTS2006 or by using a XSLT validation[/list:u:0e4927cbca]
3. One main process orchestration that receives a message of type XmlDocument and uses dynamic transforms. The orchestration will identify the message type and apply the appropriate transform before it reaches the main process logic
[url]http://www.biztalkgurus.com/Samples/Dynamic-Transforms-BizTalk-2006.html[/url][list:0e4927cbca]I have not used this technique so cannot really comment, although the author is Stephen Thomas so it is definitely worth a look. Its on my todo list.
[/list:u:0e4927cbca]My current preference is option 2. I have found using XSLT to validate incoming messages far superior to the standard XML Schema validation.
You can return a list of errors rather than just the first one, you can use conditional validation based on data content. Option 3 would be open to this approach as well.-
You will theoretically require one receive location for all Xml documents. The Xml Disassembler is able to derive the message type from the document.
Then one receive location for each different flat file or custom format. The Flat File disassembler requires the message type be predefined as flat files have no standard mechanism for defining message type like Xml with its root node and target namespace.One possibility is a custom disassembler that can determine the message type and call the standard Flat File disassembler
If you would create this then you could have one receive location with two disassemblers in the pipeline. The Disassembler stage in a pipeline is different from the other stages it uses FirstMatch execution mode. It calls IProbeMessage.Probe for each component until a component returns true.The other factor determining how many receive locations you have is the adapter used. How are all the suppliers sending messages? What transport protocol are they using?
I would still go for multiple receive locations, less code to write and maintain, you also get all the tracking and debugging facilities of Biztalk. It will also be easier to bring on new suppliers, just add another receive location, schema and map. With a manual disassembler every new supplier will be a new version with complete regression testing
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.