| Author |
Message
|
| EvolutionQuest |
 Posted: Tue Oct 14, 2003 8:06 am Post subject: working with blobs in a message flow |
 |
|
Voyager
Joined: 18 Sep 2001
Posts: 88
Location: Billings, MT
|
| One of my colleagues is receiving a message from a VB app which is sending meta data (string) and a blob to him in one message. The blob is roughly 1280 bytes, but when he sends it to a trace node to view things it comes out as 2 megabytes. The MQMD.Format = MQNONE. Is there issues with mixing strings and message for a message flow? The other suggestion I had was to let the XML parser handle the separation of the meta data and blob. Opinions? |
|
| Back to top |
|
 |
| JLRowe |
| Posted: Tue Oct 14, 2003 9:15 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Put the BLOB in a CDATA within the XML.
It's also bad practice to use MQMD.Format = MQNONE, this prevents translation between different codepages, use MQSTR instead. |
|
| Back to top |
|
|
| EvolutionQuest |
| Posted: Tue Oct 14, 2003 10:27 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2001
Posts: 88
Location: Billings, MT
|
I am going to be naive and completely stupid for asking this as my brain is a little fried right now.
I don't think we want the binary data to run through a conversion because wouldn't it muck up the raw binary data, i.e. database file. So if I take a .DBF (FoxPro) file from NT and send it to the broker as part of the payload shouldn't it be untouched by the conversion? I would think so, but then again I haven't messed with Blobs in integrator until now.
Also, the message is in a tag delimited format so TDS is being used within a message set. The problem is the element for the blob seems to be getting mucked up when coming into the message flow.
We want the header or meta data in the message to be converted to the proper code page, but do not want the blob affected. That is why the Format = MQFMT_NONE.
Any suggestions. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 14, 2003 10:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| cfryett wrote: |
| I don't think we want the binary data to run through a conversion because wouldn't it muck up the raw binary data, i.e. database file. |
Base64 encode the binary data first. Then put it into a CDATA section.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EvolutionQuest |
| Posted: Tue Oct 14, 2003 10:56 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2001
Posts: 88
Location: Billings, MT
|
I understand the encoding portion, but i don't recall integrator being able to decode the data. Also, if I understand you the application putting the message will do the encoding of the blob, integrator will pass that through, and then the application on the receiving end will need to decode it.
So, while I ask this stupid question I get the sense that the blob will have to be encoded by the sending application, the message flow can pass it through, and then the receiving app will have to decode it.
Sorry to repeat, just thinking while I type  |
|
| Back to top |
|
|
| EvolutionQuest |
| Posted: Tue Oct 14, 2003 11:08 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2001
Posts: 88
Location: Billings, MT
|
| I think based on the customer's requirements we have figured out how to resolve this issue. The message flow which has to deal with the BLOB will no longer be required based on its only purpose of being a passthru. It doesn't justify its existence, when the VB app can just write the information to a queue and the receiving app can deal with it. Sorry for the wasted messages. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 14, 2003 11:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Another option is to put all of the metadata into a user area of an MQRFH2 header, and put only the binary data into the payload.
Then MQSeries and Integrator will do any necessary conversion on the contents of the header but ignore the binary data.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
