Thanks a lot, Christian, that's pretty much what I did - my malformed messages had broken MSH, so I got some inspiration from an old Mirth code and came up with some regex parser that tries to extract as much info as possible from the MSH, and uses "default" values where headers from the incoming message cannot be retrieved. Then the info is used to construct the custom NAK.
-- Eugene Berman Sr. Enterprise Solutions Architect ---- MuleSoft Inc. 77 Geary Street, Ste. 400 San Francisco, CA 94108 Office: 415 229 2063 Website: http://www.mulesoft.com <http://www.mulesoft.com/> --- Entia non sunt multiplicanda praeter necessitatem! On Jun 11, 2013, at 1:31 PM, Christian Ohr <christian....@gmail.com> wrote: > Hi Eugene, > > It certainly depends on how malformed the message is. If you are able to > parse out minimal data required for a qualified response (i.e. the MSH > segment is somehow valid), you have Parser#getMinimalResponseData that > returns a MSH segment that can be used for your response. If you are using > HAPI 2.1, you might also want to have a look at > RespondingValidationExceptionHandler#generateResponseMessage, where the above > mentioned Parser method is used. > > Although this is certainly not perfect, it provides a good starting point, > though. > If your request is complete "garbage", you probably have to "invent" some > generic NAK. > > cheers > Christian > > > > 2013/6/11 Eugene Berman <eugene.ber...@mulesoft.com> > One of the use cases that I need to deal with is to return a NACK in response > to malformed messages. For example, if I send an XML message that cannot be > parsed by the HAPI parser, the exception will be thrown, but then I need to > generate a NACK and return it to the client. My question is, how can I > generate the NACK if the inbound message cannot be parsed? Normally I would > call generateACK() method and populate ERR segments, but if I don't have an > incoming message as a HAPI object, I cannot call the generateACK method. Is > there any way to create a "default" NACK? > > -- > Eugene Berman > Sr. Enterprise Solutions Architect > ---- > MuleSoft Inc. > 77 Geary Street, Ste. 400 > San Francisco, CA 94108 > Office: 415 229 2063 > Website: http://www.mulesoft.com <http://www.mulesoft.com/> > --- > Entia non sunt multiplicanda praeter necessitatem! > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Hl7api-devel mailing list > Hl7api-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Hl7api-devel mailing list Hl7api-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hl7api-devel
