| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Getting name of root element |
« View previous topic :: View next topic » |
| Author |
Message
|
| chrisc |
 Posted: Tue Oct 31, 2006 6:54 pm Post subject: Getting name of root element |
 |
|
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 |
|
 |
| jefflowrey |
| Posted: Tue Oct 31, 2006 7:05 pm Post subject: |
|
|
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 |
|
|
| chrisc |
| Posted: Tue Oct 31, 2006 9:01 pm Post subject: |
|
|
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 |
|
|
| jefflowrey |
| Posted: Wed Nov 01, 2006 2:44 am Post subject: |
|
|
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 |
|
|
| kimbert |
| Posted: Wed Nov 01, 2006 3:52 am Post subject: |
|
|
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 |
|
|
| jefflowrey |
| Posted: Wed Nov 01, 2006 4:16 am Post subject: |
|
|
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 |
|
|
| chrisc |
| Posted: Thu Nov 02, 2006 2:25 pm Post subject: |
|
|
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 < 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 |
|
|
| jefflowrey |
| Posted: Thu Nov 02, 2006 2:27 pm Post subject: |
|
|
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 |
|
|
| fjb_saper |
| Posted: Thu Nov 02, 2006 4:24 pm Post subject: |
|
|
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 |
|
|
| chrisc |
| Posted: Thu Nov 02, 2006 5:52 pm Post subject: |
|
|
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: |
| <?xml version="1.0" encoding="UTF-8"?><root><tag>abc</tag></root> |
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
