| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| different message types in the same input q - best practice |
« View previous topic :: View next topic » |
| Author |
Message
|
| hdjur |
 Posted: Wed Dec 20, 2006 6:09 am Post subject: |
 |
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
I highlighted the differences, I thought loading mxsd files into editor would be easier for you to understand my dillema on how to define message, than describing differences.
In the first version, "a" is defined only inside "message1", before a local group consisting of "message2" and "message3", "message2" defines only "b", and "message3" only "c". In the second version, "message1" consists only of a local group, local element "a" is defined inside both "message2" and "message3".
Why would I define message alias for "message1"? My understanding (obviously wrong) was that I have to define aliases for messages inside the group.
Can you provide an .mxsd example (or the relevant document) which would help? |
|
| Back to top |
|
 |
| kimbert |
| Posted: Wed Dec 20, 2006 2:15 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
So message1 is a different kind of message from message2 and message3? I suggest you choose a different naming convention. How about renaming message1 to 'outerMessage'? While you're doing that, how about renaming 'a' to 'messageIdentifier' and renumbering message2 and message3?
The only thing that matters to the MRM parser is this: when it encounters a complex type or group with composition=message it needs to have a message identifier. Otherwise it does not know how to parse the embedded message. IF the message identifier matches a message alias or a message name THEN parsing will proceed using that message definition.
So as long as you have parsed 'messageIdentifier' before you get to the embedded message you should be OK. Other users have got this working, so I suggest that you follow my advice. First check that the header is being parsed correctly ( otherwise the message identifier will be incorrect and nothing else will work ). |
|
| Back to top |
|
|
| hdjur |
| Posted: Thu Dec 21, 2006 5:20 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi kimbert! How are you?
I follow your advices all the time. You asked me to highlight differences, I did it. You asked me to remove the local group which represents the inner message, shorten the input message so that it only contains the header, use a trace node, and I did it. I have reported that in this case message is backed out too, but it is not. It is properly parsed and in the trace there is for example:
This is Root.MRM: (
(0x0300000B):a = '123'
)
This is Root.MRM: (
(0x0300000B):a = '321'
)
Only, in this case, there is no multipart message (without the inner group of messages). If I followed your last advice, instead of "a" there would be "messageIdentifier". If I understand you well (and I can't be sure if I do) you don't have objections to version 1 mxsd?
I want to achieve behaviour like this:
input message : 1231234 parsed as: a='123' b='1234'
input message : 32112345 parsed as: a='321' c='12345'
Would you send me the correct mxsd, if my version 1 is not correct? |
|
| Back to top |
|
|
| hdjur |
| Posted: Thu Dec 28, 2006 9:36 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
| kimbert wrote: |
| The error message which you are getting (BIP5428E) is from the TDS parser. It is trying to use the old TDS-only multipart message support. Maybe because it could not identify the message using your Message Identity. |
That's the key, it (version 1) works as intended with message key instead of message identity. Toolkit warnings made me to quick "fix" message key usage, telling it was deprecated. We have this version:
$ mqsiservice -v
BIPv600 hr HR
ucnv Console CCSID 912 dft ucnv CCSID 912
OS ISO8859-2 ICUW ibm-912_P100-1995 ICUA ibm-912_P100-1995
BIP8996I: Version: 6000
BIP8997I: Product: WebSphere Message Brokers
BIP8998I: CMVC Level: S000-L50920.2 DH000-L50920
BIP8999I: Build Type: Production
BIP8071I: Successful command completion. |
|
| Back to top |
|
|
| hdjur |
| Posted: Thu Jan 04, 2007 6:25 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Happy New Year everyone!
1. How can I tell if parser understands some local element as a message key (or message identity) using trace node? I have printed all correlation names in the logical message tree, searching for something like "interpretElementValue", but it is not contained there.
I'm trying to understand the suggestion that it does not matter if it is not fully functional and meaningfull multipart message, when inner local group of messages is removed, if outer message contains local element whose value is interpreted as message key, I should still be able to test (multipart) message parsing using trace node, but I don't see how.
2. Is this some known issue with version 6, why am I forced to use message key, instead of message identity? I have studied "WebSphere Event Broker and Message Broker V6 problems fixed in Fix Packs" and I can't find anything like that. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 04, 2007 6:52 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
Hi hdjur,
Happy New Year to you.
| Quote: |
| How can I tell if parser understands some local element as a message key (or message identity) using trace node? |
Sorry - not possible. But you can at least tell that the message key element has the correct string value.
| Quote: |
| 'm trying to understand the suggestion that it does not matter if it is not fully functional and meaningfull multipart message, when inner local group of messages is removed, if outer message contains local element whose value is interpreted as message key, I should still be able to test (multipart) message parsing using trace node, but I don't see how. |
Obviously you cannot fully test multipart messaging unless your model contains an embedded message. Hopefully you knew that already. But you can check that your header is being parsed correctly. That is a very good idea, because if your message identity field is incorrect, you will not be able to resolve the embedded message. In other words, it is a good idea to solve one problem at a time. First get the header to parse correctly, then add the embedded message.
| Quote: |
| Is this some known issue with version 6, why am I forced to use message key, instead of message identity? |
You are not forced to use Message Key in v6. Others have successfully implemented solutions using Message Identity. You have had more success with Message Key. If you don't like using Message Key, have another try at using Message Identity. |
|
| Back to top |
|
|
| hdjur |
| Posted: Thu Jan 04, 2007 8:26 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi kimbert,
There was no doubt at any one moment, the critical local element (does not matter whether is it set up as message key, message identity, or no value interpretation) is properly parsed, has correct string value etc, as long as there is no embedded message. The only case when parsing does fail, is when model contains embedded message, and the local element is set up as message identity:
| Code: |
Dec 21 10:46:03 hrambtest user:err|error WebSphere Broker v6000[274470]: (WBRK.default)[6426]BIP2628E: Exception condition detected on input node 'route_msgflow.MQInput'. : WBRK.f9cdf9a0-0f01-0000-0080-929af9708d91: /build/S000_P/src/DataFlowEngine/ImbCommonInputNode.cpp: 1013: ImbCommonInputNode::run: ComIbmMQInputNode: route_msgflow#FCMComposite_1_1
Dec 21 10:46:03 hrambtest user:err|error WebSphere Broker v6000[274470]: (WBRK.default)[6426]BIP2230E: Error detected whilst processing a message in node 'route_msgflow.Trace'. : WBRK.f9cdf9a0-0f01-0000-0080-929af9708d91: /build/S000_P/src/DataFlowEngine/ImbTraceNode.cpp: 350: ImbTraceNode::evaluate: ComIbmTraceNode: route_msgflow#FCMComposite_1_3
Dec 21 10:46:03 hrambtest user:err|error WebSphere Broker v6000[274470]: (WBRK.default)[6426]BIP5285E: Message Translation Interface Parsing Errors have occurred: : WBRK.f9cdf9a0-0f01-0000-0080-929af9708d91: /build/S000_P/src/MTI/MTIforBroker/MtiImbParser2/MtiImbParser.cpp: 614: MtiImbParser::parseRightSibling: ComIbmMQInputNode: route_msgflow#FCMComposite_1_1
Dec 21 10:46:03 hrambtest user:info WebSphere Broker v6000[274470]: (WBRK.default)[6426]BIP5421S: Tagged/Delimited String Format (TDS) parsing error : WBRK.f9cdf9a0-0f01-0000-0080-929af9708d91: /build/S000_P/src/cpi/pwf/nxd/nxdworker.cpp: 456: NXDWorker::parseNext: :
Dec 21 10:46:03 hrambtest user:err|error WebSphere Broker v6000[274470]: (WBRK.default)[6426]BIP5153E: Retrieving Message Definition from dictionary: message '123'; message set 'D8KLF48002001'. : WBRK.f9cdf9a0-0f01-0000-0080-929af9708d91: /build/S000_P/src/MTI/MTIforBroker/MtiImbParser2/MtiImbFIHandler.cpp: 2862: MtiImbFIHandler::startEmbeddedMessage(int&, int&): :
Dec 21 10:46:04 hrambtest user:err|error WebSphere Broker v6000[274470]: (WBRK.default)[6426]BIP2648E: Message backed out to a queue; node 'route_msgflow.MQInput'. : WBRK.f9cdf9a0-0f01-0000-0080-929af9708d91: /build/S000_P/src/DataFlowEngine/ImbMqInputNode.cpp: 1819: ImbCommonInputNode::eligibleForBackout: ComIbmMQInputNode: route_msgflow#FCMComposite_1_1 |
If you consider this a question of good taste (what do I like better), I see no point in further analysis. But out of pure curiosity, trying to learn something from this problem, I will ask once again, could you please propose some variation in version 1 mxsd which does not include message key usage instead of message identity? Maybe I should change something on the broker side? I seriously doubt I will succeed without any change in approach to a problem. |
|
| Back to top |
|
|
| hdjur |
| Posted: Fri Jan 05, 2007 2:10 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
kimbert,
I think I can reproduce the problem. Without using target namespace
xmlns:tns="http://www.mrmnames.net"
targetNamespace="http://www.mrmnames.net"
message identity works for me too, with embedded message. But if I use target namespace, I have previously reported errors. Will you check it please? |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jan 05, 2007 2:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
Hi hdjur,
Sounds like a defect in the product. I'll make a note of it. Thanks for your persistence. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
