- This topic has 5 replies, 1 voice, and was last updated 7 years, 8 months ago by
.
-
Posts
-
-
-
You could use an encoding pipeline component on your send pipeline. BizTalk doesn’t come with one out of the box, but there are a few samples and third party components that support this functionality if you google around a bit.
-
Thanks for the reply tomasr, But actually I have a scenario Like this, I need to compress messasge or fragment it(I dont know at this point of time how to do it) if it is more than 4 MB using .net application and will have to send to MSMQ, then at the other side biztalk has to receive that comressed message or fragmented message and combine it, How can do it ??any Idea over it , How does biztalk batch that fragmented or compressed message?
-
If you have used biztalk for sending messages to MSMQ you can send large messages greater than 4MB by using msmqtlarge.dll which comes with BizTalk refer http://msdn.microsoft.com/en-us/library/aa559135.aspx But as you are sending it thruogh .net application to MSMQ And receving from MSMQ using BizTalk I am not sure How you can fragment or compress message and send to MSMQ and how your BizTalk can receve those messages, Its interesting scenario hmm, Lets have a comments from some experts in this forum.
-
[:^)] It was my understanding that the msmqtlarge.dll on non-biztalk machines to submit messages to the q; and that this functionality was baked into the MSMQ adapter so it comes out-the-box with biztalk.
-
I don’t know about msmqtlarge.dll. I usually try to steer away from using MSMQ because of the 4MB size limit and also because BizTalk’s large message queueing functionality seems cumbersome. I would probably look at compression or chunking before I went the MSMQT route. Compression would be simpler than chunking, but it would not eliminate the size limit, only increase it. You could use the System.IO.Compression.GZipStream class to compress the message on the client side, and then write a custom receive pipeline on the BizTalk side that uses GZipStream to decompress it. Chunking would be more complicated but it would allow you to handle much bigger messages. You would need to write a debatching orchestration to reconstruct the message from the chunks. The tricky part would be identifying the chunks that make up a message. You have to find a way to correlate the chunks. The client app will probably need to set some kind of batch ID. Tricky!
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.