| Author |
Message
|
| jdouch |
 Posted: Fri May 31, 2002 8:41 am Post subject: Attribute XML & LocalEnvironment |
 |
|
Apprentice
Joined: 31 May 2002
Posts: 32
Location: London, UK
|
Has anyone successfully managed to save off attribute XML to the LocalEnvironment area, and then bring it back having done some other processing (I am having to go a get a message from a cache queue using MQGet node).
I save off the attribute XML, trace node shows that its stored there ok, but when i bring the whole message back (whole Root not field by field) , specifying XML as the parser/domain it defaults to tagged XML ?? .... and with only the main elements from the attribute XML, i.e most of attributes and their values are missing. 
I've tried various work arounds using ATTACH and CREATE but without success. I've found that you can map field by field using (XML.attr), but to copy a message body for example where you have to specify the OutputRoot.XML. the XML will always default to tagged XML.
So far i have found no way to specify the whole XML tree as attribute XML. Does anyone have any ideas ??
many thanks
_________________
Julian Douch
E-business Solutions Consultant
WMQ/WMQI Specialist |
|
| Back to top |
|
 |
| amigupta1978 |
| Posted: Sun Jun 02, 2002 10:00 pm Post subject: Attribute XML & LocalEnvironment |
|
|
Centurion
Joined: 22 Jan 2002
Posts: 132
Location: India
|
HI,
I dont think its possible to get the attribute list in the LocalEnvironment tree. I too faced the similar problem.
But we got one workarund by saving the completet message as the BITSTREAM and then remaking thr message out from the Bitstream.
Rgds,
Amit |
|
| Back to top |
|
|
| kwelch |
| Posted: Thu Jun 06, 2002 6:10 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
What version of WMQI are you using? I have been told that you can save attributes into LocalEnvironment.Variables and retrieve them back. Does anyone else have any experience with this issue?
Karen |
|
| Back to top |
|
|
| jdouch |
| Posted: Thu Jun 06, 2002 12:17 pm Post subject: |
|
|
Apprentice
Joined: 31 May 2002
Posts: 32
Location: London, UK
|
We're using 2.1 here. I've managed to save and retrieve using a field by field method specifying the (XML.attr) for each field, however the scenario i was faced with where i did not have knowledge of all the mesage fields meant that i needed to save off the whole message and bring it back.
I have also been told in the last few days that this should be possible too, by using the CREATE function and specifying the DOMAIN as XML. Apparently the key is to specify the domain. I shall try it over the next few days and let you know how i get on.
Julian
_________________
Julian Douch
E-business Solutions Consultant
WMQ/WMQI Specialist |
|
| Back to top |
|
|
| kwelch |
| Posted: Thu Jun 06, 2002 12:22 pm Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
I would be interested in how you accomplish this as I am faced with a similar situation. I just posted under another topic. I have to set multiple attributes on a repeating aggregate and wanted to do a group move of the whole thing and so far have been unsuccessful in getting both the id and the ref to come out with the right occurrences. I too will post it if I get it to work.
Karen |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Wed Jun 19, 2002 11:39 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
The XML parser does some things automatically when it is assigned values: an implicit cast to CHAR, and rendering as XMLElements. So to preserve original rendering, you must also preserve the original bitstream.
Try to store the InputBody as BLOB into LocalEnvironment, using
SET LocalEnvironment.Variables.Temp=BITSTREAM(InputBody);
Then retrieve it from temporary storage with CREATE....PARSE.
I haven't tried this one, but similar cases worked ok. |
|
| Back to top |
|
|
| kwelch |
| Posted: Mon Jun 24, 2002 6:38 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Hi,
I have been away from this topic for awhile and am now back to addressing this issue. I don't understand the part where I have to save the message as a BLOB.
I am creating the attribute id's and references in the OutputLocalEnvironment in various compute nodes throughout my messageflow. My very last compute node is taking all the XML I have created in the OutputLocalEnvironment and putting it into the ACORD XML order we need. I do this by moving chunks of the data at a time. At this point I am losing the attributes I set. If I save the OutputLocalEnvironment as a BLOB then I don't understand how I would format my output message. Am I missing the whole concept here? Could you maybe give a small example of this? Thanks in advance.
Karen |
|
| Back to top |
|
|
| kwelch |
| Posted: Fri Jun 28, 2002 11:03 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Julian,
We experienced the same thing that you described. We could store them in OutputLocalEnvironment.Variables but then could only retrieve them individually. If we tried to move the data in chunks most of the attributes came out as regular tags.
What we ended up doing was storing all the individual elements to the OutputLocalEnvironment.Variables but no attributes. Then in our last compute node after we moved all the elements in chunks, we assigned all the attributes. We didn't realize that attributes don't have to be coded in order like the elements. So far this is accomplishing what we need. I don't know if it will work in your case but thought I would post it. 
Karen |
|
| Back to top |
|
|
| CodeCraft |
| Posted: Fri Jun 28, 2002 11:27 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
What you have here is a valid problem. Miriam gives the same solution as I would have: If the integrity of the data is not preserved by doing a tree copy from Root.XML to LocalEnvironment, just store the BLOB equivalent instead (the message bitstream).
However, I think you should address to WMQI Support that "features" are lost if you move XML to LocalEnvironment. The objects that are used to represent the trees are probably different, but since LocalEnvironment *should* support anything thats in any of the logical message trees, this might need to be looked at my WMQI development and fixed. |
|
| Back to top |
|
|
| kwelch |
| Posted: Fri Jun 28, 2002 12:20 pm Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
CodeCraft,
I did not understand Miriam's resolution of storing it as a BLOB. We are building the attributes along the way in various compute nodes. At what point do I store it as a BLOB? Then I don't know what I have or don't have.
A little background on this. I am dealing with a legacy cobol variable input message. It is comprised of some unknown combination of COBOL copylibs. The mainframe app is providing us via a header which ones are present and how many of each there are. During the proof of concept for this project we had over 10,000 lines of code in one compute node which was very unmanageable. We decided to split the code by copybook. So in our very first compute node we build a router list that is based on the presence of each copybook. Then our next problem was that our output is required to be in ACORD XML order. Needless to say our copybooks aren't in that order. So each compute node stores it's data in OutputLocalEnvironment.Variables. At the very end we have a reorder Compute node which puts everything in ACORD XML order except the attributes, which we do at the very end of the reorder compute node.
We just didn't realize that the attributes for elements could be done out of order and not with the elements themselves, as order is so important with creating XML.
Also, my WMQI techie did report it as a problem to IBM.
Karen |
|
| Back to top |
|
|
| CodeCraft |
| Posted: Fri Jun 28, 2002 2:41 pm Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
I'm not clear from the textual description exactly what is wrong. My original impression is that attributes were being taken out of context when put in LocalEnvironment, eg:
<A B="C">Y</A>
becomes:
<A>Y<B>C</B></A>
Is this the case. However, you also mention "order" issues.
Now, if building the various trees in the XML domain achieves the desired result, but in the LocalEnvironment does not, then you can build the XML tree, RCD to BLOB, and then store the BLOB in the LocalEnvironment. This ensures that when you later retrieve the BLOB and RCD back to the XML domain, nothing has become lost in the translation.
Exactly what you need to do depends on the app. itself. Alternatively, you could add a dummy indicator to elements which are supposed to be attributes, so that when you are assembling the final message, you can fix up.
If using 2.1 you should also look at some of the newer create/parse functionality as there are additional flexibilities you may not have previously encountered.
Without more specific knowledge of the app. I can't really give more specific assistance. Is this something you could use consultancy on? |
|
| Back to top |
|
|
| kwelch |
| Posted: Mon Jul 01, 2002 4:31 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Your example of how the attributes get lost is true. The order issue is our own problem. Our project is driven by the 1)output needing to be in ACORD XML format 2) the input being in a completely different order and variable with an unknown combination of various COBOL copylibs making up the message and 3)the need to break up the code into smaller maintainable chuncks. We do this and store it in the OutputLocalEnvironment. The OutputLocalEnvironment is not built exactly in the order needed so in our last compute node we do moves of large chunks from the OutputLocalEnvironment to the Output. This is where we lost the attributes. I don't know if this makes it any clearer for you or not!!!
I still don't get how saving the message as BLOB will help me in this instance. I am apparently missing the concept. Anyway, we got around this by just coding the attributes after we do all the moves in the last compute nodes.
Karen |
|
| Back to top |
|
|
| CodeCraft |
| Posted: Mon Jul 01, 2002 4:41 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
To save messing with the attrbiutes, can you just send the various XML segments through the flow in the XML tree, eg:
Root.XML.Temp.MessageSeg1
Root.XML.Temp.MessageSeg1
Etc, and then at the end rebuild the new XML output tree by reordering the various bits of the XML input tree.
Even if you need to do processing on the contents of the XML tree during flow processing, it shouldn't hurt to have the extra things in tree once your code ignores them. |
|
| Back to top |
|
|
| CodeCraft |
| Posted: Mon Jul 01, 2002 4:51 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
| Of course, what's done is done if you have already resolved the issue another way! |
|
| Back to top |
|
|
| kwelch |
| Posted: Mon Jul 01, 2002 4:57 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
I guess I didn't make it clearer!!! Yes, that is kind of what we are doing. We build the OutputLocalEnvironment based on whatever copylibs we receive on the input message. The last compute node puts them in order and assigns the attributes. Our flow looks something like this:
MQInput --> Compute Node to Build RouterList --> RouteToLast
Label for Copy1 --> Compute Node to Build Copy 1 fields in OutputLocalEnvironment --> Route To Last
repeat one for each copylib
Label for Reorder --> Compute Node to Reorder and assign attributes -->MQOutput Node
Originally we were assigning attributes in each of the copybook compute nodes, now we just do it in the last compute node. Thanks for your input and suggestions.
Karen |
|
| Back to top |
|
|
|
|
