| Author |
Message
|
| m00300 |
 Posted: Thu May 13, 2004 7:48 am Post subject: Repeat fields in wrong place in CWF post migration to v5 |
 |
|
Apprentice
Joined: 01 May 2002
Posts: 31
|
I've just migrated a message set into into v5 which is used for converting XML messages to CWF format.
When i run messages through now in v5 which contain repeating groups the repeating group count fields (which are all specified as being at the top of the logical model) are now appearing just above their respective repeating groups.
This causes the message to fail the parse with the error :
2004-05-13 15:56:05.719333 4796 ParserException BIP5344E: CWF Output: Mismatch between logical definition and message tree.
Message : INBD_CUSTOMER_MSG
Element : 69^INCU_CM_MANAG_FL
The CWF writer has been given a message tree which does not match the logical message definition.
Heres part of the trace after the compute node which does the change to CWF (you can see the '_CNT' fields just before the groups below):
(0x03000015):INAD_POST_CODE = 'EH9 1PB'
(0x03000000):INAD_STREET_NAME_PB = 'U'
(0x03000015):INAD_STREET_NAME = 'Livingstone Place'
(0x03000000):INAD_VILLAGE_PB = 'I'
(0x03000000):INAD_VILLAGE = ''
)
(0x03000000):REL_CNT = 2
(0x01000000):INRE_RELATIONSHIP_MESSAGE = (
(0x03000000):INRE_REL_END_DT_PB = 'I'
(0x03000000):INRE_REL_END_DT = ''
(0x03000000):INRE_REL_STA_DT_PB = 'I'
(0x03000000):INRE_REL_STA_DT = ''
(0x03000000):INRE_ORIG_SYS_CUST_ID_PB = 'U'
(0x03000000):INRE_ORIG_SYS_CUST_ID = '120000000000007'
(0x03000000):INRE_SRC_REL_CD_PB = 'U'
(0x03000015):INRE_SRC_REL_CD = 'HUS'
(0x03000000):INRE_SRC_SYS_CUST_ID_PB = 'U'
(0x03000000):INRE_SRC_SYS_CUST_ID = '900210'
(0x03000000):INRE_TARG_REL_CD_PB = 'U'
(0x03000015):INRE_TARG_REL_CD = 'WIF'
(0x03000000):INRE_TARG_SYS_CUST_ID_PB = 'U'
(0x03000000):INRE_TARG_SYS_CUST_ID = '120000000000007'
)
(0x01000000):INRE_RELATIONSHIP_MESSAGE = (
(0x03000000):INRE_REL_END_DT_PB = 'I'
(0x03000000):INRE_REL_END_DT = ''
(0x03000000):INRE_REL_STA_DT_PB = 'I'
(0x03000000):INRE_REL_STA_DT = ''
(0x03000000):INRE_ORIG_SYS_CUST_ID_PB = 'U'
(0x03000000):INRE_ORIG_SYS_CUST_ID = '120000000000008'
(0x03000000):INRE_SRC_REL_CD_PB = 'U'
(0x03000015):INRE_SRC_REL_CD = 'FAT'
(0x03000000):INRE_SRC_SYS_CUST_ID_PB = 'U'
(0x03000000):INRE_SRC_SYS_CUST_ID = '900220'
(0x03000000):INRE_TARG_REL_CD_PB = 'U'
(0x03000015):INRE_TARG_REL_CD = 'SON'
(0x03000000):INRE_TARG_SYS_CUST_ID_PB = 'U'
(0x03000000):INRE_TARG_SYS_CUST_ID = '120000000000008'
)
(0x03000000):MERGE_CNT = 0
(0x03000000):MAIL_CNT = 0
(0x03000000):CONT_CNT = 2
(0x01000000):INCO_CONTACT_MESSAGE = (
(0x03000000):INCO_CNTCT_EXT_NO_PB = 'U'
(0x03000015):INCO_CNTCT_EXT_NO = 'TD50_1_Xtn'
(0x03000000):INCO_CNTCT_NO_PB = 'U'
(0x03000015):INCO_CNTCT_NO = 'TD50_1_Cnmber_TD_End'
(0x03000000):INCO_CNTCT_LST_DT_PB = 'U'
(0x03000015):INCO_CNTCT_LST_DT = '01.03.1950'
(0x03000000):INCO_CNTCT_REFU_DT_PB = 'U'
(0x03000015):INCO_CNTCT_REFU_DT = '02.03.1950'
(0x03000000):INCO_CNTCT_NO_TYP_PB = 'U'
(0x03000015):INCO_CNTCT_NO_TYP = 'DAYNO'
(0x03000000):INCO_CNTCT_VER_DT_PB = 'I'
(0x03000000):INCO_CNTCT_VER_DT = ''
)
(0x01000000):INCO_CONTACT_MESSAGE = (
(0x03000000):INCO_CNTCT_EXT_NO_PB = 'U'
(0x03000015):INCO_CNTCT_EXT_NO = 'TD50_2_Xtn'
(0x03000000):INCO_CNTCT_NO_PB = 'U'
(0x03000015):INCO_CNTCT_NO = 'TD50_2_Cnmber_TD_End'
(0x03000000):INCO_CNTCT_LST_DT_PB = 'U'
(0x03000015):INCO_CNTCT_LST_DT = '01.04.1950'
(0x03000000):INCO_CNTCT_REFU_DT_PB = 'U'
(0x03000015):INCO_CNTCT_REFU_DT = '02.04.1950'
(0x03000000):INCO_CNTCT_NO_TYP_PB = 'U'
(0x03000015):INCO_CNTCT_NO_TYP = 'EVNNO'
(0x03000000):INCO_CNTCT_VER_DT_PB = 'I'
(0x03000000):INCO_CNTCT_VER_DT = ''
)
)
)
)
However they should be at the top of the message (hence the error shown above):
)
(0x01000021):MRM = (
(0x03000000):INBD_LINE_CODE = 1
(0x03000000):INBD_MASTER_PB = 'U'
(0x01000000):INCU_CUSTOMER_MESSAGE = (
IN HERE!!!
(0x03000000):INCU_CM_MANAG_FL_PB = 'U'
(0x03000015):INCU_CM_MANAG_FL = 'Y'
(0x03000000):INCU_CM_MANAG_FL_DT_PB = 'U'
The logical model shows them in the correct place and all the Composition values for types are set to 'unorderedSet' however the CWF writer appears to have written them in the order of the ESQL statements and ignored the logical model.
Any ideas why this occurs ?
There are some odd looking '**Anonymous**' types that have appeared in the logical model after the migration - could these cause this ? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu May 13, 2004 8:43 am Post subject: Re: Repeat fields in wrong place in CWF post migration to v5 |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| m00300 wrote: |
The logical model shows them in the correct place and all the Composition values for types are set to 'unorderedSet' however the CWF writer appears to have written them in the order of the ESQL statements and ignored the logical model.
Any ideas why this occurs ?
There are some odd looking '**Anonymous**' types that have appeared in the logical model after the migration - could these cause this ? |
Since at least 2.1, the order of the ESQL determines absolutely the order of appearance of the fields in the message.
In other words, it's doing what it's supposed to - it's doing what you tell it to do.
The **Anonymous** types aren't related to this problem, but you should review the migration documentation to understand what they are telling you and where they may or may not cause problems.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JT |
| Posted: Thu May 13, 2004 9:47 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Jeff wrote: |
| Since at least 2.1, the order of the ESQL determines absolutely the order of appearance of the fields in the message. |
Could you clarify this statement? Please correct me if I mis-understood, but doesn't the unordered set classification allow you to build elements of the output message in any sequence? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 13, 2004 10:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, if your Message Models says that Field 1, 2 and 3 can appear in any order, then it does not matter if your ESQL says "Create Field 3, Field 1 and then Field 2".
But if your Message Model says that Field 1 must come first, followed by Field 2, followed by Field 3, then your ESQL must create them in that order.
The MRM will not, as a general rule, reorder fields to make sure that they are in the correct order.
There are situations where this can happen, but I don't remember them off the top of my head and it is better not to rely on them. There has been discussion here before about those situations, so if you are interested, you can look for it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JT |
| Posted: Thu May 13, 2004 11:08 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Jeff,
My confusion stems from this statement in the v5.0 Information Center pertaining to an unordered set:
| Quote: |
Unordered Set
You can build elements of the output message in any sequence. On output, the elements will be written in the order specified in the logical message model defintion. |
I understood this to mean that regardless of the order the elements were built through the ESQL statements they would be re-ordered to reflect the message model upon exit. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 13, 2004 12:06 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That may, in fact, be one of the situations that I do not recall properly.
But very few people build models with unordered sets.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| m00300 |
| Posted: Fri May 14, 2004 4:24 am Post subject: |
|
|
Apprentice
Joined: 01 May 2002
Posts: 31
|
I to had read that part in the manual about UnorderedSets and understood it to mean that you could write the elements in any order.
However i've re-ordered the esql statements so the order matches the logical model and the trace now looks like the model :
)
(0x01000021):MRM = (
(0x03000000):INBD_LINE_CODE = 1
(0x03000000):INBD_MASTER_PB = 'U'
(0x01000000):INCU_CUSTOMER_MESSAGE = (
(0x03000000):ADDR_CNT = 0
(0x03000000):REL_CNT = 0
(0x03000000):MERGE_CNT = 0
(0x03000000):MAIL_CNT = 0
(0x03000000):CONT_CNT = 0
(0x03000000):INCU_CM_MANAG_FL_PB = 'U'
(0x03000015):INCU_CM_MANAG_FL = 'Y'
(0x03000000):INCU_CM_MANAG_FL_DT_PB = 'U'
(0x03000015):INCU_CM_MANAG_FL_DT = '01.01.1950'
(0x03000000):INCU_COMM_CHANNEL_PREF_PB = 'I'
(0x03000000):INCU_COMM_CHANNEL_PREF = ''
(0x03000000):INCU_COY_CAR_FL_PB = 'U'
(0x03000015):INCU_COY_CAR_FL = 'Y'
(0x03000000):INCU_COY_CAR_LST_DT_PB = 'U'
(0x03000015):INCU_COY_CAR_LST_DT = '02.01.1950'
but I still get the same error :
2004-05-14 13:09:02.375016 5836 ParserException BIP5286E: Message Translation Interface Writing Errors have occurred:
Message Set Name : 'AD_TRA_XML_CWF'
Message Set Level : '1'
Message Format : 'CWF'
Message Type Path : 'INBD_CUSTOMER_MSG'
Review further error messages for an indication to the cause of the errors.
2004-05-14 13:09:02.375168 5836 ParserException BIP5167E: Custom Wire Format error while parsing/writing message 'INBD_CUSTOMER_MSG'.
2004-05-14 13:09:02.375245 5836 ParserException BIP5350E: Custom Wire Format writing error. While writing the message quoted above, the CWF writer encountered an error.
The error occurred during or after the writing of element '/INBD_CUSTOMER_MSG/INCU_CUSTOMER_MESSAGE/INCU_CM_MANAG_FL_PB'.
Check that you have built the message correctly.
See following messages for more details.
2004-05-14 13:09:02.375355 5836 ParserException BIP5344E: CWF Output: Mismatch between logical definition and message tree.
Message : INBD_CUSTOMER_MSG
Element : 69^INCU_CM_MANAG_FL
The CWF writer has been given a message tree which does not match the logical message definition.
Any more suggestions/things i should be checking ? |
|
| Back to top |
|
|
| JMB |
| Posted: Fri May 14, 2004 4:56 am Post subject: |
|
|
Apprentice
Joined: 01 Apr 2002
Posts: 29
|
| Quote: |
| (0x01000000):INCU_CUSTOMER_MESSAGE = ( |
| Quote: |
| Message Type Path : 'INBD_CUSTOMER_MSG' |
perhaps this mismatch is an issue? |
|
| Back to top |
|
|
| m00300 |
| Posted: Fri May 14, 2004 5:54 am Post subject: |
|
|
Apprentice
Joined: 01 May 2002
Posts: 31
|
no 'INCU_CUSTOMER_MESSAGE' is a subtype within the message itself 'INBD_CUSTOMER_MSG' - badly named i know!
My moneys on :
a) the message set wasnt migrated properly (by that I mean that what we had in v2.0.2 is achived differently in v5 and it couldnt be mapped directly by the migration util)
or
b) the way CWF operates in v5 is fundamenatally different than in v2.0.2
either way I think the message set may have to re-written (i'm building a small example from scratch to prove this) |
|
| Back to top |
|
|
| m00300 |
| Posted: Fri May 14, 2004 7:53 am Post subject: |
|
|
Apprentice
Joined: 01 May 2002
Posts: 31
|
Well I've built an example, a minature version of the original message set with all the same features (unordered set, repeating groups, sub types etc..) and coded the ESQL in the wrong order on purpose and it works fine!
The Trace after the compute nodes shows the fields in the order they were written by the ESQL but when the message is written to the queue they are re-ordered as per the logical model and parse successfully.
This kind of proves my migrated message set with the **ANONYMOUS** types is the culprit . Tried understanding the manual entries on **ANONYMOUS** but I must admit I dont think I followed most of it 
I will be recoding the migrated message set on Monday to remove the **ANONYMOUS** types will report if this fixes things. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 17, 2004 2:41 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| The ANONYMOUS types are simply local complex types. By default, mqsimigratemsgsets creates local types when it can (i.e when the type is only used once). You can override this by using the '-g' switch on mqsimigratemsgsets - that would certainly settle the question of whether the local types are causing the problem. |
|
| Back to top |
|
|
| m00300 |
| Posted: Tue May 18, 2004 6:36 am Post subject: solved at last... |
|
|
Apprentice
Joined: 01 May 2002
Posts: 31
|
Thanks for the tip about '-g' that removed the ANONYMOUS types.
However that didnt turn out to be the problem.
Infact the problem wasnt with the outgoing CWF message set at all - it was a problem with the input XML message set that I finally tracked down as being the cause.
I hadnt added an XML wire format on the incoming mesasage set and this caused the unwanted 'attributes' to be passed over to the output message set and cause the parse to fail.
These showed up as (0x03000015):INCS_ORIG_SYS = 'VEC'
in the output trace.
They should look like (0x03000000):INCS_ORIG_SYS = 'VEC'
The tip off was when I tried replacing the 'SET OutputRoot.MRM.blah = InputRoot.MRM.blah' with 'SET OutputRoot.MRM.blah = 'X' (i.e. a literal) and the trace then changed to look like this : (0x03000000):INCS_ORIG_SYS = 'X'
I hadnt added any XML wire formats as the vast majority of our processing is all XML based as this worked fine without the wire format layer and on the basis of 'if it aint broke dont fix it!' I left well alone.
However in the case of moving from XML to Fixed Format this appears to be important.
The other way to fix it was to code the following style of statements : 'SET OutputRoot.MRM.blah = FIELDVALUE(InputRoot.MRM.blah)' But this requires recoding so to be avoided during migration if at all possible!  |
|
| Back to top |
|
|
|
|
