| Author |
Message
|
| hdjur |
 Posted: Fri Dec 08, 2006 7:18 am Post subject: different message types in the same input q - best practice |
 |
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi!
I have to parse different message types in the same message domain (for example MRM), and in the same message format (for example TDS format with Fixed length data separation), arriving in the same queue.
How can I achieve it simply with MQInput node or otherwise? What would be the best practice for that? I hope that broker does not expect to have separate input queues for different message types, since IBM claims broker is a tool which may intervene, in non invasive manner regarding applications.
Thanks in advance. |
|
| Back to top |
|
 |
| dipankar |
| Posted: Fri Dec 08, 2006 7:26 am Post subject: |
|
|
Disciple
Joined: 03 Feb 2005
Posts: 171
|
hdjur,
You can achieve this by multipart messaging model or by esql (create statement with parse) in the next compute node.
_________________
Regards |
|
| Back to top |
|
|
| gregop |
| Posted: Fri Dec 08, 2006 7:29 am Post subject: |
|
|
Voyager
Joined: 24 Nov 2006
Posts: 81
|
Or have the application that writes the messages include RFH2 header with mcd containing the domain, set and message type.
e.g.
<mcd><Msd>MRM</Msd><Set>DHM4UO906S001</Set><Type>receiptmsg1</Type><Fmt>TDS</Fmt></mcd>
This takes precedence over MQInput values for parsing |
|
| Back to top |
|
|
| hdjur |
| Posted: Fri Dec 08, 2006 7:41 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 08, 2006 7:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, in v6 you can set a field in your message definition as a Message Indicator.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 08, 2006 7:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
And if the data is XML and you have modelled it, it will pick the right message definition based on the root tag (assuming they have different root tags).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Dec 13, 2006 6:18 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
| Can someone please provide an url with downloadable importable example for this (multipart message, MRM parser, TDS, fixed length data separation). I was looking at Samples Galery inside Toolkit (Application samples and Technology samples), and didn't find any adequate. Thanks. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Dec 13, 2006 1:17 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
hi hdjur,
I'm still not sure what your requirement is:
- Do all your input messages have a standard header section, followed by one of several 'body messages'.
- Or is each message a completely different fixed-length structure? |
|
| Back to top |
|
|
| hdjur |
| Posted: Thu Dec 14, 2006 1:17 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi kimbert,
my messages have a standard header section followed by one of several body messages. In fact, I may identify in this header one local element as a Message Identity. Without waiting for anyone's answer, I have continued working on my own, looking through documentation, and done this:
- created new message (intention is to make it multipart)
- added new local group to it
- properties of this group are set to Composition:message; Content validation:Closed
- to this group I have added messages which may occur in input queue
- for every message I have defined message alias, which is a string which is equal to the value of the local string element, whose value is interpreted as MessageIdentity
- in every message this elements have the same length, even the same name
- I have set this new message (multipart) as a Message Type in Default tab of Properties dialogue of MQInput node
- when I put message to a queue I receive this:
| Code: |
Dec 13 19:48:39 hrambtest user:err|error WebSphere Broker v6000[286826]: (WBRK.default)[6426]BIP2498E: (.route_msgflow_Filter.Main, 14.6) : An error occurred whilst navigating to the '3'th path element of the field reference at the given location. : WBRK.3582535d-0f01-0000-0080-c0c87da9fe6b: /build/S000_P/src/DataFlowEngine/ImbRdl/ImbRdlFieldRef.cpp: 2323: SqlFieldReference::evaluate: ComIbmFilterNode: route_msgflow#FCMComposite_1_8
Dec 13 19:48:39 hrambtest user:err|error WebSphere Broker v6000[286826]: (WBRK.default)[6426]BIP5285E: Message Translation Interface Parsing Errors have occurred: : WBRK.3582535d-0f01-0000-0080-c0c87da9fe6b: /build/S000_P/src/MTI/MTIforBroker/MtiImbParser2/MtiImbParser.cpp: 445: MtiImbParser::parseFirstChild: ComIbmMQInputNode: route_msgflow#FCMComposite_1_1
Dec 13 19:48:39 hrambtest user:info WebSphere Broker v6000[286826]: (WBRK.default)[6426]BIP5421S: Tagged/Delimited String Format (TDS) parsing error : WBRK.3582535d-0f01-0000-0080-c0c87da9fe6b: /build/S000_P/src/cpi/pwf/nxd/nxdworker.cpp: 456: NXDWorker::parseNext: :
Dec 13 19:48:39 hrambtest user:err|error WebSphere Broker v6000[286826]: (WBRK.default)[6426]BIP5428E: The bitstream does not contain the required Message Key, Message Identity or Message Path for a nested message. : WBRK.3582535d-0f01-0000-0080-c0c87da9fe6b: /build/S000_P/src/cpi/pwf/nxd/nxddataelementseparation.cpp: 4098: NXDUndefinedDataElSep::parseFirst: :
Dec 13 19:48:40 hrambtest user:err|error WebSphere Broker v6000[286826]: (WBRK.default)[6426]BIP2648E: Message backed out to a queue; node 'route_msgflow.MQInput'. : WBRK.3582535d-0f01-0000-0080-c0c87da9fe6b: /build/S000_P/src/DataFlowEngine/ImbMqInputNode.cpp: 1819: ImbCommonInputNode::eligibleForBackout: ComIbmMQInputNode: route_msgflow#FCMComposite_1_1
|
For example, if this local group consists of two messages, and the first one has alias 123, the second one 321, first message has local element called "a" of fixed length 3 bytes (value interpreted as MessageIdentity), and the second one called "b" of 4 bytes, and the second message has local element called "a" of fixed length 3 bytes (value interpreted as MessageIdentity), and the second one called "c" of 5 bytes length, I receive this errors and messages are backed out, and the message buffer are for example:
1231234
or
32112345
Obviously, I didn't understand something, but I don't know what. These are not my real messages, it's just for testing multipart messages parsing. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Dec 14, 2006 2:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
hi hdjur,
Good work so far. You're on the right track.
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.
I cannot be sure what the problem is yet, so we need to go through the process step by step. First thing is to check that your message identity element is getting parsed correctly:
- Remove the local group which represents the inner message. Your message definition now describes only the header.
- Shorten the input message so that the input bitstream only contains the header.
- Using the debugger or a trace node, check that your Message Identity element has the correct value. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Dec 20, 2006 12:56 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi Kimbert,
here are two versions of mxsd files, I tried to achieve the described behaviour of multipart message parsing using message identity, none of them works. Could you please look at them and tell what's wrong?
version 1:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:tns="http://www.mrmnames.net" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.mrmnames.net">
<xsd:include schemaLocation="common_header.mxsd"/>
<xsd:complexType name="complexType1">
<xsd:sequence maxOccurs="1" minOccurs="1">
<xsd:element name="a" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMSGLogicalModelExtension_logicalModelExtension interpretValueAs="MessageIdentity"/>
<tdsElemRep justification="leftJustify" length="3" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:choice>
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRLocalGroup composition="message"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:element ref="tns:message2"/>
<xsd:element ref="tns:message3"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message1" type="tns:complexType1">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMessage messageDefinition="/0/message1;XSDElementDeclaration$MRObject"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="complexType2">
<xsd:sequence>
<xsd:element name="b" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<tdsElemRep justification="leftJustify" length="4" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message2" type="tns:complexType2">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMessage messageDefinition="/0/message2;XSDElementDeclaration=1$MRObject">
<MRMSGLogicalModelExtension_logicalModelExtension messageAlias="123"/>
</MRMessage>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="complexType3">
<xsd:sequence>
<xsd:element name="c" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<tdsElemRep justification="leftJustify" length="5" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message3" type="tns:complexType3">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMessage messageDefinition="/0/message3;XSDElementDeclaration=2$MRObject">
<MRMSGLogicalModelExtension_logicalModelExtension messageAlias="321"/>
</MRMessage>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:schema>
version 2:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:tns="http://www.mrmnames.net" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.mrmnames.net">
<xsd:include schemaLocation="common_header.mxsd"/>
<xsd:complexType name="complexType1">
<xsd:sequence maxOccurs="1" minOccurs="1">
<xsd:choice>
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRLocalGroup composition="message"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:element ref="tns:message2"/>
<xsd:element ref="tns:message3"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message1" type="tns:complexType1">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMessage messageDefinition="/0/message1;XSDElementDeclaration$MRObject"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="complexType2">
<xsd:sequence>
<xsd:element name="a" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMSGLogicalModelExtension_logicalModelExtension interpretValueAs="MessageIdentity"/>
<tdsElemRep justification="leftJustify" length="3" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="b" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<tdsElemRep justification="leftJustify" length="4" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message2" type="tns:complexType2">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMessage messageDefinition="/0/message2;XSDElementDeclaration=1$MRObject">
<MRMSGLogicalModelExtension_logicalModelExtension messageAlias="123"/>
</MRMessage>
<MRMSGLogicalModelExtension_logicalModelExtension messageAlias="123"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="complexType3">
<xsd:sequence>
<xsd:element name="a" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMSGLogicalModelExtension_logicalModelExtension interpretValueAs="MessageIdentity"/>
<tdsElemRep justification="leftJustify" length="3" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="c" type="xsd:string">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<tdsElemRep justification="leftJustify" length="5" messageSetDefaultRep="TDS1" precision="-1"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message3" type="tns:complexType3">
<xsd:annotation>
<xsd:appinfo source="WMQI_APPINFO">
<MRMessage messageDefinition="/0/message3;XSDElementDeclaration=2$MRObject">
<MRMSGLogicalModelExtension_logicalModelExtension messageAlias="321"/>
</MRMessage>
<MRMSGLogicalModelExtension_logicalModelExtension messageAlias="321"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:schema>
Thank you.
Last edited by hdjur on Wed Dec 20, 2006 8:19 am; edited 2 times in total |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Dec 20, 2006 1:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I will gladly give help and advice, but I'm not going to spend hours recreating your problem.
| Quote: |
| Could you please look at them and tell what's wrong? |
No ( my name is not Einstein  )
| Quote: |
| none of them works |
What goes wrong?
Sorry to say it again, but you need to solve your problem one step at a time. I would start by making sure that your header is getting parsed correctly. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Dec 20, 2006 3:09 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
All right, I did it. I think it would take less than a minute to take a look at both definitions and see differences. Now I have the third, according to your suggestion, and again I'm not sure if it is what you think it has to be. The result is the same. Message is backed out to a queue defined by attr BOQNAME of the input q (that is what goes wrong in all three cases):
Dec 20 11:09:47 hrambtest user:err|error WebSphere Broker v6000[286826]: (WBRK.default)[6426]BIP2648E: Message backed out to a queue; node 'route_msgflow.MQInput'. : WBRK.3582535d-0f01-0000-0080-c0c87da9fe6b: /build/S000_P/src/DataFlowEngine/ImbMqInputNode.cpp: 1819: ImbCommonInputNode::eligibleForBackout: ComIbmMQInputNode: route_msgflow#FCMComposite_1_1
Only this time, no parsing error was reported.
If I change the property of the MQInput node Message Type from message1 to message2 (see .mxsd files), input message is correctly parsed and is not backed out. Trace is like this:
Root.MRM: (
(0x0300000B):a = '123'
(0x0300000B):b = '1234'
) |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Dec 20, 2006 3:19 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
| When I said less than a minute, I meant using Message Definition Editor ... |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Dec 20, 2006 4:23 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| All right, I did it. I think it would take less than a minute to take a look at both definitions and see differences |
How long would it take for you to highlight those differences in your original post? Why should I have to load your mxsd files into my tooling just to find out what you know already?
I did notice that message 1 does not have a message alias defined. Maybe you corrected that already. |
|
| Back to top |
|
|
|
|
