MQSeries.net :: View topic - Causing a full parse in ESQl that is the same as the MQINPUT

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Causing a full parse in ESQl that is the same as the MQINPUT

Causing a full parse in ESQl that is the same as the MQINPUT

« View previous topic :: View next topic »

Author

Message

bbakerman

Posted: Tue Aug 30, 2005 6:18 pm Post subject: Causing a full parse in ESQl that is the same as the MQINPUT

Apprentice

Joined: 17 Dec 2003
Posts: 41

I have a project processing requirement that "invalid messages" that fail parsing be set aside but that all other exceptions result in a constant re-try within the flow.

I have approached this by creating a message flow that reads its data as a BLOB with no validation, it then goes down a 2 prong flow order node where one line causea a full parse and then the other does the processing. I set some state in the Environment to say whether the parse completed.

If I get an exception during the parse, I set the message aside. Something like this
|--- on exception set aside
|
MQinput -- Flow Order -- TryCatch - RCD - Compute (cause full parse)
|
|--- Compute (check parse result in environment)
|
|-- RCD
|
|-- Do actual processing

My full parse consists of visiting every node in the MRM tree. The Compute node has full validation turned on.

HOWEVER I dont get the same behaviour using this approach as I do if I wire the MQInpout node with validation=ContentValue and Timing=Immediate.

Sometimes invalid message sneak through the parser which are caught via the validated MQINPUT approach.

As I stated earlier the reason I dont use the validated MQInput node is becaue I want to be able to "differentiate" my "bad parser" exception handling from other type of exceptions (where I want to default backout behaviour to occur)

Can some one please outline a better approach to

* Cause a full "real" parse from within ESQL?

* Catching "badly" parsed messages as opposed to the flow exceptions?

kimbert

Posted: Wed Aug 31, 2005 12:30 am Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Hi bbakerman,

Quote:

My full parse consists of visiting every node in the MRM tree. The Compute node has full validation turned on.

If the Compute node validation settings are as described, they should trigger a full parse anyway.

Quote:

Sometimes invalid message sneak through the parser

I'd like to know more about this. The MRM parsers don't care whether they were called by an MQInput node or a Compute node, so maybe there's something else going on. Can you give an example of an invalid message which 'sneaks through'.

bbakerman

Posted: Wed Aug 31, 2005 5:47 pm Post subject:

Apprentice

Joined: 17 Dec 2003
Posts: 41

Yeah strange behaviour indeed. It would appear that the parser is acting different depending on whether I am running under the ESQL debugger
or not.

I am on WBI 5 CSD 6 on Windows.

For example I have a TDS defined message set for HL7 messages. The
data looks like this

MSH|^~\&|CERNER|SWSAHS|DATAGATE|DATAGATE|20050117112823||ADT^A04|Q29639231T31990013X558507||2.3
EVN|A04|20050117112700|||^Kuskoff^Alex^^^^^^^CD:299294
PID|1|954625^^^LIVMRN^MRN|1051806^^^BNKMRN^MRN~422756^^^SWSAHS^CMRN~954625^^^LIVMRN^MRN~733193^^^FRFMRN^MRN||XYZ^Emergency^^^Mr^^CD:766||19881010000000|M||50|1 Smith St^^RYDE^NSW^2112^Australia^CD:756~1^^ryde^NSW^2112^Australia^CD:757||345345345^CD:170|(444)444-3454^CD:163|90|2||553990^^^CD:297030^CD:1077|1231231231||||||0|CD:493039||5202
ZPI|1|||||||304329^Tadros^Victor^S
ZEI|1
PV1|1|E|Emergency^^^LIVERPOOLHEALT^^CD:772^Liverpool OPD|||||||||||06||||E|1106644^0^^^CD:1081|ON|||||||||||||||||||LIVERPOOLHEALT||A|||20050117112700
PV2||||||||||0|||||||||||||^^294883
ZVI|||||||||CD:297144
OBX|1|ST|COMPEN CLAIM||Yes
GT1|1|1051806|XYZ^Emergency^^^Mr^^CD:766||1 Smith St^^RYDE^NSW^2112^Australia^CD:756|345345345|(444)444-3454|19881010000000|M|CD:1150|1|1231231231
ACC|20050117000000|CD:297182|||CD:299975
ZAC|car accident
ZQA|1|294862

When I am running under the debugger, I dont always get an immediate parser validation but I get strange entries in the logical message tree like
...
...
->parseNext failed

The tree might look like this

Message
MSH
...
...
EVN
...
...
PID
...
...
etc..then wacko
ZPI|1|||||||304329^Tadros^Victor^S

I tracked this down to me message set being wrong (eg not containing a ZPI segement defintiion) but I would have hoped that when I did the RCD followed by a compute node with full validation this would have been picked up and an exception thrown.

But it seems under the ESQL debugger I get slightly different behaviour than without it.

In the end I checked my design to use the MQINPUT failure terminal.

I now use the MRM and message name in the MQINPUT and have the failure terminal wired.

I theen have a compute node after that which checks the ExceptionList and dtermines with it has ParserExceptions in it versus other types.

I what to set adide parse exceptions but I want to "back out" all others.

So in my compute node if I detect if the ExceptionList entries have the name 'ParserException' and take the appropriate set aside action whilst throwing a user exception for evything else.

This has the effect of backig out the message for everything but parser exceptions.

I didnt go down this path because in the old 2.1 days you couldnt get this behaviour to work (somehting like the ExceptionList didnt have enough explcit information it) but that seems to have been addressed.

Thanks for your reply.

Display posts from previous:

Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Causing a full parse in ESQl that is the same as the MQINPUT

Jump to:

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

Protected by Anti-Spam ACP