| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Attaching XML to Output Message in Java Compute Node |
« View previous topic :: View next topic » |
| Author |
Message
|
| wyatt |
 Posted: Tue Dec 26, 2006 3:45 pm Post subject: Attaching XML to Output Message in Java Compute Node |
 |
|
Voyager
Joined: 28 Nov 2004
Posts: 76
|
Is it possible to take an XML document and attach all its elements and attributes to output message from a java compute node using a single method call? In the case, the XML document is created by de-serializing a java object (using xstream). Using MbElement.createElementAsLastChild(..) methods to attach all the XML elements/attributes does not seem practical.
As a work around, The XML document is attached as a BLOB (as follows)
MbElement outRoot = outMessage.getRootElement();
MbElement outBody = outRoot.createElementAsLastChild(MbBLOB.PARSER_NAME);
MbElement outElem = outBody.createElementAsLastChild(MbBLOB.PARSER_NAME);
outElem.setName("BLOB");
outElem.setValue(xmlMessage); Where xmlMessage contains the XML document.
Then, using the Message Broker node resetcontentDescriptor the message is set to XML domain, the output from this node is sent to a compute node for further processing.
But this is resulting in parsing the data twice, once in the java compute node when de-serializing the java object and then again after exiting the java compute node using a resetContentDescriptor node.
Is there a better way to handle this problem? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Dec 26, 2006 4:45 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
First off, Reset Content Descriptor does not perform any parsing. All it does is change the message properties so that the normal broker Just in Time parsing can occur.
Secondly, of course you intend to use the XMLNSC parser and not the XML parser - because everyone knows that XML domain is deprecated in v5, and thus wouldn't dream of using it in v6, which is the only version that supports a Java Compute Node.
Thirdly, most people define "practical" as "something that works", and so if you have a working solution, I'd be hard pressed to say that it wasn't "practical".
Fourthly, you should consider whether your Java Compute node is really enhancing a message, or replacing it. If it's replacing it, and you aren't using anything from the Input message to figure out what to replace it with.... then you should probably not be using a Java Compute node, and instead be creating a custom node that is an Input node.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wyatt |
| Posted: Wed Dec 27, 2006 6:37 am Post subject: |
|
|
Voyager
Joined: 28 Nov 2004
Posts: 76
|
I appreciate your comments!
There is one "kludge" I did not mention earlier.
The Java compute node creates the "new" output message as follows:
MbElement outBody = outRoot.createElementAsLastChildFromBitstream(
baos.toByteArray(), MbBLOB.PARSER_NAME, null, null, null,
0, 1208, 0); where baos is a java ByteArrayOutputStream.
The resulting output messaage "InputRoot.BLOB.BLOB" has a data-type of BLOB.
For the message to successfully pass thru the resetContentDescriptor node, it is necessary to preceedd this node with the following statement in a compute Node:
Set OutputRoot.BLOB.BLOB=CAST(InputRoot.BLOB.BLOB AS BLOB CCSID 1208); Why would this step be necessary when the data-type is already a BLOB.
If this step is not done, the resetContentDescriptor returns message "XML parsing errors have occured"
With Respect to using a custom input node. ..Since this data is arriving via MQSeries why would you consider this as a possible solution. Would the "advantages" of a "custom input node" exceed the the cost of developing/supporting such a solution? |
|
| 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
|
|
|
|
