Hi Jens,

I think you're right, if you need this to work on a single port, you are
probably looking at implementing a custom MinLLPReader. I don't think this
would be terribly hard: The existing one wraps the InputStream with a Reader
object that reads in using the predefined charset. Presumably you could keep
a copy of the InputStream around, wait for a "\r" to come along to mark the
end of the MSH segment, parse the string so far for the MSH, and then
re-wrap the InputStream with the appropriate Reader for the rest of the
message. Just thinking out loud, I'm sure there are lots of other ways to do
this too.

If you do end up implementing this and want to contribute it back to HAPI,
I'm sure you'd be making a lot of people happy. :)

Cheers,
James


On Thu, Oct 6, 2011 at 3:43 AM, Jens Kristian Villadsen <[email protected]> wrote:

> Hi Eric, and thx for the link
>
> I have looked at your code, and it seems to me that we happen to share some
> thoughts regarding the design. However it seems to me that the way you have
> come across the problem is by having multiple instances of the SimpleServer
> and allocate a separate port pr. SimpleServer. I know this is a perfectly
> valid approach, it does however not entirely solve the problem as one of my
> requirements states that I should only use a single port.
>
> So far my current suggestion is to make an extension/reimplement the
> MinLLPReader<http://hl7api.sourceforge.net/apidocs/ca/uhn/hl7v2/llp/MinLLPReader.html>that
>  dynamically reads the encoding of the current message and then
> deserialize it properly, according to the encoding provided in the MSH-18.
>
>
> 2011/10/5 Eric Poiseau <[email protected]>
>
>> Jens
>>
>> we are using HAPI in the development of the IHE Simulators used by the
>> Gazelle project. Thanks to HAPI our life is also much easier.
>> I think we have found a solution for what you are reporting here.
>>
>> Our simulators need to be able to send and receive messages using
>> different character encoding. For instance you can see it in the following
>> simulators :
>>
>>
>>    - Patient Administration Management (PAM) Profile 
>> Simulator<http://gazelle.ihe.net/PAMSimulator>
>>    - Laboratory Barcode Labeling (LBL) Profile 
>> Simulator<http://gazelle.ihe.net/LBLSimulator>
>>    - Laboratory Code Set Distribution (LCSD) Profile 
>> Simulator<http://gazelle.ihe.net/LCSDSimulator>
>>
>>
>> All the simulators use a common module that implement what you need. You
>> can look at our sources there :
>>
>>
>> https://gforge.inria.fr/scm/viewvc.php/Maven/simulators/HL7Common/trunk/HL7Common-ejb/src/main/java/net/ihe/gazelle/HL7Common/responder/?root=gazelle
>>
>> Please let us know if you need further help. But I guess the code should
>> be self explainable
>>
>> Best regards
>>
>> Eric
>>
>>
>>
>> Le 5 oct. 2011 à 13:48, Jens Kristian Villadsen a écrit :
>>
>> Hi All
>>
>> Initial, I would like to thank James and all the other guys behind the
>> HAPI framework - that's solid work, guys, solid work! It has made my life a
>> h**l lot easier.
>>
>> However I would like to get some input/solutions/suggestions to the
>> following problem:
>>
>> I'm about to write an HL7 application that has to support incoming
>> messages encoded in various different formats, e.g. an ADT_A04 being encoded
>> in UT8 (MSH-18) and the same kind of message encoded in, lets say
>> ISO-8859-1. As far as I can see, using the SimpleServer, this is not
>> possible, as the SimpleServer is using LowerLayerProtocol which is using
>> MinLLPReader which uses the static CHARSET_KEY for decoding which means that
>> all received messages will be decoded with the same encoding, even though
>> they are encoded differently. So what is the solution to this?
>>
>> To manually convert all fields that I'm reading from the message dependant
>> of what is stated in the MSH-18 for each message?
>>
>> --
>> Med venlig hilsen / Kind regards
>>
>> Jens Kristian Villadsen
>> cand.polyt
>> Systemudvikler / System developer
>> Cetrea A/S, Denmark
>>
>>    phone : +45 38 40 05 81
>>    address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
>>    e-mail : [email protected]
>>    w^3     : http://www.cetrea.com/
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>>
>> http://p.sf.net/sfu/splunk-d2dcopy1_______________________________________________
>> Hl7api-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>>
>> Eric Poiseau
>> IHE Europe Technical Project Manager
>> Responsable du Projet IHE-Development
>> INRIA Rennes
>> Campus Universitaire de Beaulieu
>> F-35042 Rennes Cedex FRANCE
>> Tel: +33 2 99 84 74 58
>> Cell : +33 6 85 97 01 26
>> Fax: +33 2 99 84 71 71
>> Mail: [email protected]
>> Mail: [email protected]
>> http://www.ihe-europe.net
>>
>>
>>
>>
>>
>>
>
>
> --
> Med venlig hilsen / Kind regards
>
> Jens Kristian Villadsen
> cand.polyt
> Systemudvikler / System developer
> Cetrea A/S, Denmark
>
>    phone : +45 38 40 05 81
>    address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
>    e-mail : [email protected]
>    w^3     : http://www.cetrea.com/
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Hl7api-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Hl7api-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

Reply via email to