| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Is there a way to have an MRM message with alternative... |
« View previous topic :: View next topic » |
| Author |
Message
|
| dkesel |
 Posted: Wed Nov 13, 2002 2:54 pm Post subject: Is there a way to have an MRM message with alternative... |
 |
|
Newbie
Joined: 08 Nov 2002
Posts: 4
|
elements (message types) underneath it?
I don't know if I am asking this question correctly but basically I am trying to replace an MQSI 1.1.1 alternative input compound with a WMQI V2.1 MRM. The data looks roughly like this...
"To From Subject Body "
-OR-
"Id To From Subject Body"
One of the 2 messages will get put to the input queue depending on which program does the put. Both input messages are the same length, so I can't parse on that. If I bring the data as a BLOB I don't have a field to filter on for the ResetContentDescriptor.
In MQSI version 1.1.1 I would be able to define 2 flat formats and put them under one compound and check Alternative for the Component Format Order. Is there something similar in WMQI V2.1?
Thanks in advance for any help at all!
Donna |
|
| Back to top |
|
 |
| Miriam Kaestner |
| Posted: Thu Nov 14, 2002 2:52 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
You can use compound types with type composition = CHOICE to model this. But how the broker resolves the choice for incoming message depends on the physical format.
If it is CWF or TDS with no tags, unresolved choice handling occurs. That means, the broker takes the choice that is first referred to. So you must write ESQL to determine which is the right choice - in your sample, whether the ID field is present or not. |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Thu Nov 14, 2002 6:06 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Isn't this NEON thing fun? As the MRM becomes more robust, the decision to migrate is not always easy.....
I assume from your post that the alternatives must have some type of literal value or delimiter in the alternatives since they are the same length and the parse based on the first format definition would always be successful if it was completely based on length.
If this is the case (and you do not have any repeating formats previous to the alternative) you can just SUBSTRING the BLOB where the literal value should be and then use this as your field to filter on.
Example:
SUBSTRING(INCOMING from 34 FOR 2) = x'3030'
After all that, my short answer is that the MRM does not have the robustness yet to handle this situation purely from its parsing definition. (It would be a pleasant surprise if someone corrected me and showed us how to do it, though.)
I think that you are on the right track. If it ain't broke, don't fix it, but keep an eye on the MRM to see what improvements are coming, since MRM will always be supported and you might have to make the jump one day.
One more thought. I don't know your messaging side, but if the sending application built the MQRFH2 with the appropriate message set defined, this would make things a bit easier since the message itself would define what message set to use.
Good luck from an old NEON guy. 
Todd |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
