| Author |
Message
|
| shalabh1976 |
 Posted: Tue Jun 23, 2009 9:13 pm Post subject: Validation Problem with HTTPInput |
 |
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Hi,
I am using WMB 6.1.0.3 on Windows.
My main flow is HTTPInput-->Compute-->HTTPReply
I have the input message format as XML, I have a XSD for this. I have imported and created a message set using this XSD. The input is validated against this XSD in the HTTPInput node.
To test this flow, I have a dummy flow MQInput-->HTTPRequest-->MQOutput.
Now When I put a valid XML file in my MQInput queue it reches the main flow, is proccessed and a Reply sent back.
When I put an invalid XML file in my MQInput it is rejected by the HTTPInput node (as expected).
One of the testers then tried to invoke the main flow using IE.
They typed http://localhost:7800/svc/flow and sent a blank message.
Ideally this message should be stopped by the HTTPInput as it cannot be validated against the XSD. However the HTTPInput Node allows this message to go through. Input message in debugger only has HTTP Header with no Body.
Shouldn't HTTPInput stop such a message?
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
 |
| kimbert |
| Posted: Wed Jun 24, 2009 3:58 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Please take a user trace and look carefully at the output. Post again if you still have questions. |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Thu Jun 25, 2009 1:08 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
I have captured a user trace and please see the initial lines from the trace:
| Quote: |
2009-06-25 14:28:46.249683 8360 UserTrace BIP4040I: The Execution Group ''default'' has processed a configuration message successfully.
A configuration message has been processed successfully. Any configuration changes have been made and stored persistently.
No user action required.
2009-06-25 14:28:46.250194 8360 UserTrace BIP2638I: The MQ output node 'ConfigurationMessageFlow.outputNode' attempted to write a message to queue ''SYSTEM.BROKER.EXECUTIONGROUP.REPLY'' connected to queue manager ''WBRK61_DEFAULT_QUEUE_MANAGER''. The MQCC was '0' and the MQRC was '0'.
2009-06-25 14:28:46.250225 8360 UserTrace BIP2622I: Message successfully output by output node 'ConfigurationMessageFlow.outputNode' to queue ''SYSTEM.BROKER.EXECUTIONGROUP.REPLY'' on queue manager ''WBRK61_DEFAULT_QUEUE_MANAGER''.
2009-06-25 14:28:46.250465 8360 Information BIP2154I: Execution group finished with Configuration message.
A command response will be sent to the broker.
No user action required.
2009-06-25 14:29:12.337489 1832 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'RefundValidation.RefundValidation_HTTP Input' to handle portion of incoming message of length 364 bytes beginning at offset '0'.
2009-06-25 14:29:12.337602 1832 UserTrace BIP6061I: Parser type ''HTTPInputHeader'' created on behalf of node 'RefundValidation.RefundValidation_HTTP Input' to handle portion of incoming message of length '734' bytes beginning at offset '364'. Parser type selected based on value ''WSINPHDR'' from previous parser.
2009-06-25 14:29:12.337627 1832 UserTrace BIP3122I: Message received and propagated to 'out' terminal of HTTP input node 'RefundValidation.RefundValidation_HTTP Input'.
2009-06-25 14:29:12.337649 1832 UserTrace BIP4163I: Message propagated to the first terminal of the FlowOrder node 'RefundValidation.LogFirst_FlowOrder'.
The FlowOrder node has received a message and has propagated it to the output terminal called first. Once the processing of the message down the first terminal has finished, the message will be propagated to the second terminal.
|
The trace only confirms that a blank input message is passing through from IE something which should not be happening.
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jun 25, 2009 1:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| I don't see any body parser being invoked. There is a very basic and important point that you are missing. If you leave Parse Timing set to its default value of 'On demand' then a trivial message flow will *never* trigger any parsing of the message body. Your other mistake is to ask for help with a parsing problem without telling us which domain you are using. |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Thu Jun 25, 2009 2:37 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
I did mention "The input is validated against this XSD in the HTTPInput node."
But to expand - the Input message is validated against a Message Set in the input where the message domain is MRM, message set is <MSET NAME>, message type is <MTYPE>, message format is XML1.
Parse timing is Complete.
Even with the Parse timing as Immediate the results are the same.
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jun 25, 2009 3:17 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Fair enough - thanks for clarifying that.
But my point still stands. The MRM parser is never being invoked here because there is nothing to be parsed. So if any parser is going to complain, it will have to be the HTTP root parser ( the one which kicks off the parsing of the headers ). But there's no way of making that parser complain about an empty body.
If you think that the HTTPInput node is missing a trick you could raise a requirement via your IBM rep. Otherwise, I think you'll have to put in some ESQL/Java to check whether there's a valid body. |
|
| Back to top |
|
|
|
|
