Guys, thanks a lot for all the info! I did make some progress yesterday, my component now takes message and exceptions, checks if the version is 2.5 or greater (it seems the repetitive ERRs were not allowed prior to 2.5) and uses reflection to get the getERR method and invoke it to get the segment and then call exception.populate(). My next step would be to design a configuration element for error mapping. I wish there was one set of data model interfaces implemented by all model classes. I understand that standards are different, but imho the way around it would be to throw MethodNotImplementedException if standard does not support certain operation. E.g. if generic model ACK had getERR(int) method, and the actual message was of version 2.5 or higher, it would return the ERR segment, but if the actual message had version 2.3, I would get an exception. Just my 2c.
On Oct 23, 2012, at 6:43 PM, James Agnew <[email protected]> wrote: > Yikes, thanks Tom for correcting me! You definitely have this right and I was > backwards. I will mention that the reason I have it backwards is that one of > the systems we deal with regularly at UHN also gets it backwards.. Which > brings me to my reply to Eugene: What you propose sounds sensible. > Flexibility is key for this kind of thing, since you never know what wacky > thing the other person is going to be doing. :) > > Cheers, > James > > On Mon, Oct 22, 2012 at 1:38 PM, <[email protected]> wrote: > Hi James, > I'd like to clarify for my own understanding - I normally consider AE and AR > to be reversed from the way you describe. The way I think of it 'AR' means > "Resend" as in message may be OK but something else went wrong. From HL7 2.5 > chapter 2: > > 2.9.2.2 Accept and validate/process the message in the receiving application > Upon successful validation by the responding system, the message is passed to > the receiving application, > which performs one of these functions: > a) process the message successfully, generating the functional response > message with a value of AA in > MSA-1-acknowledgment code. > b) send an error response, providing error information in functional segments > to be included in the > response message with a value of AE in MSA-1-acknowledgment code. > c) fail to process (reject) the message for reasons unrelated to its content > or format (system down, > internal error, etc.). For most such problems it is likely that the > responding system will be able to > accept the same message at a later time. The implementers must decide on an > application-specific > basis whether the message should be automatically sent again. The response > message contains a > value of AR in MSA-1-acknowledgment code. > > > Cheers and thanks for a great product! > > Tom Bonavia > > > > NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, > you are prohibited from sharing, copying, or otherwise using or disclosing > its contents. If you have received this e-mail in error, please notify the > sender immediately by reply e-mail and permanently delete this e-mail and any > attachments without reading, forwarding or saving them. Thank you. > > > > > From: James Agnew <[email protected]> > To: Eugene Berman <[email protected]> > Cc: "[email protected]" > <[email protected]> > Date: 10/22/2012 10:58 AM > Subject: Re: [HAPI-devel] HL7 Error Handling and ACK > > > > Hi Eugene, > > Re. multiple errors: > The HL7 "ACK" message type actually allows you to specify the details of more > than one error in your response, using the repeatable ERR segment. The > generateAck(String, HL7Exception) method only populates the first one, since > this is a common use case, but there is nothing stopping you from grabbing > multiple reps and populating each one with the details. > E.g. > firstException.populate(ackMessage.getERR(0), null); > secondException.populate(ackMessage.getERR(1), null); > // etc.... > > Really, we should probably have a varargs (HL7Exception...) version of the > generateAck method. I've filed an enhancement request to that effect. I think > it would make sense.. > > Re. non-HL7 errors: > This is generally handled by using specific acknowledgement codes. I don't > have HL7 chapter 2 handy right now, so I'll paraphrase a bit, but this is how > the ACK code is generally used: > AA - Message was successfully processed > AR - Message was not successful because of an issue with the message (bad > contents, etc.) > AE - Message was not successful because of an issue with the server > (unexplained exceptions, IO errors, etc.) > > This is only a guideline though. Every sending system will have it's own > interpretation of how these ack codes should be interpreted, so in the end > your best bet is to be flexible and let things be configured by specific > implementations. > > Cheers, > James > > On Fri, Oct 19, 2012 at 10:14 AM, Eugene Berman <[email protected]> > wrote: > I'm very new to HAPI, so sorry for the stupid questions :) > I'm trying to figure out what is the best way to generate ACK message in case > I have multiple processing errors. E.g. I receive a message and then > validation fails, producing multiple errors. The generateACK() method only > accepts one HL7Exception as a parameter, so how do I handle the situation > when there are multiple errors? Or should I just pick the first one? > > Also, what is the best way to handle the non-HL7 error - e.g. general system > error which is not related to any HL7-specific problem? > > Thanks a lot, > > Eugene > > -- > Eugene Berman > Sr. Enterprise Solutions Engineer > ---- > 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! > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Hl7api-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________ > Hl7api-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > -- Eugene Berman Sr. Enterprise Solutions Engineer ---- 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! ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Hl7api-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hl7api-devel
