Forum Replies Created
-
Posts
-
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.
There is a limit of 256 chars on the Promoted Properties.
If you make it a Distinguished field you shouldn’t have a problem.
I'd guess you are probably not using it for Routing anyway.
As Greg mentioned, this is by no means an ideal or best solution for a BizTalk point of view.
It is important to understand that you gain and give up by not loading the message though a Receive Location. You give up persistence. What you gain is, well, a little more flexibility as to the pick up location. If you had 1,000’s of pickup locations that may not be known at any given time this makes sense. If files are always going to be at \\somelocation\here\ then this might not be the right approach.
This reminds me of something I did years ago with 04 Beta. Needing the file loaded inside the Orchestration from some random location then sent via a preexisting .net component to a remote system.
What I was getting at with this: “You can do both inside the Orchestration, but that’s just not really the best place for them” Was in general, if you can do things differently you should. A more standard approach is to call Send and Receive pipeline inside the ports and not the Orchestration.
I think it all rides on if you have a finite number of receive locations for your files. If you do, then something like Greg is talking about is the right way to go.
Got you, that makes total sense.
Not sure what the right approach would be for that. But the reg key sounds viable. Just as long as R2 doesn’t change it.
If you are sending the exact same message out thru the send port then you may be able to use a flat file assembler in the send pipeline. Do not specify the schema on the Flat File assembler and it will check the BTS.MessageType in the message context and use that schema to convert to a flat file. Even though you have declared the message as type XmlDocument in you orchestration it will still have the message context properties created in the receive pipeline.
If you copy the message in the orchestration you will lose the context properties, so you will also need to explicitly copy these as well
e.g.
outputMessage = inputMessage
outputMessage(*) = inputMessage(*)I need this information to use for license checking for a BizTalk component. We feel it is important to mirror MS's licensing approach as much as possible. If a customer only needs BizTalk Standard Edition, then we want to be able to provide them with a Standard Edition of our component. If, on the other hand, the customer has a sufficient number of business partners and BizTalk Applications that they need BizTalk Enterprise Edition, we feel that we are fair in providing an Enterprise Edition.
What we need is a way to validate licensing that will support the above concept.
Thanks,Robby
Anon-
Try IBM DatastageTX, formerly TSI Mercator. It compiles the parser and map into a single executable, which would fit the architecture you desire.
– weak architect
Sorry greg; it took me a lot of time to complete my reply to Stephen's post so I couldn't check that your response had arrived. I guess I have already answered your question (Can you explain a bit more about the overall purpose of your solution. What are you trying to do?)
As I specified in my reply, the main purpose of this type of design is to have less setup overhead. If I need to develop custom mapping, that would require development for each new file type / format. I need to deliver a solution where only a handful of mapping guys could deploy schemas & maps (& pipelines) to BizTalk Server 2006 machine, add some new map definitions in my system and the system just does its job (i.e. executes the maps for the files they are configured for).
I have also considered multiple Receive Location setup. But with the number of maps this solution needs to support (2000+ maps), it seems an overkill (I may be wrong here). Setting up receive location with each new map defined in my system is also an overhead (though a one-time effort to write some code to setup necessary ports, locations & pipelines)
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
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 so2. 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?
Also check that you have saved changes to the Xslt file before doing the build.
VS2005 normally saves any unsaved changes when doing a build but forgets about the Xslt file.
One possibility is to have a looser flat file schema, that will parse data that is invalid, lots of optional records and fields and then have a subsequent check. Map into a stricter schema possibly or use a Schematron type validation in an orchestration using a map.
Can you go back to the source and correct the reason for the problem there. Ensuring only good data is sent.
If the source is external, then I find automatically rejecting errors back to the source can focus the sender into correcting their mistakesYou should be able to write a simple Windows Service to do this. Might even be something on DotGotNet that already does something close to this.
If you download the sample code with my BizTalk 2004 Convoy Deep Dive white paper, I have a listener for Zombies. You could always modify that for the other WMI event.
Hope this helps.
Yes, it sounds like you’d need to call a pipeline inside the Orchestration for you read in messages if they are not XML.
Here are my answers:
- Well, it’d not really say it’s just the mapping engine but really BizTalk as a whole. Seems like a good fit.
- You should be able to construct an Xml Document inside an Orchestration and have it be anything. Never done anything with XLangMessage, but it should allow you to do that as well.
- Sure. – but see below.
- See below.
Let me get this right, you get a message in a location and then you go get a file at the location that message tells you? Any way to just have the final document end up in your file location? What you want to try to get to, is your Receive Locations to process your pipelines and convert into Xml. Some on the Send side. You can do both inside the Orchestration, but that’s just not really the best place for them.
If you can’t really change much, then I like your approach. It makes sense to me and it should work for you.
Are you just reading them using File IO? If so, I’d make sure I was doing this inside a .net component I call rather than an expression shape. Then you should be able to make that method return an XLang Message.
Hope this helps.
