ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Getting name of root element

Post new topic  Reply to topic
 Getting name of root element « View previous topic :: View next topic » 
Author Message
chrisc
PostPosted: Tue Oct 31, 2006 6:54 pm    Post subject: Getting name of root element Reply with quote

Voyager

Joined: 19 Mar 2006
Posts: 77

Hi everyone,

I was wondering, is it possible to get the original element name of the root of an input message?

For example, if I have:
Code:

<MyMessage>
   <Field1>abc</Field1>
   <Field2>def</Field2>
</MyMessage>

then when I do FIELDNAME(InputRoot.MRM.*[1]) I get "Field1", but when I do FIELDNAME(InputRoot.MRM) I get "MRM".

How can I find out that the root element is called "MyMessage"?

(If you are wondering, I am writing a unit testing flow that accepts any type of message, so I can't just "know" in advance what the message should look like.)


Many thanks,
Chris
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Oct 31, 2006 7:05 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

MRM will identify an XML message as being described by a particular message dictionary based on the root tag.

So you can look at InputRoot.Properties....
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
chrisc
PostPosted: Tue Oct 31, 2006 9:01 pm    Post subject: Reply with quote

Voyager

Joined: 19 Mar 2006
Posts: 77

Hmm, I hadn't thought of that... Is the name of the dictionary always the same as the name of the root element?

As some background, I want to output a message using a fixed structure, but then I want to copy the input message exactly as it was into the RFH2. Unfortunately I've just realised that with my current approach I'm going to lose all the namespace info etc anyway:
Code:
SET OutputRoot.MQRFH2.usr.{InputRoot.Properties.MessageType)} = InputBody;


(The above will get a "sort of" version of the input message, but everything will be CHAR, there will be no namespaces, and the root element will be whatever the dictionary name is, as per your response...)

Is there any way of getting the broker to bitstream the contents of the MQRFH2.usr folder, so that it actually outputs everything with namespaces etc intact? i.e. if I create a folder, assigned to the MRM domain, and get it to parse my bitstreamed input message, will the broker actually treat it differently?

Cheers,
Chris
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Nov 01, 2006 2:44 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

RFH2 header is only "sort of" XML - it doesn't support the notion of namespaces. Heck, it was designed before XML *had* namespaces.

You can use ASBITSTREAM to unmarshall your XML into a string (including namespaces) and put that into the RFH2.

The name of the dictionary is not the same as the name of the Root Element - it's the name of the Message Definition file, I think. But the Root.Properties.Message should be the name of the message element in the Message Definition File. But that doesn't *have* to be the name of the root element. It's just whatever you call it.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
kimbert
PostPosted: Wed Nov 01, 2006 3:52 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

So you want to
1. Find out the root tag of the input message ( so that your flow can take appropriate action based on the type of message )
2. Copy the input bitstream into the output RFH2.usr

For 1, I think you have 2 options
a) Force all clients to populate InputRoot.Propeties.MessageType with the root tag name. I realise that this might not be possible in your organisation.
b) First parse the message using the XMLNSC parser. Implement your control logic while in the XMLNSC domain. Switch to the MRM domain once you get to the real work. Note that this is a lot more efficient that it sounds. Accessing the root node will only require a very small amount of parsing because message broker parses lazily ( on demand ).

For 2., why not simply store the input message as a BLOB in the environment, and pop it into the output message on the way out?

So I'm suggesting that your flow would use 3 domains in sequence:
BLOB -> XMLNSC -> MRM

Jeff : Do you think this will work?
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Nov 01, 2006 4:16 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

MessageType?

It's not my week for details.



Otherwise, yeah, that looks like it would work. It's a good progession, too. Saves having to use ASBITSTREAM to "unparse" what's already been parsed.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
chrisc
PostPosted: Thu Nov 02, 2006 2:25 pm    Post subject: Reply with quote

Voyager

Joined: 19 Mar 2006
Posts: 77

Thanks very much for the suggestions.

I wrote a big response to your comments, with lots more questions, and then just before I hit "submit" something clicked...

Jefflowrey, I am using ASBISTREAM already to validate the input message, but I disregarded the idea of using this BLOB because when I did put it in the RFH2 header it was just an encoded hex stream. But then I realised that I wasn't casting it to CHAR. First attempt after casting didn't work either, because I forgot the CCSID and ENCODING attributes, but not I'm getting my original message put in the RFH just like I was after!

(Well, it's encoded the XML as XML, which means my tags are all &lt; instead of < etc, but that's easy to handle.)

So Kimbert, your idea for 2) was spot on, I was just stuffing up the implementation. 1) is no longer an issue anyway, since I only wanted the root element name if I was going to copy over the elements the hard way, but this was going to lose me the namespaces as I said.

I ended up not going down the path of changing between parsers, because a) I was using ASBITSTREAM anyway, and b) all incoming messages have the MCD info set, which overwrites whatever I might put in the input node. I didn't feel like mucking around with reset content descriptor nodes etc...


Thanks to you both for your help. Do you actually get time to do your own stuff, given how much time you must spend helping the rest of us?


Cheers,
Chris
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Thu Nov 02, 2006 2:27 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

chrisc wrote:
Do you actually get time to do your own stuff, given how much time you must spend helping the rest of us?


I'm surprisingly productive.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Nov 02, 2006 4:24 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Remember I would not dare put a full xml tree into the RFH header. The restrictions of the RFH header mean that the xml structure is pretty flat....
You are just allowed to use property value pairs or has this restriction been lifted and I am just not aware of it?

What you can do however is set the tree as BLOB and use
property = original message, value = blob; And this cannot be a String that is humanly readable (see xml restrictions)...

What you can have is the bytes representation of a String as byte values in hex....But of course that means decoding and parsing at the receiving end.

Rethink what you are trying to do and what the requirements are...

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
chrisc
PostPosted: Thu Nov 02, 2006 5:52 pm    Post subject: Reply with quote

Voyager

Joined: 19 Mar 2006
Posts: 77

Yes, I discovered the issue of putting full XML trees in there when I tried putting a full XML message including XML declaration into the usr folder with RFHUtil. (Interestingly, it doesn't actually mind if I take out the XML declaration at the beginning - I guess without that, even a full XML message could be interpreted as just a snippet...)

Just out of interest, is this restriction a documented restriction or is it just common knowledge? I haven't heard of it before...

Anyway, the XML I am putting in the RFH is human readable only as far as not being a hex string, but it is encoded with XML entities, so:
Code:
<?xml version="1.0" encoding="UTF-8"?><root><tag>abc</tag></root>

becomes:
Code:
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;&lt;root&gt;&lt;tag&gt;abc&lt;/tag&gt;&lt;/root&gt;


Yes, it involves parsing on the other end, but that is not really a big issue. Converting XML entities into their normal representation is a lot easier than trying to parse encoded hex strings!

Although... thinking about your comment about rethinking what I'm trying to do... if I'm going to have an XML-safe string stored in the RFH then I might as well just store it in my message! I don't have to worry about unknown XML structures any more. Cheers!

Chris
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Getting name of root element
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.