| Author |
Message
|
| kash3338 |
 Posted: Wed Jul 04, 2012 4:09 am Post subject: Identify Message format |
 |
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
Hi,
I have a scenario wherein I have a MQInput pointing to a Queue. This Queue can receive different kinds of message (XML, TDS or Fixed Length). Once I get this message I need to validate against a message set and then do the transformation and route to output.
Note: I do not get the source or format of the message in any headers.
I have a approach for this which I am not sure if correct,
I read the input as BLOB message. Check if the message is XML or Fixed Length or TDS (by using String operation on the BLOB message) and use the ESQL statement to cast to that format and validate the message.
Is there any better way to acheive this?
Version: WMB v7.0.0.1, WMQ v7.0 |
|
| Back to top |
|
 |
| goffinf |
| Posted: Wed Jul 04, 2012 5:01 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Could you perhaps ask the sender of the message to include a MQRFH2 usr folder value like 'MSG_TYPE' with appropriate value ?
Fraser. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Wed Jul 04, 2012 5:39 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| goffinf wrote: |
Could you perhaps ask the sender of the message to include a MQRFH2 usr folder value like 'MSG_TYPE' with appropriate value ?
Fraser. |
As I said earlier, thats not possible. I just want to know if there is any other better approach with the given requirements. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 04, 2012 5:50 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Your approach is the correct one, but...
| Quote: |
| This Queue can receive different kinds of message (XML, TDS or Fixed Length) |
Your message flow needs to work out whether the incoming message is
a) XML
b) one of your custom TDS formats
c) one of your custom CWF formats
You are perfectly placed to do the following:
- understand all of the formats that can arrive at the input node(s) of your flow
- design an algorithm that can *reliably* determine the format of any message.
We cannot really advise you on how to do that because we don't have the specifications for your custom message formats. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 04, 2012 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That being said you absolutely cannot CAST to the correct format.
You will have to PARSE the BLOB with the correct format and CCSID, ENCODING. (as per InputRoot.Properties)...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kash3338 |
| Posted: Wed Jul 04, 2012 8:18 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| kimbert wrote: |
You are perfectly placed to do the following:
- understand all of the formats that can arrive at the input node(s) of your flow
- design an algorithm that can *reliably* determine the format of any message.
We cannot really advise you on how to do that because we don't have the specifications for your custom message formats. |
Yes, what I have done is, I have handled all three formats in the ESQL currently. I have done the following checks for each of the format,
XML - Check for the '<RootElement>' using String function
TDS - Delimited with ';' - Cheked for the delimiter
Fixed Length - Checked for the total length of the record
| fjb_saper wrote: |
That being said you absolutely cannot CAST to the correct format.
You will have to PARSE the BLOB with the correct format and CCSID, ENCODING
|
I actually ment doing a PARSE on the BLOB when I said CAST. Thanks anyways. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 04, 2012 11:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| Your approach is the correct one, but... |
You could also look at declaring handlers and just parsing as XML, and if it fails then parse as TDS and if it fails then parse as CWF...
I'd also see if I could minimize the amount of searching of the BLOB you need to do. How likely is it that any message other than the XML format is going to have a first character of "<"? Can you make the same distinction in the first few characters between the TDS and the CWF? |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Jul 04, 2012 1:44 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
It may not be possible in your environment, but you could try to get the sending apps to send to a different queue so you have one queue for XML, one for TDS etc...
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 04, 2012 2:35 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I agree with mgk. I think this auto-detection of the input data format is likely to be fragile and unmaintainable. If I were in your place I would be making a strong case for either
a) separate input queues or
b) a header to identify the format.
...but I have to accept your clear statement that b) is impossible, and so a) probably is too. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Wed Jul 04, 2012 9:07 pm Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| kimbert wrote: |
If I were in your place I would be making a strong case for either
a) separate input queues or
|
This option was also considered, but I felt having a single input queue and doing a PARSE in the compute node to better than having 3 MQInputs and checking and doing a mapping in the compute node.
Which option would be better out of these two (considering all the factors),
a) Using 3 MQInputs (with message sets defined in each)
b) Reading the message as BLOB with single Queue and doing a PARSE later wit the format
| mqjeff wrote: |
I'd also see if I could minimize the amount of searching of the BLOB you need to do.
|
| mqjeff wrote: |
How likely is it that any message other than the XML format is going to have a first character of "<"?
|
Never.
| mqjeff wrote: |
Can you make the same distinction in the first few characters between the TDS and the CWF? |
This is not possible. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jul 05, 2012 1:37 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
Which option would be better out of these two (considering all the factors),
a) Using 3 MQInputs (with message sets defined in each)
b) Reading the message as BLOB with single Queue and doing a PARSE later wit the format
|
I think a). I would do it this way:
- Create separate message definitions for each input format.
- Ensure that the root element name is different in each message definition, so that your message flow can easily detect which type of message it is dealing with.
I'm not clear whether these message formats are processed identically by the message flow, or whether they are genuinely different message structures. If they are identical in their logical structure then you may be able to get away with using the same root name for all of them.
I would go a long way to avoid b) - it places information about the physical format into the message flow logic. Message flow logic should, if possible, deal with the logical structure only. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Jul 05, 2012 5:33 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| kimbert wrote: |
I think a). I would do it this way:
- Create separate message definitions for each input format.
- Ensure that the root element name is different in each message definition, so that your message flow can easily detect which type of message it is dealing with. |
By this do you mean we can do this using single MQInput node?
| kimbert wrote: |
I'm not clear whether these message formats are processed identically by the message flow, or whether they are genuinely different message structures. If they are identical in their logical structure then you may be able to get away with using the same root name for all of them.
|
They are all of same logical structure. So I am having the same root element. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jul 05, 2012 5:37 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| By this do you mean we can do this using single MQInput node? |
No - that would not be a) 
| Quote: |
| They are all of same logical structure. So I am having the same root element. |
So why even consider b)? If the upstream applications can tell you which message definition to use ( by putting the message to the appropriate queue ) then why not take advantage of that? |
|
| Back to top |
|
|
|
|
