| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| base64 encoding a XMLNS element.... |
« View previous topic :: View next topic » |
| Author |
Message
|
| dcapodic |
 Posted: Fri Dec 07, 2007 5:59 am Post subject: base64 encoding a XMLNS element.... |
 |
|
Apprentice
Joined: 03 Sep 2003
Posts: 32
|
Hi....
I am working in WMB 6.0.0.3. I have a flow that is picking up a file via the File Extender and passing it along during a lengthy flow. Along the way, I do not touch the file at all, meaning I am just passing it along. After I initially pick it up, I assign it to an MRM value of base64binary and pass it along as that. I have checked it all along its path and it keeps that base64 value. However, in the last step of the flow I need to post this file and a lot of other related data to a web service, using a soap envelop. I have done this many times with just typical datra but the first time I am trying it with a base64 encoded filed. I am using a compute node to format the final message and using the XMLNS (also tried the XMLNSC) domain. the problem is when I attempt to write out the file element, the result gets changed to what appears to be a blob value. I am losing the base64 encoding. I am assuming (maybe wrongly so) that this is a function of the parser. Is there a way that I can get that element posted as a base64 value using the XMLNS (or XMLNSC) domain? I have experimented with using the MRM domain and the element does get created as base64 as expected but because of so many other things I need to do to manipulate the data, using the MRM seems impossible (or very difficult) to do. so, is there a way of overriding what the XMLNS parser seems to want to do to change that element value?
Here is the esql for the actual element:
SET OutputRoot.XMLNS."SOAP-ENV:Envelope".(XML.Element)"SOAP-ENV:Body".(XML.Element)"m:SR_Att_Insert_Input".(XML.Element)"m0:ListOfServicerequestws".ServiceRequest.(XML.Element)"m0:ListOfServiceRequestAttachment".(XML.Element)"m0:ServiceRequestAttachment".(XML.Element)"ActivityFileBuffer" = InputRoot.MRM.SRCreateData.FileContentOut;
Thanks....
Dan |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Dec 07, 2007 6:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why do you think it's a BLOB value and not a base64 encoded value?
It's also not clear, to me, if what you've done will cause the logical element in the MRM tree to be serialized into it's proper output form.
it's also not quite clear why you're switching from MRM-XML to XMLNS... What can you do in XMLNS that you can't do in your model?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dcapodic |
| Posted: Fri Dec 07, 2007 7:43 am Post subject: |
|
|
Apprentice
Joined: 03 Sep 2003
Posts: 32
|
| jefflowrey wrote: |
Why do you think it's a BLOB value and not a base64 encoded value?
It's also not clear, to me, if what you've done will cause the logical element in the MRM tree to be serialized into it's proper output form.
it's also not quite clear why you're switching from MRM-XML to XMLNS... What can you do in XMLNS that you can't do in your model? |
For sure, the value is not base64. Two ways I can tell  First, the service that picks the file up, once it writes it out it cannot be read and the error says (data not base64 ....secondly, it is visually obvious when you look at it and I went back and changed the initial MRM value from base64 to blob and wrote it out at that point and it was exactly the same. So, I know that it is being changed back to blob.
As to why I am not using the MRM....it is probably more an issue of not understanding the toolkit enough to get done in the MRM what I would like to do. Simply put....I cannot make the output of the MRM look like what I need but it is extremely easy to do in code which is why I did it initially in the XMLNS domain.
Do you kow....is it an expected behavior that if I passed in a base64 encoded element and looked to reassign it to an XMLNS domain element such as the code I presented above, should the parser be changing that encoding? Or, am I seeing something a bit "weird"...?
Thanks....
Dan |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 07, 2007 8:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's my belief, and hopefully kimbert will correct me if I'm wrong, that base64 encoded elements are decoded by the MRM when it parses the physical message into a logical tree. When the message is serialized into an output bitstream, then the MRM parser will re-encoded the data.
So the element in the logical tree is decoded. Which is likely why you're seeing what you see.
If you want to pass the data along "as is", then probably you should mark the logical element as an xsd:string field, not a base64 field. Then the MRM should not do any encoding or decoding. It might, however, play around with any whitespace that's in the field - per normal XML rules.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Dec 07, 2007 1:27 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Jeff is 100% correct. The MRM parser decodes base64 fields, and re-encodes them when it serializes the message tree. That is why the field is not base64-encoded when output by the XMLNS domain.
If dcapodic needs good control of the output XML, then MRM XML will make that difficult. So XMLNS is the correct domain to use ( and XMLNSC would be even better...read on for the reason why ).
| Quote: |
| After I initially pick it up, I assign it to an MRM value of base64binary and pass it along as that |
I presume that means that dcapodic has set up a message set with an XML physical format for the express purpose of serializing this BLOB as base64
( because simply assigning the BLOB value to Root.MRM.myBase64Field will not trigger any encoding, as explained above ).
You can do base64 encoding when using the XMLNS domain. The simplest way is to call out to a Java method which encodes the BLOB and returns a base64 string.
In v6.1 the XMLNSC domain can decode and encode base64 fields. So using XMLNSC would allow the code to be simplified in future.
My recommendations are:
- Switch to using XMLNSC or XMLNS throughout the message flow. Use Java for base64 encoding and decoding. This will reduce CPU usage, and make the flow more maintainable.
- Alternatively. continue using the MRM domain, and model the BLOB field as a string so that it remains in base64 format in the message tree. The is the minimum-effort solution |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 07, 2007 1:52 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kimbert wrote: |
| In v6.1 the XMLNSC domain can decode and encode base64 fields |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dcapodic |
| Posted: Sat Dec 08, 2007 2:23 pm Post subject: |
|
|
Apprentice
Joined: 03 Sep 2003
Posts: 32
|
Thanks guys, it is always an education when I get to hear from you the "internals" of how things work
I actually got this to work in a relatively easy manner (though probably not that elegant) by sticking a reset content descriptor node in and restting the domain of the message to XMLNS before posting it to the web service. This gets the desired results. The message output has the file as base64.
You are correct in your assumption of why I initially used the MRM....I was looking to endcode the input then simply pass it along. I tried to then move it along as a string but still, as I go to output the message it is back to its BLOB form. For now, this solution will suffice.
I very much look forward to 6.1 and playing with many of the new features and now I have another to look forward to |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
