| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Modeling |
« View previous topic :: View next topic » |
| Author |
Message
|
| SpitFire |
 Posted: Fri Apr 07, 2006 4:04 am Post subject: Message Modeling |
 |
|
Acolyte
Joined: 01 Aug 2005
Posts: 59
Location: India
|
Hi all,
I have a scenario in which the message flow picks up an XML(self-defining or MRM.XML) message, and then does thorough validation on the incoming data and then routes it some other destination for processing. The issue I'm facing is that the flow can receive upto 93 msgs. The structure of the msgs are more or less the same. The difference in the msgs are based on the value of a particular field viz., action or messageid(basically, either a string description or a number). Depending upon the value extra fields may appear/disappear in the message structure. For example, look at the following two sample msgs...
---* Sample Message: #1 *---
--------------------------------------------------
<msgs>
<action>ALERT</action>
...
<alertMsg>... General Warning ...</alertMsg>
...
</msgs>
--------------------------------------------------
---* Sample Message: #2 *---
--------------------------------------------------
<msgs>
<action>ALERT_RESPONSE</action>
...
<fault>
<code>FAULT-#1</code>
<reason>FALSE ALARM</reason>
</fault>
...
</msgs>
--------------------------------------------------
In the example shown above, the msgs are differentiated only based on the value of the 'action' element. And after classifying the same, I ahve to do content based validation on the msgs viz., ensure for msgs of type 'ALERT_RESPONSE', fault->code is set.
How do I begin modeling for such a scenario?
Should I develop individual msgs for each such msg, though their structures would more or less be the same? In that case, the validation becomes easier. However, I would end up wasting time defining same elements repeatedly for each of the msgs. On the other hand, if in case I choose to develop a single message pattern, how do I set and validate the conditions for checking the message payload later?
_________________
...: 5|71+ph1|23 :... |
|
| Back to top |
|
 |
| thomeck |
| Posted: Fri Apr 07, 2006 5:32 am Post subject: |
|
|
Apprentice
Joined: 07 Apr 2006
Posts: 30
Location: Germany
|
Hi,
I think you have to define a DTD for your xml like
<!DOCTYPE msgs[
<!ELEMENT msgs(action, alertMsg, fault)>
<!ELEMENT action (#PCDATA)>
<!ELEMENT alertMsg (#PCDATA)>
<!ELEMENT fault(code, reason)>
<!ELEMENT code (#PCDATA)>
<!ELEMENT reason (#PCDATA)>
]>
This DTD must include all possible attributes. But be sure that it is not well-formed if an attribute is not in your xml data.
I had test it with ICS it works. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Apr 07, 2006 6:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Should I develop individual msgs for each such msg |
It depends. Your validation requirements are outside of what XML Schema allows. There are products out there which do this kind of cross-field validation, but the current version of the broker does not support it. I think you have two choices:
a) Implement a two-stage message flow in which you inspect InputRoot.XML.msgs and then re-parse and validate ( using an RCD node) using message definition N ( where N is between 0 and 92 ).
b) Skip schema validation entirely. Code the validation rules in ESQL and just take the maintenance hit.
If you want higher performance, option a) could be done within a single Compute node using CREATE FIELD...PARSE to do the reparsing and validation.
Which option you take depends on how many validation rules there are, and whether you can summarise them in some efficient and maintainable ESQL. |
|
| Back to top |
|
|
| SpitFire |
| Posted: Tue Apr 11, 2006 2:13 am Post subject: |
|
|
Acolyte
Joined: 01 Aug 2005
Posts: 59
Location: India
|
Hi thomeck,
Thanks for the response. However, I guess your solution won't work in my case.
IMHO, DTD's are used to model XML instances and are too document oriented, in the sense they can't possible be used to define data-types of the elements or impose restrictions on the range of values that the elements can handle.
"...XML Schemas provide data-oriented data types in addition to the more document-oriented data types XML DTDs support..." - http://www.techinterviews.com/?p=203
I think, I need to use only an xml schema and then import the same into the broker to generate the msg-sets.
_________________
...: 5|71+ph1|23 :... |
|
| Back to top |
|
|
| SpitFire |
| Posted: Tue Apr 11, 2006 2:15 am Post subject: |
|
|
Acolyte
Joined: 01 Aug 2005
Posts: 59
Location: India
|
| kimbert wrote: |
I think you have two choices:
a) Implement a two-stage message flow in which you inspect InputRoot.XML.msgs and then re-parse and validate ( using an RCD node) using message definition N ( where N is between 0 and 92 ).
b) Skip schema validation entirely. Code the validation rules in ESQL and just take the maintenance hit.
|
I'm taking the first one. And, thanks for the information.
_________________
...: 5|71+ph1|23 :... |
|
| 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
|
|
|
|
