| Author |
Message
|
| pjaffe |
 Posted: Thu Jul 07, 2005 11:44 am Post subject: MRM parser problem using ATTACH and DETACH |
 |
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
WBIMB v5 CSD4 - windows platform
I have a message definition that has both CWF and XML properties. We have a requirement that the CWF field names be different from the XML tag names so we have used the XML properties for field name. This method works well for us as long as we just read the message and set the Outputroot.Properties.Format='XML' and OutputRoot=InputRoot.
My problem is that I have one message flow were I need to move a branch of the tree to a different part of the XML tree. This works using the ATTACH and DETACH statements. The only problem is that for the branch that got moved, the XML tag names on the output are ignored and the CWF field names are used.
The message definition is:
01 TEST-REQUEST.
10 FIELD1 PIC X(1).
10 FIELD2 PIC X(1).
10 LEVEL1.
15 FIELD3 PIC X(1).
15 FIELD4 PIC X(1).
10 LEVEL2.
15 LEVEL3.
20 FIELD5 PIC X(1).
The output without moving the <L3> branch is:
<msg_TESTREQUEST>
<X1>Q</X1>
<X2>W</X2>
<L1>
<X3>E</X3>
<X4>R</X4>
</L1>
<L2>
<L3>
<X5>T</X5>
</L3>
</L2>
</msg_TESTREQUEST>
When I move the <L3> branch, I get:
<msg_TESTREQUEST>
<X1>Q</X1>
<X2>W</X2>
<L1>
<X3>E</X3>
<X4>R</X4>
<LEVEL3>
<FIELD5>T</FIELD5>
</LEVEL3>
</L1>
<L2></L2>
</msg_TESTREQUEST>
The esql code I am using is:
SET OutputRoot = InputRoot;
SET OutputRoot.Properties.MessageFormat = 'XML1';
DECLARE ref1 REFERENCE TO OutputRoot.MRM.LEVEL2.LEVEL3;
DETACH ref1;
ATTACH ref1 TO OutputRoot.MRM.LEVEL1 AS LASTCHILD;
I used the identical code in WMQI v2.1 and it worked fine. Did I miss some documented explaination for this behavior? Any ideas how to get around it besides not using the MRM parser for the XML conversion? The actual message is quite large and I would hate to re-code it all. |
|
| Back to top |
|
 |
| shanson |
| Posted: Fri Jul 08, 2005 2:02 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
I think the problem is caused by the change in logical structure that has taken place, combined with an intended change in behaviour from V2.1 to V5. Your input logical message structure is:
FIELD1
FIELD2
LEVEL1
--FIELD3
--FIELD4
LEVEL2
--LEVEL3
----FIELD5
Your output logical structure is:
FIELD1
FIELD2
LEVEL1
--FIELD3
--FIELD4
--LEVEL3
----FIELD5
LEVEL2
On output, the MRM parser finds in the tree a child of LEVEL1 called LEVEL3 and looks for a match in the model. It correctly does not find it, as LEVEL3 is a child of LEVEL2 in the model. LEVEL3 is then output as a self-defining element, which explains why the XML name is appearing as the model name.
Why did this work in V2.1? In V2.1 all elements were global and had a unique identifier. There could only be one LEVEL3, so it matched ok. In V5 elements can be local and can have the same name, scoped by parent complex type. Matching of local elements is therefore only within complex type. That's why the match for LEVEL3 fails in V5.
To get round this, you have two choices:
1) Create a second logical model for the output message. After all, the structures are not the same.
2) Make LEVEL3 a global element and replace the local element with a reference to the global one. This mimics V2.1 and I believe LEVEL3 will then match ok.
Note that when migrating a message set from V2.1 using mqsimigratemsgsets there is a -g option that if set will keep the V2.1 style of the message set, and make all elements global. |
|
| Back to top |
|
|
| shanson |
| Posted: Fri Jul 08, 2005 2:37 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
Note that switching on validation in conjunction with complex type/group Composition='Closed' is a good way to catch inadvertent use of self-defining elements. We recommend that you switch on validation during development even if you have no business case for it in production.
For option 2 above to work with validation you need to set Composition='Open Defined' on the complex type/group for LEVEL1. That allows LEVEL3 to appear in LEVEL1 even though the model says it can't. |
|
| Back to top |
|
|
| pjaffe |
| Posted: Fri Jul 08, 2005 6:21 am Post subject: how to limit re-coding |
|
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
| What is the simplest method to create a second logical message definition? My problem is that I don't have a COBOL copybook or XML schema that I can import. Am I just going to create a Message Set Project and use the original as the base message set? Can't I have them both in the same project and just order the levels differently as 2 different messages? I have a lrge number of fields and each has a XML tag name that I would need to re-enter if I rebuild it from scratch. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 08, 2005 6:33 am Post subject: Re: how to limit re-coding |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| pjaffe wrote: |
| Can't I have them both in the same project and just order the levels differently as 2 different messages? |
I don't see why not.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pjaffe |
| Posted: Fri Jul 08, 2005 6:41 am Post subject: how? |
|
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
The only problem is how to put both in the same project with different orders. I can't see it.
My work with message sets has always been creating new ones based on importing a cobol or XML file. I have added individual fields but nothing on the scale of copying a message definition. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 08, 2005 6:47 am Post subject: Re: how? |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| pjaffe wrote: |
| The only problem is how to put both in the same project with different orders. I can't see it. |
Create a new message. Add groups and elements in the right order.
Create new groups where necessary. This may require you to hand enter some tags. Or you can copy the groups with new names.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
