From: Steve P. <st...@pr...> - 2006-01-05 19:47:02
|
I'm getting HL7 messages from a client that have non-default separators. How can I set the parser to use the appropriate separators? It looks like the EncodingCharacters class might be useful, but it's not clear how to tie the EncodingCharacters object to a *Parser object, such as PipeParser. thanks, Steve Pringle |
From: Bryan T. <bp...@gm...> - 2006-01-05 20:57:06
|
Hi Steve, The parser should do this automatically, as long as they are declared correctly in MSH-1 and MSH-2. Bryan On 1/5/06, Steve Pringle <st...@pr...> wrote: > I'm getting HL7 messages from a client that have non-default separators. > How can I set the parser to use the appropriate separators? > > It looks like the EncodingCharacters class might be useful, but it's not > clear how to tie the EncodingCharacters object to a *Parser object, such = as > PipeParser. > > thanks, > Steve Pringle |
From: Steve P. <st...@pr...> - 2006-01-05 22:17:48
|
Indeed it does! Very exciting! =20 Next I'm going to try to register an application with a SimpleServer and send messages to the SimpleServer via the TestPanel. Thanks, Steve > -----Original Message----- > From: hl7...@li...=20 > [mailto:hl7...@li...] On Behalf=20 > Of Bryan Tripp > Sent: Thursday, January 05, 2006 12:57 PM > To: spr...@po... > Cc: hl7...@li... > Subject: Re: [HAPI-devel] How to change default encoding=20 > characters (separators)? >=20 >=20 > Hi Steve, >=20 > The parser should do this automatically, as long as they are=20 > declared correctly in MSH-1 and MSH-2. >=20 > Bryan >=20 > On 1/5/06, Steve Pringle <st...@pr...> wrote: > > I'm getting HL7 messages from a client that have non-default=20 > > separators. How can I set the parser to use the appropriate=20 > > separators? > > > > It looks like the EncodingCharacters class might be useful,=20 > but it's=20 > > not clear how to tie the EncodingCharacters object to a *Parser=20 > > object, such as PipeParser. > > > > thanks, > > Steve Pringle >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files for problems? Stop! Download the new AJAX=20 > search engine that makes searching your log files as easy as=20 > surfing the web. DOWNLOAD SPLUNK!=20 > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > Hl7api-devel mailing list > Hl7...@li... > https://lists.sourceforge.net/lists/listinfo/hl7api-devel >=20 >=20 |
From: Steve P. <st...@pr...> - 2006-01-09 07:27:16
|
Could someone please tell me how one goes about determining what type of message has been received in the Application.processMessage(Message in) method? Here's a code snippet, which is being sent an ADT_A01 msg, but I have no idea how to determine that it is an ADT_A01. All I want to do is determine which message type was sent, get the data I need, then send an ACK. public class ABApplication implements Application { ... public Message processMessage(Message in) throws ApplicationException { Message out = null; PipeParser parser = new PipeParser(); try { System.out.println("\nmsg Name: " + in.getName()); System.out.println("\nmsg Name: " + in.getClass().getName()); System.out.println("\nmsg Version: " + in.getVersion()); System.out.println("\nmsg ?: " + in.get("MSH").getName()); String[] names = in.getNames(); for (int i = 0; i < names.length; i++) System.out.println("** " + names[i]); ... Here's the output: msg Name: GenericMessage$V22 msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 msg Version: 2.2 msg ?: MSH ** MSH ** EVN ** PID ** NK1 ** PV1 Thanks, Steve PRingle |
From: Bryan T. <bp...@gm...> - 2006-01-10 21:26:46
|
Hi Steve, The message type, event, and possibly structure should be in field MSH-9. Actually if they are there, HAPI should not use the GenericMessage class, and you should be able to tell what kind of message it is from the class. Maybe these data are missing from the message? Bryan On 1/9/06, Steve Pringle <st...@pr...> wrote: > Could someone please tell me how one goes about determining what type of > message has been received in the Application.processMessage(Message in) > method? > > Here's a code snippet, which is being sent an ADT_A01 msg, but I have no > idea how to determine that it is an ADT_A01. All I want to do is determi= ne > which message type was sent, get the data I need, then send an ACK. > > public class ABApplication implements Application > { > ... > public Message processMessage(Message in) throws ApplicationException > { > Message out =3D null; > PipeParser parser =3D new PipeParser(); > > try > { > System.out.println("\nmsg Name: " + in.getName()); > System.out.println("\nmsg Name: " + > in.getClass().getName()); > System.out.println("\nmsg Version: " + > in.getVersion()); > System.out.println("\nmsg ?: " + > in.get("MSH").getName()); > > String[] names =3D in.getNames(); > > for (int i =3D 0; i < names.length; i++) > System.out.println("** " + names[i]); > ... > > Here's the output: > > msg Name: GenericMessage$V22 > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > msg Version: 2.2 > > msg ?: MSH > ** MSH > ** EVN > ** PID > ** NK1 > ** PV1 > > Thanks, > Steve PRingle > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Hl7api-devel mailing list > Hl7...@li... > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > |
From: Steve P. <st...@pr...> - 2006-01-10 22:00:02
|
It looks like the MSH I have does not meet the HL7 2.2 specs? The = message type is in MSH-9, but there's also an int (43) in MSH-9-3... Here's the ADT A04 sample msg I have (header only): =20 MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04;43:9007713:P:2.2:9007713::AL= :"" : ^ ^ As I understand it, field MSH-9 is a msg type, "Components: <message = type> ^ <trigger event>", but the msg type sent is "ADT;A04;43", which is incorrect according to the standards? In addition, there's an extra = field after the msg type, it's either "43" or "9007713" (depending on how the segment is parsed), before the processing ID (P). But it seems 9007713 = is the sequence #, so why two of them? =20 9 7 CM R 0076 00009 Message type=20 10 20 ST R 00010 Message control ID=20 11 1 ID R 0103 00011 Processing ID=20 12 8 ID R 0104 00012 Version ID Any suggestions on how to deal with this? It seems a good approach to handling messages in my Application class, when a message is sent via = the "processMessage(Message in)" method, is to simply do an "instance of" on = the msg to determine it's type, then process the msg accordingly. But with these msgs I'm being sent "instanceof" fails, due to the MSH-9-3 field = being present. If I remove the MSH-9-3 field it parses properly, as an = ADT_A04. Here's output from parsing the original msg: msg Name: GenericMessage$V22 =20 msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 =20 msg Version: 2.2 =20 msg ?: MSH ** MSH-9-1 is: ADT ** MSH-9-2 is: A04 ** MSH-9-3 is: 43 ** MSH-10 is: 9007713 ** MSH-11 is: P ** MSH-12 is: 2.2 ** MSH-13 is: 9007713 ** MSH-14 is: null ** MSH ** EVN ca.uhn.hl7v2.HL7Exception: Can't XML-encode a GenericMessage. Message = must have a recognized structure. at ca.uhn.hl7v2.parser.XMLParser.doEncode(XMLParser.java:251) at ca.uhn.hl7v2.parser.Parser.encode(Parser.java:221) at ABParse.main(ABParse.java:79) And here's output from parsing the modified msg (MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04:43:P:2.2:9007713::AL:"":) msg Name: ADT_A04 =20 msg Name: ca.uhn.hl7v2.model.v22.message.ADT_A04 =20 msg Version: 2.2 =20 msg ?: MSH ** MSH-9-1 is: ADT ** MSH-9-2 is: A04 ** MSH-9-3 is: null ** MSH-10 is: 43 ** MSH-11 is: P ** MSH-12 is: 2.2 ** MSH-13 is: 9007713 ** MSH-14 is: null ** MSH ** EVN ** PID ** NK1 ** PV1 ** PV2 ** OBX ** AL1 ** DG1 ** PR1 ** GT1 ** INSURANCE ** ACC ** UB1 ** UB2 message is instanceof ADT_A04 <?xml version=3D"1.0"?> <ADT_A04 xmlns=3D"urn:hl7-org:v2xml"> <MSH> <MSH.1>:</MSH.1> <MSH.2>;~\&</MSH.2> <MSH.3>HBOC</MSH.3> <MSH.4>A</MSH.4> <MSH.5>HBOC</MSH.5> <MSH.6>A</MSH.6> <MSH.7> <TS.1>200512152351</TS.1> </MSH.7> <MSH.9> <CM_MSG.1>ADT</CM_MSG.1> <CM_MSG.2>A04</CM_MSG.2> </MSH.9> <MSH.10>43</MSH.10> <MSH.11>P</MSH.11> <MSH.12>2.2</MSH.12> <MSH.13>9007713</MSH.13> <MSH.15>AL</MSH.15> <MSH.16>""</MSH.16> </MSH> <EVN> <EVN.1>A04</EVN.1> <EVN.2> <TS.1>200512152351</TS.1> </EVN.2> </EVN> </ADT_A04> =20 > -----Original Message----- > From: hl7...@li...=20 > [mailto:hl7...@li...] On Behalf=20 > Of Bryan Tripp > Sent: Tuesday, January 10, 2006 1:27 PM > To: spr...@po... > Cc: hl7...@li... > Subject: Re: [HAPI-devel] Detemining the Message type in=20 > Application.processMessage(...) >=20 >=20 > Hi Steve, >=20 > The message type, event, and possibly structure should be in=20 > field MSH-9. Actually if they are there, HAPI should not use=20 > the GenericMessage class, and you should be able to tell what=20 > kind of message it is from the class. Maybe these data are=20 > missing from the message? >=20 > Bryan >=20 > On 1/9/06, Steve Pringle <st...@pr...> wrote: > > Could someone please tell me how one goes about determining=20 > what type=20 > > of message has been received in the=20 > Application.processMessage(Message=20 > > in) method? > > > > Here's a code snippet, which is being sent an ADT_A01 msg,=20 > but I have=20 > > no idea how to determine that it is an ADT_A01. All I want=20 > to do is=20 > > determine which message type was sent, get the data I need,=20 > then send=20 > > an ACK. > > > > public class ABApplication implements Application > > { > > ... > > public Message processMessage(Message in) throws=20 > ApplicationException > > { > > Message out =3D null; > > PipeParser parser =3D new PipeParser(); > > > > try > > { > > System.out.println("\nmsg Name: " +=20 > in.getName()); > > System.out.println("\nmsg Name: " +=20 > > in.getClass().getName()); > > System.out.println("\nmsg Version: " +=20 > > in.getVersion()); > > System.out.println("\nmsg ?: " +=20 > > in.get("MSH").getName()); > > > > String[] names =3D in.getNames(); > > > > for (int i =3D 0; i < names.length; i++) > > System.out.println("** " +=20 > names[i]);=20 > > ... > > > > Here's the output: > > > > msg Name: GenericMessage$V22 > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > msg Version: 2.2 > > > > msg ?: MSH > > ** MSH > > ** EVN > > ** PID > > ** NK1 > > ** PV1 > > > > Thanks, > > Steve PRingle > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log=20 > > files for problems? Stop! Download the new AJAX search=20 > engine that=20 > > makes searching your log files as easy as surfing the web.=20 > DOWNLOAD=20 > > SPLUNK! = http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > _______________________________________________ > > Hl7api-devel mailing list > > Hl7...@li... > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files for problems? Stop! Download the new AJAX=20 > search engine that makes searching your log files as easy as=20 > surfing the web. DOWNLOAD SPLUNK!=20 > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > Hl7api-devel mailing list > Hl7...@li... > https://lists.sourceforge.net/lists/listinfo/hl7api-devel >=20 >=20 |
From: Bryan T. <bp...@gm...> - 2006-01-10 22:49:40
|
Yes, that would do it. Righteous ire might work, or if they don't respond well to that, all I can suggest is to hack something in to blank that field before the message is parsed. Let me know if you need pointers there. Bryan On 1/10/06, Steve Pringle <st...@pr...> wrote: > It looks like the MSH I have does not meet the HL7 2.2 specs? The messag= e > type is in MSH-9, but there's also an int (43) in MSH-9-3... > > Here's the ADT A04 sample msg I have (header only): > > MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04;43:9007713:P:2.2:9007713::AL= :"" > : > ^ > ^ > As I understand it, field MSH-9 is a msg type, "Components: <message typ= e> > ^ <trigger event>", but the msg type sent is "ADT;A04;43", which is > incorrect according to the standards? In addition, there's an extra fiel= d > after the msg type, it's either "43" or "9007713" (depending on how the > segment is parsed), before the processing ID (P). But it seems 9007713 i= s > the sequence #, so why two of them? > > 9 7 CM R 0076 00009 Message type > 10 20 ST R 00010 Message control ID > 11 1 ID R 0103 00011 Processing ID > 12 8 ID R 0104 00012 Version ID > > Any suggestions on how to deal with this? It seems a good approach to > handling messages in my Application class, when a message is sent via the > "processMessage(Message in)" method, is to simply do an "instance of" on = the > msg to determine it's type, then process the msg accordingly. But with > these msgs I'm being sent "instanceof" fails, due to the MSH-9-3 field be= ing > present. If I remove the MSH-9-3 field it parses properly, as an ADT_A04= . > > Here's output from parsing the original msg: > > msg Name: GenericMessage$V22 > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > msg Version: 2.2 > > msg ?: MSH > ** MSH-9-1 is: ADT > ** MSH-9-2 is: A04 > ** MSH-9-3 is: 43 > ** MSH-10 is: 9007713 > ** MSH-11 is: P > ** MSH-12 is: 2.2 > ** MSH-13 is: 9007713 > ** MSH-14 is: null > ** MSH > ** EVN > ca.uhn.hl7v2.HL7Exception: Can't XML-encode a GenericMessage. Message mu= st > have > a recognized structure. > at ca.uhn.hl7v2.parser.XMLParser.doEncode(XMLParser.java:251) > at ca.uhn.hl7v2.parser.Parser.encode(Parser.java:221) > at ABParse.main(ABParse.java:79) > > And here's output from parsing the modified msg > (MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04:43:P:2.2:9007713::AL:"":) > > msg Name: ADT_A04 > > msg Name: ca.uhn.hl7v2.model.v22.message.ADT_A04 > > msg Version: 2.2 > > msg ?: MSH > ** MSH-9-1 is: ADT > ** MSH-9-2 is: A04 > ** MSH-9-3 is: null > ** MSH-10 is: 43 > ** MSH-11 is: P > ** MSH-12 is: 2.2 > ** MSH-13 is: 9007713 > ** MSH-14 is: null > ** MSH > ** EVN > ** PID > ** NK1 > ** PV1 > ** PV2 > ** OBX > ** AL1 > ** DG1 > ** PR1 > ** GT1 > ** INSURANCE > ** ACC > ** UB1 > ** UB2 > message is instanceof ADT_A04 > <?xml version=3D"1.0"?> > <ADT_A04 xmlns=3D"urn:hl7-org:v2xml"> > <MSH> > <MSH.1>:</MSH.1> > <MSH.2>;~\&</MSH.2> > <MSH.3>HBOC</MSH.3> > <MSH.4>A</MSH.4> > <MSH.5>HBOC</MSH.5> > <MSH.6>A</MSH.6> > <MSH.7> > <TS.1>200512152351</TS.1> > </MSH.7> > <MSH.9> > <CM_MSG.1>ADT</CM_MSG.1> > <CM_MSG.2>A04</CM_MSG.2> > </MSH.9> > <MSH.10>43</MSH.10> > <MSH.11>P</MSH.11> > <MSH.12>2.2</MSH.12> > <MSH.13>9007713</MSH.13> > <MSH.15>AL</MSH.15> > <MSH.16>""</MSH.16> > </MSH> > <EVN> > <EVN.1>A04</EVN.1> > <EVN.2> > <TS.1>200512152351</TS.1> > </EVN.2> > </EVN> > </ADT_A04> > > > > > -----Original Message----- > > From: hl7...@li... > > [mailto:hl7...@li...] On Behalf > > Of Bryan Tripp > > Sent: Tuesday, January 10, 2006 1:27 PM > > To: spr...@po... > > Cc: hl7...@li... > > Subject: Re: [HAPI-devel] Detemining the Message type in > > Application.processMessage(...) > > > > > > Hi Steve, > > > > The message type, event, and possibly structure should be in > > field MSH-9. Actually if they are there, HAPI should not use > > the GenericMessage class, and you should be able to tell what > > kind of message it is from the class. Maybe these data are > > missing from the message? > > > > Bryan > > > > On 1/9/06, Steve Pringle <st...@pr...> wrote: > > > Could someone please tell me how one goes about determining > > what type > > > of message has been received in the > > Application.processMessage(Message > > > in) method? > > > > > > Here's a code snippet, which is being sent an ADT_A01 msg, > > but I have > > > no idea how to determine that it is an ADT_A01. All I want > > to do is > > > determine which message type was sent, get the data I need, > > then send > > > an ACK. > > > > > > public class ABApplication implements Application > > > { > > > ... > > > public Message processMessage(Message in) throws > > ApplicationException > > > { > > > Message out =3D null; > > > PipeParser parser =3D new PipeParser(); > > > > > > try > > > { > > > System.out.println("\nmsg Name: " + > > in.getName()); > > > System.out.println("\nmsg Name: " + > > > in.getClass().getName()); > > > System.out.println("\nmsg Version: " + > > > in.getVersion()); > > > System.out.println("\nmsg ?: " + > > > in.get("MSH").getName()); > > > > > > String[] names =3D in.getNames(); > > > > > > for (int i =3D 0; i < names.length; i++) > > > System.out.println("** " + > > names[i]); > > > ... > > > > > > Here's the output: > > > > > > msg Name: GenericMessage$V22 > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > msg Version: 2.2 > > > > > > msg ?: MSH > > > ** MSH > > > ** EVN > > > ** PID > > > ** NK1 > > > ** PV1 > > > > > > Thanks, > > > Steve PRingle > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > through log > > > files for problems? Stop! Download the new AJAX search > > engine that > > > makes searching your log files as easy as surfing the web. > > DOWNLOAD > > > SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > > _______________________________________________ > > > Hl7api-devel mailing list > > > Hl7...@li... > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > through log files for problems? Stop! Download the new AJAX > > search engine that makes searching your log files as easy as > > surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > > _______________________________________________ > > Hl7api-devel mailing list > > Hl7...@li... > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > |
From: Steve P. <st...@pr...> - 2006-01-10 23:16:37
|
Unfortunately righteous ire isn't working in this situation (big = hospital, little software group)... Are you suggesting I modify some HAPI source (Parser, Application, Connection, or) in order to edit the MSH message *before* it gets parsed and sent to Application.processMessage(Message = in)? So yes, pointers would be appreciated! Thanks, Steve > -----Original Message----- > From: hl7...@li...=20 > [mailto:hl7...@li...] On Behalf=20 > Of Bryan Tripp > Sent: Tuesday, January 10, 2006 2:50 PM > To: spr...@po... > Cc: hl7...@li... > Subject: Re: [HAPI-devel] Detemining the Message type in=20 > Application.processMessage(...) >=20 >=20 > Yes, that would do it. Righteous ire might work, or if they=20 > don't respond well to that, all I can suggest is to hack=20 > something in to blank that field before the message is=20 > parsed. Let me know if you need pointers there. >=20 > Bryan >=20 > On 1/10/06, Steve Pringle <st...@pr...> wrote: > > It looks like the MSH I have does not meet the HL7 2.2 specs? The=20 > > message type is in MSH-9, but there's also an int (43) in MSH-9-3... > > > > Here's the ADT A04 sample msg I have (header only): > > > >=20 > MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04;43:9007713:P:2.2:9007713: > > :AL:"" > > : > > =20 > ^ > > ^ > > As I understand it, field MSH-9 is a msg type, =20 > "Components: <message type> > > ^ <trigger event>", but the msg type sent is "ADT;A04;43", which is > > incorrect according to the standards? In addition, there's=20 > an extra field > > after the msg type, it's either "43" or "9007713"=20 > (depending on how the > > segment is parsed), before the processing ID (P). But it=20 > seems 9007713 is > > the sequence #, so why two of them? > > > > 9 7 CM R 0076 00009 Message type > > 10 20 ST R 00010 Message control ID > > 11 1 ID R 0103 00011 Processing ID > > 12 8 ID R 0104 00012 Version ID > > > > Any suggestions on how to deal with this? It seems a good=20 > approach to=20 > > handling messages in my Application class, when a message=20 > is sent via=20 > > the "processMessage(Message in)" method, is to simply do an=20 > "instance=20 > > of" on the msg to determine it's type, then process the msg=20 > > accordingly. But with these msgs I'm being sent=20 > "instanceof" fails,=20 > > due to the MSH-9-3 field being present. If I remove the=20 > MSH-9-3 field=20 > > it parses properly, as an ADT_A04. > > > > Here's output from parsing the original msg: > > > > msg Name: GenericMessage$V22 > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > msg Version: 2.2 > > > > msg ?: MSH > > ** MSH-9-1 is: ADT > > ** MSH-9-2 is: A04 > > ** MSH-9-3 is: 43 > > ** MSH-10 is: 9007713 > > ** MSH-11 is: P > > ** MSH-12 is: 2.2 > > ** MSH-13 is: 9007713 > > ** MSH-14 is: null > > ** MSH > > ** EVN > > ca.uhn.hl7v2.HL7Exception: Can't XML-encode a=20 > GenericMessage. Message=20 > > must have a recognized structure. > > at ca.uhn.hl7v2.parser.XMLParser.doEncode(XMLParser.java:251) > > at ca.uhn.hl7v2.parser.Parser.encode(Parser.java:221) > > at ABParse.main(ABParse.java:79) > > > > And here's output from parsing the modified msg > >=20 > (MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04:43:P:2.2:9007713::AL:"": > > ) > > > > msg Name: ADT_A04 > > > > msg Name: ca.uhn.hl7v2.model.v22.message.ADT_A04 > > > > msg Version: 2.2 > > > > msg ?: MSH > > ** MSH-9-1 is: ADT > > ** MSH-9-2 is: A04 > > ** MSH-9-3 is: null > > ** MSH-10 is: 43 > > ** MSH-11 is: P > > ** MSH-12 is: 2.2 > > ** MSH-13 is: 9007713 > > ** MSH-14 is: null > > ** MSH > > ** EVN > > ** PID > > ** NK1 > > ** PV1 > > ** PV2 > > ** OBX > > ** AL1 > > ** DG1 > > ** PR1 > > ** GT1 > > ** INSURANCE > > ** ACC > > ** UB1 > > ** UB2 > > message is instanceof ADT_A04 > > <?xml version=3D"1.0"?> > > <ADT_A04 xmlns=3D"urn:hl7-org:v2xml"> > > <MSH> > > <MSH.1>:</MSH.1> > > <MSH.2>;~\&</MSH.2> > > <MSH.3>HBOC</MSH.3> > > <MSH.4>A</MSH.4> > > <MSH.5>HBOC</MSH.5> > > <MSH.6>A</MSH.6> > > <MSH.7> > > <TS.1>200512152351</TS.1> > > </MSH.7> > > <MSH.9> > > <CM_MSG.1>ADT</CM_MSG.1> > > <CM_MSG.2>A04</CM_MSG.2> > > </MSH.9> > > <MSH.10>43</MSH.10> > > <MSH.11>P</MSH.11> > > <MSH.12>2.2</MSH.12> > > <MSH.13>9007713</MSH.13> > > <MSH.15>AL</MSH.15> > > <MSH.16>""</MSH.16> > > </MSH> > > <EVN> > > <EVN.1>A04</EVN.1> > > <EVN.2> > > <TS.1>200512152351</TS.1> > > </EVN.2> > > </EVN> > > </ADT_A04> > > > > > > > > > -----Original Message----- > > > From: hl7...@li... > > > [mailto:hl7...@li...] On=20 > Behalf Of Bryan=20 > > > Tripp > > > Sent: Tuesday, January 10, 2006 1:27 PM > > > To: spr...@po... > > > Cc: hl7...@li... > > > Subject: Re: [HAPI-devel] Detemining the Message type in > > > Application.processMessage(...) > > > > > > > > > Hi Steve, > > > > > > The message type, event, and possibly structure should be=20 > in field=20 > > > MSH-9. Actually if they are there, HAPI should not use the=20 > > > GenericMessage class, and you should be able to tell what kind of=20 > > > message it is from the class. Maybe these data are=20 > missing from the=20 > > > message? > > > > > > Bryan > > > > > > On 1/9/06, Steve Pringle <st...@pr...> wrote: > > > > Could someone please tell me how one goes about determining > > > what type > > > > of message has been received in the > > > Application.processMessage(Message > > > > in) method? > > > > > > > > Here's a code snippet, which is being sent an ADT_A01 msg, > > > but I have > > > > no idea how to determine that it is an ADT_A01. All I want > > > to do is > > > > determine which message type was sent, get the data I need, > > > then send > > > > an ACK. > > > > > > > > public class ABApplication implements Application > > > > { > > > > ... > > > > public Message processMessage(Message in) throws > > > ApplicationException > > > > { > > > > Message out =3D null; > > > > PipeParser parser =3D new PipeParser(); > > > > > > > > try > > > > { > > > > System.out.println("\nmsg Name: " + > > > in.getName()); > > > > System.out.println("\nmsg Name: " +=20 > > > > in.getClass().getName()); > > > > System.out.println("\nmsg Version: " +=20 > > > > in.getVersion()); > > > > System.out.println("\nmsg ?: " +=20 > > > > in.get("MSH").getName()); > > > > > > > > String[] names =3D in.getNames(); > > > > > > > > for (int i =3D 0; i < names.length; i++) > > > > System.out.println("** " + > > > names[i]); > > > > ... > > > > > > > > Here's the output: > > > > > > > > msg Name: GenericMessage$V22 > > > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > > > msg Version: 2.2 > > > > > > > > msg ?: MSH > > > > ** MSH > > > > ** EVN > > > > ** PID > > > > ** NK1 > > > > ** PV1 > > > > > > > > Thanks, > > > > Steve PRingle > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > > through log > > > > files for problems? Stop! Download the new AJAX search > > > engine that > > > > makes searching your log files as easy as surfing the web. > > > DOWNLOAD > > > > SPLUNK! = http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > > > _______________________________________________ > > > > Hl7api-devel mailing list Hl7...@li... > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you=20 > grep through=20 > > > log files for problems? Stop! Download the new AJAX=20 > search engine=20 > > > that makes searching your log files as easy as surfing the web. =20 > > > DOWNLOAD SPLUNK! = http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > > > _______________________________________________ > > > Hl7api-devel mailing list > > > Hl7...@li... > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files for problems? Stop! Download the new AJAX=20 > search engine that makes searching your log files as easy as=20 > surfing the web. DOWNLOAD SPLUNK!=20 > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > Hl7api-devel mailing list > Hl7...@li... > https://lists.sourceforge.net/lists/listinfo/hl7api-devel >=20 >=20 |
From: Nico V. <ni...@sk...> - 2006-01-11 06:51:12
|
Hi Steve, Bryan, I'm also afraid that you won't be able to force the 3rd party system to=20 modify their hl7 message (unless they use a communications server of= course). Pure theoretically I think that the PipeParser class should be able to deal= =20 with this message (by ignoring MSH-9-3) since the messagestructure=20 component was not yet defined in HL7 version 2.2 and in that case I think=20 that HL7 expects you to ignore all additional non-expected components... What do you think ? Regards Nico At 11/01/2006, Steve Pringle wrote: >Unfortunately righteous ire isn't working in this situation (big hospital, >little software group)... Are you suggesting I modify some HAPI source >(Parser, Application, Connection, or) in order to edit the MSH message >*before* it gets parsed and sent to Application.processMessage(Message in)? > >So yes, pointers would be appreciated! > >Thanks, >Steve > > > -----Original Message----- > > From: hl7...@li... > > [mailto:hl7...@li...] On Behalf > > Of Bryan Tripp > > Sent: Tuesday, January 10, 2006 2:50 PM > > To: spr...@po... > > Cc: hl7...@li... > > Subject: Re: [HAPI-devel] Detemining the Message type in > > Application.processMessage(...) > > > > > > Yes, that would do it. Righteous ire might work, or if they > > don't respond well to that, all I can suggest is to hack > > something in to blank that field before the message is > > parsed. Let me know if you need pointers there. > > > > Bryan > > > > On 1/10/06, Steve Pringle <st...@pr...> wrote: > > > It looks like the MSH I have does not meet the HL7 2.2 specs? The > > > message type is in MSH-9, but there's also an int (43) in MSH-9-3... > > > > > > Here's the ADT A04 sample msg I have (header only): > > > > > > > > MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04;43:9007713:P:2.2:9007713: > > > :AL:"" > > > : > > > > > ^ > > > ^ > > > As I understand it, field MSH-9 is a msg type, > > "Components: <message type> > > > ^ <trigger event>", but the msg type sent is "ADT;A04;43", which is > > > incorrect according to the standards? In addition, there's > > an extra field > > > after the msg type, it's either "43" or "9007713" > > (depending on how the > > > segment is parsed), before the processing ID (P). But it > > seems 9007713 is > > > the sequence #, so why two of them? > > > > > > 9 7 CM R 0076 00009 Message type > > > 10 20 ST R 00010 Message control ID > > > 11 1 ID R 0103 00011 Processing ID > > > 12 8 ID R 0104 00012 Version ID > > > > > > Any suggestions on how to deal with this? It seems a good > > approach to > > > handling messages in my Application class, when a message > > is sent via > > > the "processMessage(Message in)" method, is to simply do an > > "instance > > > of" on the msg to determine it's type, then process the msg > > > accordingly. But with these msgs I'm being sent > > "instanceof" fails, > > > due to the MSH-9-3 field being present. If I remove the > > MSH-9-3 field > > > it parses properly, as an ADT_A04. > > > > > > Here's output from parsing the original msg: > > > > > > msg Name: GenericMessage$V22 > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > msg Version: 2.2 > > > > > > msg ?: MSH > > > ** MSH-9-1 is: ADT > > > ** MSH-9-2 is: A04 > > > ** MSH-9-3 is: 43 > > > ** MSH-10 is: 9007713 > > > ** MSH-11 is: P > > > ** MSH-12 is: 2.2 > > > ** MSH-13 is: 9007713 > > > ** MSH-14 is: null > > > ** MSH > > > ** EVN > > > ca.uhn.hl7v2.HL7Exception: Can't XML-encode a > > GenericMessage. Message > > > must have a recognized structure. > > > at ca.uhn.hl7v2.parser.XMLParser.doEncode(XMLParser.java:251) > > > at ca.uhn.hl7v2.parser.Parser.encode(Parser.java:221) > > > at ABParse.main(ABParse.java:79) > > > > > > And here's output from parsing the modified msg > > > > > (MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04:43:P:2.2:9007713::AL:"": > > > ) > > > > > > msg Name: ADT_A04 > > > > > > msg Name: ca.uhn.hl7v2.model.v22.message.ADT_A04 > > > > > > msg Version: 2.2 > > > > > > msg ?: MSH > > > ** MSH-9-1 is: ADT > > > ** MSH-9-2 is: A04 > > > ** MSH-9-3 is: null > > > ** MSH-10 is: 43 > > > ** MSH-11 is: P > > > ** MSH-12 is: 2.2 > > > ** MSH-13 is: 9007713 > > > ** MSH-14 is: null > > > ** MSH > > > ** EVN > > > ** PID > > > ** NK1 > > > ** PV1 > > > ** PV2 > > > ** OBX > > > ** AL1 > > > ** DG1 > > > ** PR1 > > > ** GT1 > > > ** INSURANCE > > > ** ACC > > > ** UB1 > > > ** UB2 > > > message is instanceof ADT_A04 > > > <?xml version=3D"1.0"?> > > > <ADT_A04 xmlns=3D"urn:hl7-org:v2xml"> > > > <MSH> > > > <MSH.1>:</MSH.1> > > > <MSH.2>;~\&</MSH.2> > > > <MSH.3>HBOC</MSH.3> > > > <MSH.4>A</MSH.4> > > > <MSH.5>HBOC</MSH.5> > > > <MSH.6>A</MSH.6> > > > <MSH.7> > > > <TS.1>200512152351</TS.1> > > > </MSH.7> > > > <MSH.9> > > > <CM_MSG.1>ADT</CM_MSG.1> > > > <CM_MSG.2>A04</CM_MSG.2> > > > </MSH.9> > > > <MSH.10>43</MSH.10> > > > <MSH.11>P</MSH.11> > > > <MSH.12>2.2</MSH.12> > > > <MSH.13>9007713</MSH.13> > > > <MSH.15>AL</MSH.15> > > > <MSH.16>""</MSH.16> > > > </MSH> > > > <EVN> > > > <EVN.1>A04</EVN.1> > > > <EVN.2> > > > <TS.1>200512152351</TS.1> > > > </EVN.2> > > > </EVN> > > > </ADT_A04> > > > > > > > > > > > > > -----Original Message----- > > > > From: hl7...@li... > > > > [mailto:hl7...@li...] On > > Behalf Of Bryan > > > > Tripp > > > > Sent: Tuesday, January 10, 2006 1:27 PM > > > > To: spr...@po... > > > > Cc: hl7...@li... > > > > Subject: Re: [HAPI-devel] Detemining the Message type in > > > > Application.processMessage(...) > > > > > > > > > > > > Hi Steve, > > > > > > > > The message type, event, and possibly structure should be > > in field > > > > MSH-9. Actually if they are there, HAPI should not use the > > > > GenericMessage class, and you should be able to tell what kind of > > > > message it is from the class. Maybe these data are > > missing from the > > > > message? > > > > > > > > Bryan > > > > > > > > On 1/9/06, Steve Pringle <st...@pr...> wrote: > > > > > Could someone please tell me how one goes about determining > > > > what type > > > > > of message has been received in the > > > > Application.processMessage(Message > > > > > in) method? > > > > > > > > > > Here's a code snippet, which is being sent an ADT_A01 msg, > > > > but I have > > > > > no idea how to determine that it is an ADT_A01. All I want > > > > to do is > > > > > determine which message type was sent, get the data I need, > > > > then send > > > > > an ACK. > > > > > > > > > > public class ABApplication implements Application > > > > > { > > > > > ... > > > > > public Message processMessage(Message in) throws > > > > ApplicationException > > > > > { > > > > > Message out =3D null; > > > > > PipeParser parser =3D new PipeParser(); > > > > > > > > > > try > > > > > { > > > > > System.out.println("\nmsg Name: " + > > > > in.getName()); > > > > > System.out.println("\nmsg Name: " + > > > > > in.getClass().getName()); > > > > > System.out.println("\nmsg Version: " + > > > > > in.getVersion()); > > > > > System.out.println("\nmsg ?: " + > > > > > in.get("MSH").getName()); > > > > > > > > > > String[] names =3D in.getNames(); > > > > > > > > > > for (int i =3D 0; i < names.length; i++) > > > > > System.out.println("** " + > > > > names[i]); > > > > > ... > > > > > > > > > > Here's the output: > > > > > > > > > > msg Name: GenericMessage$V22 > > > > > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > > > > > msg Version: 2.2 > > > > > > > > > > msg ?: MSH > > > > > ** MSH > > > > > ** EVN > > > > > ** PID > > > > > ** NK1 > > > > > ** PV1 > > > > > > > > > > Thanks, > > > > > Steve PRingle > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > > > through log > > > > > files for problems? Stop! Download the new AJAX search > > > > engine that > > > > > makes searching your log files as easy as surfing the web. > > > > DOWNLOAD > > > > > SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dcl= ick > > > > > _______________________________________________ > > > > > Hl7api-devel mailing list Hl7...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. Do you > > grep through > > > > log files for problems? Stop! Download the new AJAX > > search engine > > > > that makes searching your log files as easy as surfing the web. > > > > DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=CCk > > > > _______________________________________________ > > > > Hl7api-devel mailing list > > > > Hl7...@li... > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > through log files for problems? Stop! Download the new AJAX > > search engine that makes searching your log files as easy as > > surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id865&op=CCk > > _______________________________________________ > > Hl7api-devel mailing list > > Hl7...@li... > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log= files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_idv37&alloc_id865&opick >_______________________________________________ >Hl7api-devel mailing list >Hl7...@li... >https://lists.sourceforge.net/lists/listinfo/hl7api-devel |
From: Steve P. <spr...@pe...> - 2006-01-11 07:28:05
|
Hi Nico, Bryan, Sounds reasonable to me! Not sure how easy that is to do, however. In PipeParser, check if it's vers 2.2, then if it's got an additional subcomponent (MSH-9-3) throw it out? Thanks, Steve > -----Original Message----- > From: Nico Vannieuwenhuyze [mailto:ni...@sk...]=20 > Sent: Tuesday, January 10, 2006 10:51 PM > To: spr...@po...; 'Bryan Tripp' > Cc: hl7...@li... > Subject: RE: [HAPI-devel] Detemining the Message type in=20 > Application.processMessage(...) >=20 >=20 > Hi Steve, Bryan, >=20 > I'm also afraid that you won't be able to force the 3rd party=20 > system to=20 > modify their hl7 message (unless they use a communications=20 > server of course). >=20 > Pure theoretically I think that the PipeParser class should=20 > be able to deal=20 > with this message (by ignoring MSH-9-3) since the messagestructure=20 > component was not yet defined in HL7 version 2.2 and in that=20 > case I think=20 > that HL7 expects you to ignore all additional non-expected=20 > components... >=20 > What do you think ? >=20 > Regards >=20 > Nico >=20 > At 11/01/2006, Steve Pringle wrote: > >Unfortunately righteous ire isn't working in this situation (big=20 > >hospital, little software group)... Are you suggesting I=20 > modify some=20 > >HAPI source (Parser, Application, Connection, or) in order=20 > to edit the=20 > >MSH message > >*before* it gets parsed and sent to=20 > Application.processMessage(Message in)? > > > >So yes, pointers would be appreciated! > > > >Thanks, > >Steve > > > > > -----Original Message----- > > > From: hl7...@li... > > > [mailto:hl7...@li...] On=20 > Behalf Of Bryan=20 > > > Tripp > > > Sent: Tuesday, January 10, 2006 2:50 PM > > > To: spr...@po... > > > Cc: hl7...@li... > > > Subject: Re: [HAPI-devel] Detemining the Message type in > > > Application.processMessage(...) > > > > > > > > > Yes, that would do it. Righteous ire might work, or if they don't=20 > > > respond well to that, all I can suggest is to hack=20 > something in to=20 > > > blank that field before the message is parsed. Let me know if you=20 > > > need pointers there. > > > > > > Bryan > > > > > > On 1/10/06, Steve Pringle <st...@pr...> wrote: > > > > It looks like the MSH I have does not meet the HL7 2.2=20 > specs? The=20 > > > > message type is in MSH-9, but there's also an int (43) in=20 > > > > MSH-9-3... > > > > > > > > Here's the ADT A04 sample msg I have (header only): > > > > > > > > > > >=20 > MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04;43:9007713:P:2.2:900771 > > > 3: > > > > :AL:"" > > > > : > > > > > > > ^ > > > > ^ > > > > As I understand it, field MSH-9 is a msg type, > > > "Components: <message type> > > > > ^ <trigger event>", but the msg type sent is=20 > "ADT;A04;43", which=20 > > > > is incorrect according to the standards? In addition, there's > > > an extra field > > > > after the msg type, it's either "43" or "9007713" > > > (depending on how the > > > > segment is parsed), before the processing ID (P). But it > > > seems 9007713 is > > > > the sequence #, so why two of them? > > > > > > > > 9 7 CM R 0076 00009 Message type > > > > 10 20 ST R 00010 Message control ID > > > > 11 1 ID R 0103 00011 Processing ID > > > > 12 8 ID R 0104 00012 Version ID > > > > > > > > Any suggestions on how to deal with this? It seems a good > > > approach to > > > > handling messages in my Application class, when a message > > > is sent via > > > > the "processMessage(Message in)" method, is to simply do an > > > "instance > > > > of" on the msg to determine it's type, then process the msg=20 > > > > accordingly. But with these msgs I'm being sent > > > "instanceof" fails, > > > > due to the MSH-9-3 field being present. If I remove the > > > MSH-9-3 field > > > > it parses properly, as an ADT_A04. > > > > > > > > Here's output from parsing the original msg: > > > > > > > > msg Name: GenericMessage$V22 > > > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > > > msg Version: 2.2 > > > > > > > > msg ?: MSH > > > > ** MSH-9-1 is: ADT > > > > ** MSH-9-2 is: A04 > > > > ** MSH-9-3 is: 43 > > > > ** MSH-10 is: 9007713 > > > > ** MSH-11 is: P > > > > ** MSH-12 is: 2.2 > > > > ** MSH-13 is: 9007713 > > > > ** MSH-14 is: null > > > > ** MSH > > > > ** EVN > > > > ca.uhn.hl7v2.HL7Exception: Can't XML-encode a > > > GenericMessage. Message > > > > must have a recognized structure. > > > > at=20 > ca.uhn.hl7v2.parser.XMLParser.doEncode(XMLParser.java:251) > > > > at ca.uhn.hl7v2.parser.Parser.encode(Parser.java:221) > > > > at ABParse.main(ABParse.java:79) > > > > > > > > And here's output from parsing the modified msg > > > > > > >=20 > (MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04:43:P:2.2:9007713::AL:" > > > ": > > > > ) > > > > > > > > msg Name: ADT_A04 > > > > > > > > msg Name: ca.uhn.hl7v2.model.v22.message.ADT_A04 > > > > > > > > msg Version: 2.2 > > > > > > > > msg ?: MSH > > > > ** MSH-9-1 is: ADT > > > > ** MSH-9-2 is: A04 > > > > ** MSH-9-3 is: null > > > > ** MSH-10 is: 43 > > > > ** MSH-11 is: P > > > > ** MSH-12 is: 2.2 > > > > ** MSH-13 is: 9007713 > > > > ** MSH-14 is: null > > > > ** MSH > > > > ** EVN > > > > ** PID > > > > ** NK1 > > > > ** PV1 > > > > ** PV2 > > > > ** OBX > > > > ** AL1 > > > > ** DG1 > > > > ** PR1 > > > > ** GT1 > > > > ** INSURANCE > > > > ** ACC > > > > ** UB1 > > > > ** UB2 > > > > message is instanceof ADT_A04 > > > > <?xml version=3D"1.0"?> > > > > <ADT_A04 xmlns=3D"urn:hl7-org:v2xml"> > > > > <MSH> > > > > <MSH.1>:</MSH.1> > > > > <MSH.2>;~\&</MSH.2> > > > > <MSH.3>HBOC</MSH.3> > > > > <MSH.4>A</MSH.4> > > > > <MSH.5>HBOC</MSH.5> > > > > <MSH.6>A</MSH.6> > > > > <MSH.7> > > > > <TS.1>200512152351</TS.1> > > > > </MSH.7> > > > > <MSH.9> > > > > <CM_MSG.1>ADT</CM_MSG.1> > > > > <CM_MSG.2>A04</CM_MSG.2> > > > > </MSH.9> > > > > <MSH.10>43</MSH.10> > > > > <MSH.11>P</MSH.11> > > > > <MSH.12>2.2</MSH.12> > > > > <MSH.13>9007713</MSH.13> > > > > <MSH.15>AL</MSH.15> > > > > <MSH.16>""</MSH.16> > > > > </MSH> > > > > <EVN> > > > > <EVN.1>A04</EVN.1> > > > > <EVN.2> > > > > <TS.1>200512152351</TS.1> > > > > </EVN.2> > > > > </EVN> > > > > </ADT_A04> > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: hl7...@li... > > > > > [mailto:hl7...@li...] On > > > Behalf Of Bryan > > > > > Tripp > > > > > Sent: Tuesday, January 10, 2006 1:27 PM > > > > > To: spr...@po... > > > > > Cc: hl7...@li... > > > > > Subject: Re: [HAPI-devel] Detemining the Message type in > > > > > Application.processMessage(...) > > > > > > > > > > > > > > > Hi Steve, > > > > > > > > > > The message type, event, and possibly structure should be > > > in field > > > > > MSH-9. Actually if they are there, HAPI should not use the=20 > > > > > GenericMessage class, and you should be able to tell=20 > what kind=20 > > > > > of message it is from the class. Maybe these data are > > > missing from the > > > > > message? > > > > > > > > > > Bryan > > > > > > > > > > On 1/9/06, Steve Pringle <st...@pr...> wrote: > > > > > > Could someone please tell me how one goes about determining > > > > > what type > > > > > > of message has been received in the > > > > > Application.processMessage(Message > > > > > > in) method? > > > > > > > > > > > > Here's a code snippet, which is being sent an ADT_A01 msg, > > > > > but I have > > > > > > no idea how to determine that it is an ADT_A01. All I want > > > > > to do is > > > > > > determine which message type was sent, get the data I need, > > > > > then send > > > > > > an ACK. > > > > > > > > > > > > public class ABApplication implements Application > > > > > > { > > > > > > ... > > > > > > public Message processMessage(Message in) throws > > > > > ApplicationException > > > > > > { > > > > > > Message out =3D null; > > > > > > PipeParser parser =3D new PipeParser(); > > > > > > > > > > > > try > > > > > > { > > > > > > System.out.println("\nmsg Name: " + > > > > > in.getName()); > > > > > > System.out.println("\nmsg Name: " +=20 > > > > > > in.getClass().getName()); > > > > > > System.out.println("\nmsg=20 > Version: " +=20 > > > > > > in.getVersion()); > > > > > > System.out.println("\nmsg ?: " +=20 > > > > > > in.get("MSH").getName()); > > > > > > > > > > > > String[] names =3D in.getNames(); > > > > > > > > > > > > for (int i =3D 0; i <=20 > names.length; i++) > > > > > > System.out.println("** " + > > > > > names[i]); > > > > > > ... > > > > > > > > > > > > Here's the output: > > > > > > > > > > > > msg Name: GenericMessage$V22 > > > > > > > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > > > > > > > msg Version: 2.2 > > > > > > > > > > > > msg ?: MSH > > > > > > ** MSH > > > > > > ** EVN > > > > > > ** PID > > > > > > ** NK1 > > > > > > ** PV1 > > > > > > > > > > > > Thanks, > > > > > > Steve PRingle > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > > > > through log > > > > > > files for problems? Stop! Download the new AJAX search > > > > > engine that > > > > > > makes searching your log files as easy as surfing the web. > > > > > DOWNLOAD > > > > > > SPLUNK!=20 > > > > > > = http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > > > > > _______________________________________________ > > > > > > Hl7api-devel mailing list Hl7...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.net email is sponsored by: Splunk Inc. Do you > > > grep through > > > > > log files for problems? Stop! Download the new AJAX > > > search engine > > > > > that makes searching your log files as easy as=20 > surfing the web.=20 > > > > > DOWNLOAD SPLUNK!=20 > http://ads.osdn.com/?ad_idv37&alloc_id865&op=CCk > > > > > _______________________________________________ > > > > > Hl7api-devel mailing list Hl7...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you=20 > grep through=20 > > > log files for problems? Stop! Download the new AJAX=20 > search engine=20 > > > that makes searching your log files as easy as surfing the web. =20 > > > DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=CCk > > > _______________________________________________ > > > Hl7api-devel mailing list > > > Hl7...@li... > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log=20 > >files for problems? Stop! Download the new AJAX search engine that=20 > >makes searching your log files as easy as surfing the web. =20 > DOWNLOAD=20 > >SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&opick > >_______________________________________________ > >Hl7api-devel mailing list > >Hl7...@li... > >https://lists.sourceforge.net/lists/listinfo/hl7api-devel >=20 >=20 >=20 |
From: Nico V. <ni...@sk...> - 2006-01-11 20:22:47
|
Hi Steve, I would suggest modifying the method getStructure in the PipeParser class=20 but I guess that Bryan can provide a better solution without the need to=20 modify the hapi library ... Regards Nico At 11/01/2006, Steve Pringle wrote: >Hi Nico, Bryan, > >Sounds reasonable to me! Not sure how easy that is to do, however. In >PipeParser, check if it's vers 2.2, then if it's got an additional >subcomponent (MSH-9-3) throw it out? > >Thanks, >Steve > > > -----Original Message----- > > From: Nico Vannieuwenhuyze [mailto:ni...@sk...] > > Sent: Tuesday, January 10, 2006 10:51 PM > > To: spr...@po...; 'Bryan Tripp' > > Cc: hl7...@li... > > Subject: RE: [HAPI-devel] Detemining the Message type in > > Application.processMessage(...) > > > > > > Hi Steve, Bryan, > > > > I'm also afraid that you won't be able to force the 3rd party > > system to > > modify their hl7 message (unless they use a communications > > server of course). > > > > Pure theoretically I think that the PipeParser class should > > be able to deal > > with this message (by ignoring MSH-9-3) since the messagestructure > > component was not yet defined in HL7 version 2.2 and in that > > case I think > > that HL7 expects you to ignore all additional non-expected > > components... > > > > What do you think ? > > > > Regards > > > > Nico > > > > At 11/01/2006, Steve Pringle wrote: > > >Unfortunately righteous ire isn't working in this situation (big > > >hospital, little software group)... Are you suggesting I > > modify some > > >HAPI source (Parser, Application, Connection, or) in order > > to edit the > > >MSH message > > >*before* it gets parsed and sent to > > Application.processMessage(Message in)? > > > > > >So yes, pointers would be appreciated! > > > > > >Thanks, > > >Steve > > > > > > > -----Original Message----- > > > > From: hl7...@li... > > > > [mailto:hl7...@li...] On > > Behalf Of Bryan > > > > Tripp > > > > Sent: Tuesday, January 10, 2006 2:50 PM > > > > To: spr...@po... > > > > Cc: hl7...@li... > > > > Subject: Re: [HAPI-devel] Detemining the Message type in > > > > Application.processMessage(...) > > > > > > > > > > > > Yes, that would do it. Righteous ire might work, or if they don't > > > > respond well to that, all I can suggest is to hack > > something in to > > > > blank that field before the message is parsed. Let me know if you > > > > need pointers there. > > > > > > > > Bryan > > > > > > > > On 1/10/06, Steve Pringle <st...@pr...> wrote: > > > > > It looks like the MSH I have does not meet the HL7 2.2 > > specs? The > > > > > message type is in MSH-9, but there's also an int (43) in > > > > > MSH-9-3... > > > > > > > > > > Here's the ADT A04 sample msg I have (header only): > > > > > > > > > > > > > > > > MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04;43:9007713:P:2.2:900771 > > > > 3: > > > > > :AL:"" > > > > > : > > > > > > > > > ^ > > > > > ^ > > > > > As I understand it, field MSH-9 is a msg type, > > > > "Components: <message type> > > > > > ^ <trigger event>", but the msg type sent is > > "ADT;A04;43", which > > > > > is incorrect according to the standards? In addition, there's > > > > an extra field > > > > > after the msg type, it's either "43" or "9007713" > > > > (depending on how the > > > > > segment is parsed), before the processing ID (P). But it > > > > seems 9007713 is > > > > > the sequence #, so why two of them? > > > > > > > > > > 9 7 CM R 0076 00009 Message type > > > > > 10 20 ST R 00010 Message control ID > > > > > 11 1 ID R 0103 00011 Processing ID > > > > > 12 8 ID R 0104 00012 Version ID > > > > > > > > > > Any suggestions on how to deal with this? It seems a good > > > > approach to > > > > > handling messages in my Application class, when a message > > > > is sent via > > > > > the "processMessage(Message in)" method, is to simply do an > > > > "instance > > > > > of" on the msg to determine it's type, then process the msg > > > > > accordingly. But with these msgs I'm being sent > > > > "instanceof" fails, > > > > > due to the MSH-9-3 field being present. If I remove the > > > > MSH-9-3 field > > > > > it parses properly, as an ADT_A04. > > > > > > > > > > Here's output from parsing the original msg: > > > > > > > > > > msg Name: GenericMessage$V22 > > > > > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > > > > > msg Version: 2.2 > > > > > > > > > > msg ?: MSH > > > > > ** MSH-9-1 is: ADT > > > > > ** MSH-9-2 is: A04 > > > > > ** MSH-9-3 is: 43 > > > > > ** MSH-10 is: 9007713 > > > > > ** MSH-11 is: P > > > > > ** MSH-12 is: 2.2 > > > > > ** MSH-13 is: 9007713 > > > > > ** MSH-14 is: null > > > > > ** MSH > > > > > ** EVN > > > > > ca.uhn.hl7v2.HL7Exception: Can't XML-encode a > > > > GenericMessage. Message > > > > > must have a recognized structure. > > > > > at > > ca.uhn.hl7v2.parser.XMLParser.doEncode(XMLParser.java:251) > > > > > at ca.uhn.hl7v2.parser.Parser.encode(Parser.java:221) > > > > > at ABParse.main(ABParse.java:79) > > > > > > > > > > And here's output from parsing the modified msg > > > > > > > > > > > (MSH:;~\&:HBOC:A:HBOC:A:200512152351::ADT;A04:43:P:2.2:9007713::AL:" > > > > ": > > > > > ) > > > > > > > > > > msg Name: ADT_A04 > > > > > > > > > > msg Name: ca.uhn.hl7v2.model.v22.message.ADT_A04 > > > > > > > > > > msg Version: 2.2 > > > > > > > > > > msg ?: MSH > > > > > ** MSH-9-1 is: ADT > > > > > ** MSH-9-2 is: A04 > > > > > ** MSH-9-3 is: null > > > > > ** MSH-10 is: 43 > > > > > ** MSH-11 is: P > > > > > ** MSH-12 is: 2.2 > > > > > ** MSH-13 is: 9007713 > > > > > ** MSH-14 is: null > > > > > ** MSH > > > > > ** EVN > > > > > ** PID > > > > > ** NK1 > > > > > ** PV1 > > > > > ** PV2 > > > > > ** OBX > > > > > ** AL1 > > > > > ** DG1 > > > > > ** PR1 > > > > > ** GT1 > > > > > ** INSURANCE > > > > > ** ACC > > > > > ** UB1 > > > > > ** UB2 > > > > > message is instanceof ADT_A04 > > > > > <?xml version=3D"1.0"?> > > > > > <ADT_A04 xmlns=3D"urn:hl7-org:v2xml"> > > > > > <MSH> > > > > > <MSH.1>:</MSH.1> > > > > > <MSH.2>;~\&</MSH.2> > > > > > <MSH.3>HBOC</MSH.3> > > > > > <MSH.4>A</MSH.4> > > > > > <MSH.5>HBOC</MSH.5> > > > > > <MSH.6>A</MSH.6> > > > > > <MSH.7> > > > > > <TS.1>200512152351</TS.1> > > > > > </MSH.7> > > > > > <MSH.9> > > > > > <CM_MSG.1>ADT</CM_MSG.1> > > > > > <CM_MSG.2>A04</CM_MSG.2> > > > > > </MSH.9> > > > > > <MSH.10>43</MSH.10> > > > > > <MSH.11>P</MSH.11> > > > > > <MSH.12>2.2</MSH.12> > > > > > <MSH.13>9007713</MSH.13> > > > > > <MSH.15>AL</MSH.15> > > > > > <MSH.16>""</MSH.16> > > > > > </MSH> > > > > > <EVN> > > > > > <EVN.1>A04</EVN.1> > > > > > <EVN.2> > > > > > <TS.1>200512152351</TS.1> > > > > > </EVN.2> > > > > > </EVN> > > > > > </ADT_A04> > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: hl7...@li... > > > > > > [mailto:hl7...@li...] On > > > > Behalf Of Bryan > > > > > > Tripp > > > > > > Sent: Tuesday, January 10, 2006 1:27 PM > > > > > > To: spr...@po... > > > > > > Cc: hl7...@li... > > > > > > Subject: Re: [HAPI-devel] Detemining the Message type in > > > > > > Application.processMessage(...) > > > > > > > > > > > > > > > > > > Hi Steve, > > > > > > > > > > > > The message type, event, and possibly structure should be > > > > in field > > > > > > MSH-9. Actually if they are there, HAPI should not use the > > > > > > GenericMessage class, and you should be able to tell > > what kind > > > > > > of message it is from the class. Maybe these data are > > > > missing from the > > > > > > message? > > > > > > > > > > > > Bryan > > > > > > > > > > > > On 1/9/06, Steve Pringle <st...@pr...> wrote: > > > > > > > Could someone please tell me how one goes about determining > > > > > > what type > > > > > > > of message has been received in the > > > > > > Application.processMessage(Message > > > > > > > in) method? > > > > > > > > > > > > > > Here's a code snippet, which is being sent an ADT_A01 msg, > > > > > > but I have > > > > > > > no idea how to determine that it is an ADT_A01. All I want > > > > > > to do is > > > > > > > determine which message type was sent, get the data I need, > > > > > > then send > > > > > > > an ACK. > > > > > > > > > > > > > > public class ABApplication implements Application > > > > > > > { > > > > > > > ... > > > > > > > public Message processMessage(Message in) throws > > > > > > ApplicationException > > > > > > > { > > > > > > > Message out =3D null; > > > > > > > PipeParser parser =3D new PipeParser(); > > > > > > > > > > > > > > try > > > > > > > { > > > > > > > System.out.println("\nmsg Name: " + > > > > > > in.getName()); > > > > > > > System.out.println("\nmsg Name: " + > > > > > > > in.getClass().getName()); > > > > > > > System.out.println("\nmsg > > Version: " + > > > > > > > in.getVersion()); > > > > > > > System.out.println("\nmsg ?: " + > > > > > > > in.get("MSH").getName()); > > > > > > > > > > > > > > String[] names =3D in.getNames(); > > > > > > > > > > > > > > for (int i =3D 0; i < > > names.length; i++) > > > > > > > System.out.println("** " + > > > > > > names[i]); > > > > > > > ... > > > > > > > > > > > > > > Here's the output: > > > > > > > > > > > > > > msg Name: GenericMessage$V22 > > > > > > > > > > > > > > msg Name: ca.uhn.hl7v2.model.GenericMessage$V22 > > > > > > > > > > > > > > msg Version: 2.2 > > > > > > > > > > > > > > msg ?: MSH > > > > > > > ** MSH > > > > > > > ** EVN > > > > > > > ** PID > > > > > > > ** NK1 > > > > > > > ** PV1 > > > > > > > > > > > > > > Thanks, > > > > > > > Steve PRingle > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > > > > > through log > > > > > > > files for problems? Stop! Download the new AJAX search > > > > > > engine that > > > > > > > makes searching your log files as easy as surfing the web. > > > > > > DOWNLOAD > > > > > > > SPLUNK! > > > > > > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > > > > > > _______________________________________________ > > > > > > > Hl7api-devel mailing list Hl7...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.net email is sponsored by: Splunk Inc. Do you > > > > grep through > > > > > > log files for problems? Stop! Download the new AJAX > > > > search engine > > > > > > that makes searching your log files as easy as > > surfing the web. > > > > > > DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id865&op=CCk > > > > > > _______________________________________________ > > > > > > Hl7api-devel mailing list Hl7...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. Do you > > grep through > > > > log files for problems? Stop! Download the new AJAX > > search engine > > > > that makes searching your log files as easy as surfing the web. > > > > DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=CCk > > > > _______________________________________________ > > > > Hl7api-devel mailing list > > > > Hl7...@li... > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------- > > >This SF.net email is sponsored by: Splunk Inc. Do you grep > > through log > > >files for problems? Stop! Download the new AJAX search engine that > > >makes searching your log files as easy as surfing the web. > > DOWNLOAD > > >SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&opick > > >_______________________________________________ > > >Hl7api-devel mailing list > > >Hl7...@li... > > >https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > > > > > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log= files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_idv37&alloc_id865&opick >_______________________________________________ >Hl7api-devel mailing list >Hl7...@li... >https://lists.sourceforge.net/lists/listinfo/hl7api-devel |
From: Bryan T. <bp...@gm...> - 2006-01-11 21:52:58
|
SGksCgpZZXMsIGlmIHlvdSdyZSB1c2luZyB0aGUgY2EudWhuLmhsN3YyLnByb3RvY29sIHBhY2th Z2UsIHRoaXMgY2FuIGJlCmRvbmUgc2ltcGx5LCB3aXRob3V0IGNoYW5naW5nIEhBUEkgY29kZS4g UGFydCBvZiB5b3VyIHNldHVwIHdpbGwgYmUgdG8KY29uc3RydWN0IGFuIEFwcGxpY2F0aW9uUm91 dGVyLCBhbmQgeW91IGNhbiB3cmFwIHRoZSBtZXRob2Q6CgpwdWJsaWMgVHJhbnNwb3J0YWJsZSBw cm9jZXNzTWVzc2FnZShUcmFuc3BvcnRhYmxlIHRoZU1lc3NhZ2UpCgouLi4gdG8gZWRpdCB0aGUg bWVzc2FnZSBzdHJpbmcgKHRoZU1lc3NhZ2UuZ2V0TWVzc2FnZSgpIGNvbnRhaW5zIHRoZQptZXNz YWdlIHN0cmluZykuIFlvdSBjb3VsZCBlaXRoZXIgZGVsZXRlIE1TSC05LTMgb3IgbW92ZSBpdCB0 byBNU0gtOS00CmluIGNhc2UgeW91IHdhbnQgdGhlIGNvbnRlbnRzLiBZb3Ugd2lsbCBoYXZlIHRv IGZpbmQgaXQgYnkgY291bnRpbmcKZGVsaW1pdGVycy4KCkJyeWFuCgpPbiAxLzExLzA2LCBTdGV2 ZSBQcmluZ2xlIDxzcHJpbmdsZUBwZWFrLm9yZz4gd3JvdGU6Cj4gVGhhbmtzIE5pY28gLQo+Cj4g QXMgeW91IHNheSwgbGV0J3Mgd2FpdCB0byBoZWFyIGZyb20gQnJ5YW4uLi4KPgo+IEJlc3QgUmVn YXJkcywKPiBTdGV2ZQo+Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTog TmljbyBWYW5uaWV1d2VuaHV5emUgW21haWx0bzpuaWNvdm5Ac2t5bmV0LmJlXQo+ID4gU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDA2IDEyOjIyIFBNCj4gPiBUbzogc3ByaW5nbGVAcG9p bnR2aXN0YS5iaXo7ICdCcnlhbiBUcmlwcCcKPiA+IENjOiBobDdhcGktZGV2ZWxAbGlzdHMuc291 cmNlZm9yZ2UubmV0Cj4gPiBTdWJqZWN0OiBSRTogW0hBUEktZGV2ZWxdIERldGVtaW5pbmcgdGhl IE1lc3NhZ2UgdHlwZSBpbgo+ID4gQXBwbGljYXRpb24ucHJvY2Vzc01lc3NhZ2UoLi4uKQo+ID4K PiA+Cj4gPiBIaSBTdGV2ZSwKPiA+Cj4gPiBJIHdvdWxkIHN1Z2dlc3QgbW9kaWZ5aW5nIHRoZSBt ZXRob2QgZ2V0U3RydWN0dXJlIGluIHRoZQo+ID4gUGlwZVBhcnNlciBjbGFzcwo+ID4gYnV0IEkg Z3Vlc3MgdGhhdCBCcnlhbiBjYW4gcHJvdmlkZSBhIGJldHRlciBzb2x1dGlvbiB3aXRob3V0Cj4g PiB0aGUgbmVlZCB0bwo+ID4gbW9kaWZ5IHRoZSBoYXBpIGxpYnJhcnkgLi4uCj4gPgo+ID4gUmVn YXJkcwo+ID4KPiA+IE5pY28KPiA+Cj4gPiBBdCAxMS8wMS8yMDA2LCBTdGV2ZSBQcmluZ2xlIHdy b3RlOgo+ID4gPkhpIE5pY28sIEJyeWFuLAo+ID4gPgo+ID4gPlNvdW5kcyByZWFzb25hYmxlIHRv IG1lISAgTm90IHN1cmUgaG93IGVhc3kgdGhhdCBpcyB0byBkbywKPiA+IGhvd2V2ZXIuICBJbgo+ ID4gPlBpcGVQYXJzZXIsIGNoZWNrIGlmIGl0J3MgdmVycyAyLjIsIHRoZW4gaWYgaXQncyBnb3Qg YW4gYWRkaXRpb25hbAo+ID4gPnN1YmNvbXBvbmVudCAoTVNILTktMykgdGhyb3cgaXQgb3V0Pwo+ ID4gPgo+ID4gPlRoYW5rcywKPiA+ID5TdGV2ZQo+ID4gPgo+ID4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCj4gPiA+ID4gRnJvbTogTmljbyBWYW5uaWV1d2VuaHV5emUgW21haWx0bzpu aWNvdm5Ac2t5bmV0LmJlXQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMDYg MTA6NTEgUE0KPiA+ID4gPiBUbzogc3ByaW5nbGVAcG9pbnR2aXN0YS5iaXo7ICdCcnlhbiBUcmlw cCcKPiA+ID4gPiBDYzogaGw3YXBpLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+ID4gPiA+ IFN1YmplY3Q6IFJFOiBbSEFQSS1kZXZlbF0gRGV0ZW1pbmluZyB0aGUgTWVzc2FnZSB0eXBlIGlu Cj4gPiA+ID4gQXBwbGljYXRpb24ucHJvY2Vzc01lc3NhZ2UoLi4uKQo+ID4gPiA+Cj4gPiA+ID4K PiA+ID4gPiBIaSBTdGV2ZSwgQnJ5YW4sCj4gPiA+ID4KPiA+ID4gPiBJJ20gYWxzbyBhZnJhaWQg dGhhdCB5b3Ugd29uJ3QgYmUgYWJsZSB0byBmb3JjZSB0aGUgM3JkCj4gPiBwYXJ0eSBzeXN0ZW0K PiA+ID4gPiB0byBtb2RpZnkgdGhlaXIgaGw3IG1lc3NhZ2UgKHVubGVzcyB0aGV5IHVzZSBhIGNv bW11bmljYXRpb25zCj4gPiA+ID4gc2VydmVyIG9mIGNvdXJzZSkuCj4gPiA+ID4KPiA+ID4gPiBQ dXJlIHRoZW9yZXRpY2FsbHkgSSB0aGluayB0aGF0IHRoZSBQaXBlUGFyc2VyIGNsYXNzCj4gPiBz aG91bGQgYmUgYWJsZQo+ID4gPiA+IHRvIGRlYWwgd2l0aCB0aGlzIG1lc3NhZ2UgKGJ5IGlnbm9y aW5nIE1TSC05LTMpIHNpbmNlIHRoZQo+ID4gPiA+IG1lc3NhZ2VzdHJ1Y3R1cmUgY29tcG9uZW50 IHdhcyBub3QgeWV0IGRlZmluZWQgaW4gSEw3IHZlcnNpb24gMi4yCj4gPiA+ID4gYW5kIGluIHRo YXQgY2FzZSBJIHRoaW5rCj4gPiA+ID4gdGhhdCBITDcgZXhwZWN0cyB5b3UgdG8gaWdub3JlIGFs bCBhZGRpdGlvbmFsIG5vbi1leHBlY3RlZAo+ID4gPiA+IGNvbXBvbmVudHMuLi4KPiA+ID4gPgo+ ID4gPiA+IFdoYXQgZG8geW91IHRoaW5rID8KPiA+ID4gPgo+ID4gPiA+IFJlZ2FyZHMKPiA+ID4g Pgo+ID4gPiA+IE5pY28KPiA+ID4gPgo+ID4gPiA+IEF0IDExLzAxLzIwMDYsIFN0ZXZlIFByaW5n bGUgd3JvdGU6Cj4gPiA+ID4gPlVuZm9ydHVuYXRlbHkgcmlnaHRlb3VzIGlyZSBpc24ndCB3b3Jr aW5nIGluIHRoaXMgc2l0dWF0aW9uIChiaWcKPiA+ID4gPiA+aG9zcGl0YWwsIGxpdHRsZSBzb2Z0 d2FyZSBncm91cCkuLi4gIEFyZSB5b3Ugc3VnZ2VzdGluZyBJCj4gPiA+ID4gbW9kaWZ5IHNvbWUK PiA+ID4gPiA+SEFQSSBzb3VyY2UgKFBhcnNlciwgQXBwbGljYXRpb24sIENvbm5lY3Rpb24sIG9y KSBpbiBvcmRlcgo+ID4gPiA+IHRvIGVkaXQgdGhlCj4gPiA+ID4gPk1TSCBtZXNzYWdlCj4gPiA+ ID4gPipiZWZvcmUqIGl0IGdldHMgcGFyc2VkIGFuZCBzZW50IHRvCj4gPiA+ID4gQXBwbGljYXRp b24ucHJvY2Vzc01lc3NhZ2UoTWVzc2FnZSBpbik/Cj4gPiA+ID4gPgo+ID4gPiA+ID5TbyB5ZXMs IHBvaW50ZXJzIHdvdWxkIGJlIGFwcHJlY2lhdGVkIQo+ID4gPiA+ID4KPiA+ID4gPiA+VGhhbmtz LAo+ID4gPiA+ID5TdGV2ZQo+ID4gPiA+ID4KPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0KPiA+ID4gPiA+ID4gRnJvbTogaGw3YXBpLWRldmVsLWFkbWluQGxpc3RzLnNvdXJj ZWZvcmdlLm5ldAo+ID4gPiA+ID4gPiBbbWFpbHRvOmhsN2FwaS1kZXZlbC1hZG1pbkBsaXN0cy5z b3VyY2Vmb3JnZS5uZXRdIE9uCj4gPiA+ID4gQmVoYWxmIE9mIEJyeWFuCj4gPiA+ID4gPiA+IFRy aXBwCj4gPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMDYgMjo1MCBQTQo+ ID4gPiA+ID4gPiBUbzogc3ByaW5nbGVAcG9pbnR2aXN0YS5iaXoKPiA+ID4gPiA+ID4gQ2M6IGhs N2FwaS1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6 IFtIQVBJLWRldmVsXSBEZXRlbWluaW5nIHRoZSBNZXNzYWdlIHR5cGUgaW4KPiA+ID4gPiA+ID4g QXBwbGljYXRpb24ucHJvY2Vzc01lc3NhZ2UoLi4uKQo+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPgo+ ID4gPiA+ID4gPiBZZXMsIHRoYXQgd291bGQgZG8gaXQuIFJpZ2h0ZW91cyBpcmUgbWlnaHQgd29y aywgb3IgaWYgdGhleQo+ID4gPiA+ID4gPiBkb24ndCByZXNwb25kIHdlbGwgdG8gdGhhdCwgYWxs IEkgY2FuIHN1Z2dlc3QgaXMgdG8gaGFjawo+ID4gPiA+IHNvbWV0aGluZyBpbiB0bwo+ID4gPiA+ ID4gPiBibGFuayB0aGF0IGZpZWxkIGJlZm9yZSB0aGUgbWVzc2FnZSBpcyBwYXJzZWQuIExldCBt ZSBrbm93IGlmCj4gPiA+ID4gPiA+IHlvdSBuZWVkIHBvaW50ZXJzIHRoZXJlLgo+ID4gPiA+ID4g Pgo+ID4gPiA+ID4gPiBCcnlhbgo+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiBPbiAxLzEwLzA2LCBT dGV2ZSBQcmluZ2xlIDxzdGV2ZUBwcmluZ2xlLmhtPiB3cm90ZToKPiA+ID4gPiA+ID4gPiBJdCBs b29rcyBsaWtlIHRoZSBNU0ggSSBoYXZlIGRvZXMgbm90IG1lZXQgdGhlIEhMNyAyLjIKPiA+ID4g PiBzcGVjcz8gIFRoZQo+ID4gPiA+ID4gPiA+IG1lc3NhZ2UgdHlwZSBpcyBpbiBNU0gtOSwgYnV0 IHRoZXJlJ3MgYWxzbyBhbiBpbnQgKDQzKSBpbgo+ID4gPiA+ID4gPiA+IE1TSC05LTMuLi4KPiA+ ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+IEhlcmUncyB0aGUgQURUIEEwNCBzYW1wbGUgbXNnIEkg aGF2ZSAoaGVhZGVyIG9ubHkpOgo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ ID4KPiA+ID4gPgo+ID4gTVNIOjt+XCY6SEJPQzpBOkhCT0M6QToyMDA1MTIxNTIzNTE6OkFEVDtB MDQ7NDM6OTAwNzcxMzpQOjIuMjo5MDA3NzEKPiA+ID4gPiA+ID4gMzoKPiA+ID4gPiA+ID4gPiA6 QUw6IiIKPiA+ID4gPiA+ID4gPiA6Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gICAgICAgICAg IF4KPiA+ID4gPiA+ID4gPiBeCj4gPiA+ID4gPiA+ID4gQXMgSSB1bmRlcnN0YW5kIGl0LCBmaWVs ZCBNU0gtOSBpcyBhIG1zZyB0eXBlLAo+ID4gPiA+ID4gPiAiQ29tcG9uZW50czogPG1lc3NhZ2Ug dHlwZT4KPiA+ID4gPiA+ID4gPiBeIDx0cmlnZ2VyIGV2ZW50PiIsICBidXQgdGhlIG1zZyB0eXBl IHNlbnQgaXMKPiA+ID4gPiAiQURUO0EwNDs0MyIsIHdoaWNoCj4gPiA+ID4gPiA+ID4gaXMgaW5j b3JyZWN0IGFjY29yZGluZyB0byB0aGUgc3RhbmRhcmRzPyAgSW4KPiA+IGFkZGl0aW9uLCB0aGVy ZSdzCj4gPiA+ID4gPiA+IGFuIGV4dHJhIGZpZWxkCj4gPiA+ID4gPiA+ID4gYWZ0ZXIgdGhlIG1z ZyB0eXBlLCBpdCdzIGVpdGhlciAiNDMiIG9yICAiOTAwNzcxMyIKPiA+ID4gPiA+ID4gKGRlcGVu ZGluZyBvbiBob3cgdGhlCj4gPiA+ID4gPiA+ID4gc2VnbWVudCBpcyBwYXJzZWQpLCBiZWZvcmUg dGhlIHByb2Nlc3NpbmcgSUQgKFApLiAgQnV0IGl0Cj4gPiA+ID4gPiA+IHNlZW1zIDkwMDc3MTMg aXMKPiA+ID4gPiA+ID4gPiB0aGUgc2VxdWVuY2UgIywgc28gd2h5IHR3byBvZiB0aGVtPwo+ID4g PiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gIDkgICAgNyAgQ00gIFIgICAgICAgICAgMDA3NiAgIDAw MDA5ICAgTWVzc2FnZSB0eXBlCj4gPiA+ID4gPiA+ID4gMTAgICAyMCAgU1QgIFIgICAgICAgICAg ICAgICAgIDAwMDEwICAgTWVzc2FnZSBjb250cm9sIElECj4gPiA+ID4gPiA+ID4gMTEgICAgMSAg SUQgIFIgICAgICAgICAgMDEwMyAgIDAwMDExICAgUHJvY2Vzc2luZyBJRAo+ID4gPiA+ID4gPiA+ IDEyICAgIDggIElEICBSICAgICAgICAgIDAxMDQgICAwMDAxMiAgIFZlcnNpb24gSUQKPiA+ID4g PiA+ID4gPgo+ID4gPiA+ID4gPiA+IEFueSBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZGVhbCB3aXRo IHRoaXM/ICBJdCBzZWVtcyBhIGdvb2QKPiA+ID4gPiA+ID4gYXBwcm9hY2ggdG8KPiA+ID4gPiA+ ID4gPiBoYW5kbGluZyBtZXNzYWdlcyBpbiBteSBBcHBsaWNhdGlvbiBjbGFzcywgd2hlbiBhIG1l c3NhZ2UKPiA+ID4gPiA+ID4gaXMgc2VudCB2aWEKPiA+ID4gPiA+ID4gPiB0aGUgInByb2Nlc3NN ZXNzYWdlKE1lc3NhZ2UgaW4pIiBtZXRob2QsIGlzIHRvIHNpbXBseSBkbyBhbgo+ID4gPiA+ID4g PiAiaW5zdGFuY2UKPiA+ID4gPiA+ID4gPiBvZiIgb24gdGhlIG1zZyB0byBkZXRlcm1pbmUgaXQn cyB0eXBlLCB0aGVuIHByb2Nlc3MgdGhlIG1zZwo+ID4gPiA+ID4gPiA+IGFjY29yZGluZ2x5LiAg QnV0IHdpdGggdGhlc2UgbXNncyBJJ20gYmVpbmcgc2VudAo+ID4gPiA+ID4gPiAiaW5zdGFuY2Vv ZiIgZmFpbHMsCj4gPiA+ID4gPiA+ID4gZHVlIHRvIHRoZSBNU0gtOS0zIGZpZWxkIGJlaW5nIHBy ZXNlbnQuICBJZiBJIHJlbW92ZSB0aGUKPiA+ID4gPiA+ID4gTVNILTktMyBmaWVsZAo+ID4gPiA+ ID4gPiA+IGl0IHBhcnNlcyBwcm9wZXJseSwgYXMgYW4gQURUX0EwNC4KPiA+ID4gPiA+ID4gPgo+ ID4gPiA+ID4gPiA+IEhlcmUncyBvdXRwdXQgZnJvbSBwYXJzaW5nIHRoZSBvcmlnaW5hbCBtc2c6 Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiBtc2cgTmFtZTogR2VuZXJpY01lc3NhZ2UkVjIy Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiBtc2cgTmFtZTogY2EudWhuLmhsN3YyLm1vZGVs LkdlbmVyaWNNZXNzYWdlJFYyMgo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gbXNnIFZlcnNp b246IDIuMgo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gbXNnID86IE1TSAo+ID4gPiA+ID4g PiA+ICoqIE1TSC05LTEgaXM6IEFEVAo+ID4gPiA+ID4gPiA+ICoqIE1TSC05LTIgaXM6IEEwNAo+ ID4gPiA+ID4gPiA+ICoqIE1TSC05LTMgaXM6IDQzCj4gPiA+ID4gPiA+ID4gKiogTVNILTEwIGlz OiA5MDA3NzEzCj4gPiA+ID4gPiA+ID4gKiogTVNILTExIGlzOiBQCj4gPiA+ID4gPiA+ID4gKiog TVNILTEyIGlzOiAyLjIKPiA+ID4gPiA+ID4gPiAqKiBNU0gtMTMgaXM6IDkwMDc3MTMKPiA+ID4g PiA+ID4gPiAqKiBNU0gtMTQgaXM6IG51bGwKPiA+ID4gPiA+ID4gPiAqKiBNU0gKPiA+ID4gPiA+ ID4gPiAqKiBFVk4KPiA+ID4gPiA+ID4gPiBjYS51aG4uaGw3djIuSEw3RXhjZXB0aW9uOiBDYW4n dCBYTUwtZW5jb2RlIGEKPiA+ID4gPiA+ID4gR2VuZXJpY01lc3NhZ2UuICBNZXNzYWdlCj4gPiA+ ID4gPiA+ID4gbXVzdCBoYXZlICBhIHJlY29nbml6ZWQgc3RydWN0dXJlLgo+ID4gPiA+ID4gPiA+ ICAgICAgICBhdAo+ID4gPiA+IGNhLnVobi5obDd2Mi5wYXJzZXIuWE1MUGFyc2VyLmRvRW5jb2Rl KFhNTFBhcnNlci5qYXZhOjI1MSkKPiA+ID4gPiA+ID4gPiAgICAgICAgYXQgY2EudWhuLmhsN3Yy LnBhcnNlci5QYXJzZXIuZW5jb2RlKFBhcnNlci5qYXZhOjIyMSkKPiA+ID4gPiA+ID4gPiAgICAg ICAgYXQgQUJQYXJzZS5tYWluKEFCUGFyc2UuamF2YTo3OSkKPiA+ID4gPiA+ID4gPgo+ID4gPiA+ ID4gPiA+IEFuZCBoZXJlJ3Mgb3V0cHV0IGZyb20gcGFyc2luZyB0aGUgbW9kaWZpZWQgbXNnCj4g PiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4KPiA+ID4gPgo+ID4gKE1TSDo7flwmOkhCT0M6QTpIQk9D OkE6MjAwNTEyMTUyMzUxOjpBRFQ7QTA0OjQzOlA6Mi4yOjkwMDc3MTM6OkFMOiIKPiA+ID4gPiA+ ID4gIjoKPiA+ID4gPiA+ID4gPiApCj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiBtc2cgTmFt ZTogQURUX0EwNAo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gbXNnIE5hbWU6IGNhLnVobi5o bDd2Mi5tb2RlbC52MjIubWVzc2FnZS5BRFRfQTA0Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4g PiBtc2cgVmVyc2lvbjogMi4yCj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiBtc2cgPzogTVNI Cj4gPiA+ID4gPiA+ID4gKiogTVNILTktMSBpczogQURUCj4gPiA+ID4gPiA+ID4gKiogTVNILTkt MiBpczogQTA0Cj4gPiA+ID4gPiA+ID4gKiogTVNILTktMyBpczogbnVsbAo+ID4gPiA+ID4gPiA+ ICoqIE1TSC0xMCBpczogNDMKPiA+ID4gPiA+ID4gPiAqKiBNU0gtMTEgaXM6IFAKPiA+ID4gPiA+ ID4gPiAqKiBNU0gtMTIgaXM6IDIuMgo+ID4gPiA+ID4gPiA+ICoqIE1TSC0xMyBpczogOTAwNzcx Mwo+ID4gPiA+ID4gPiA+ICoqIE1TSC0xNCBpczogbnVsbAo+ID4gPiA+ID4gPiA+ICoqIE1TSAo+ ID4gPiA+ID4gPiA+ICoqIEVWTgo+ID4gPiA+ID4gPiA+ICoqIFBJRAo+ID4gPiA+ID4gPiA+ICoq IE5LMQo+ID4gPiA+ID4gPiA+ICoqIFBWMQo+ID4gPiA+ID4gPiA+ICoqIFBWMgo+ID4gPiA+ID4g PiA+ICoqIE9CWAo+ID4gPiA+ID4gPiA+ICoqIEFMMQo+ID4gPiA+ID4gPiA+ICoqIERHMQo+ID4g PiA+ID4gPiA+ICoqIFBSMQo+ID4gPiA+ID4gPiA+ICoqIEdUMQo+ID4gPiA+ID4gPiA+ICoqIElO U1VSQU5DRQo+ID4gPiA+ID4gPiA+ICoqIEFDQwo+ID4gPiA+ID4gPiA+ICoqIFVCMQo+ID4gPiA+ ID4gPiA+ICoqIFVCMgo+ID4gPiA+ID4gPiA+IG1lc3NhZ2UgaXMgaW5zdGFuY2VvZiBBRFRfQTA0 Cj4gPiA+ID4gPiA+ID4gPD94bWwgdmVyc2lvbj0iMS4wIj8+Cj4gPiA+ID4gPiA+ID4gPEFEVF9B MDQgeG1sbnM9InVybjpobDctb3JnOnYyeG1sIj4KPiA+ID4gPiA+ID4gPiAgICA8TVNIPgo+ID4g PiA+ID4gPiA+ICAgICAgICA8TVNILjE+OjwvTVNILjE+Cj4gPiA+ID4gPiA+ID4gICAgICAgIDxN U0guMj47flwmYW1wOzwvTVNILjI+Cj4gPiA+ID4gPiA+ID4gICAgICAgIDxNU0guMz5IQk9DPC9N U0guMz4KPiA+ID4gPiA+ID4gPiAgICAgICAgPE1TSC40PkE8L01TSC40Pgo+ID4gPiA+ID4gPiA+ ICAgICAgICA8TVNILjU+SEJPQzwvTVNILjU+Cj4gPiA+ID4gPiA+ID4gICAgICAgIDxNU0guNj5B PC9NU0guNj4KPiA+ID4gPiA+ID4gPiAgICAgICAgPE1TSC43Pgo+ID4gPiA+ID4gPiA+ICAgICAg ICAgICAgPFRTLjE+MjAwNTEyMTUyMzUxPC9UUy4xPgo+ID4gPiA+ID4gPiA+ICAgICAgICA8L01T SC43Pgo+ID4gPiA+ID4gPiA+ICAgICAgICA8TVNILjk+Cj4gPiA+ID4gPiA+ID4gICAgICAgICAg ICA8Q01fTVNHLjE+QURUPC9DTV9NU0cuMT4KPiA+ID4gPiA+ID4gPiAgICAgICAgICAgIDxDTV9N U0cuMj5BMDQ8L0NNX01TRy4yPgo+ID4gPiA+ID4gPiA+ICAgICAgICA8L01TSC45Pgo+ID4gPiA+ ID4gPiA+ICAgICAgICA8TVNILjEwPjQzPC9NU0guMTA+Cj4gPiA+ID4gPiA+ID4gICAgICAgIDxN U0guMTE+UDwvTVNILjExPgo+ID4gPiA+ID4gPiA+ICAgICAgICA8TVNILjEyPjIuMjwvTVNILjEy Pgo+ID4gPiA+ID4gPiA+ICAgICAgICA8TVNILjEzPjkwMDc3MTM8L01TSC4xMz4KPiA+ID4gPiA+ ID4gPiAgICAgICAgPE1TSC4xNT5BTDwvTVNILjE1Pgo+ID4gPiA+ID4gPiA+ICAgICAgICA8TVNI LjE2PiIiPC9NU0guMTY+Cj4gPiA+ID4gPiA+ID4gICAgPC9NU0g+Cj4gPiA+ID4gPiA+ID4gICAg PEVWTj4KPiA+ID4gPiA+ID4gPiAgICAgICAgPEVWTi4xPkEwNDwvRVZOLjE+Cj4gPiA+ID4gPiA+ ID4gICAgICAgIDxFVk4uMj4KPiA+ID4gPiA+ID4gPiAgICAgICAgICAgIDxUUy4xPjIwMDUxMjE1 MjM1MTwvVFMuMT4KPiA+ID4gPiA+ID4gPiAgICAgICAgPC9FVk4uMj4KPiA+ID4gPiA+ID4gPiAg ICA8L0VWTj4KPiA+ID4gPiA+ID4gPiA8L0FEVF9BMDQ+Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ ID4gPgo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogaGw3YXBpLWRldmVsLWFkbWluQGxpc3RzLnNvdXJj ZWZvcmdlLm5ldAo+ID4gPiA+ID4gPiA+ID4gW21haWx0bzpobDdhcGktZGV2ZWwtYWRtaW5AbGlz dHMuc291cmNlZm9yZ2UubmV0XSBPbgo+ID4gPiA+ID4gPiBCZWhhbGYgT2YgQnJ5YW4KPiA+ID4g PiA+ID4gPiA+IFRyaXBwCj4gPiA+ID4gPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDEw LCAyMDA2IDE6MjcgUE0KPiA+ID4gPiA+ID4gPiA+IFRvOiBzcHJpbmdsZUBwb2ludHZpc3RhLmJp ego+ID4gPiA+ID4gPiA+ID4gQ2M6IGhsN2FwaS1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQK PiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbSEFQSS1kZXZlbF0gRGV0ZW1pbmluZyB0aGUg TWVzc2FnZSB0eXBlIGluCj4gPiA+ID4gPiA+ID4gPiBBcHBsaWNhdGlvbi5wcm9jZXNzTWVzc2Fn ZSguLi4pCj4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiA+IEhp IFN0ZXZlLAo+ID4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiA+IFRoZSBtZXNzYWdlIHR5cGUs IGV2ZW50LCBhbmQgcG9zc2libHkgc3RydWN0dXJlIHNob3VsZCBiZQo+ID4gPiA+ID4gPiBpbiBm aWVsZAo+ID4gPiA+ID4gPiA+ID4gTVNILTkuIEFjdHVhbGx5IGlmIHRoZXkgYXJlIHRoZXJlLCBI QVBJIHNob3VsZAo+ID4gbm90IHVzZSB0aGUKPiA+ID4gPiA+ID4gPiA+IEdlbmVyaWNNZXNzYWdl IGNsYXNzLCBhbmQgeW91IHNob3VsZCBiZSBhYmxlIHRvIHRlbGwKPiA+ID4gPiB3aGF0IGtpbmQK PiA+ID4gPiA+ID4gPiA+IG9mIG1lc3NhZ2UgaXQgaXMgZnJvbSB0aGUgY2xhc3MuIE1heWJlIHRo ZXNlIGRhdGEgYXJlCj4gPiA+ID4gPiA+IG1pc3NpbmcgZnJvbSB0aGUKPiA+ID4gPiA+ID4gPiA+ IG1lc3NhZ2U/Cj4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4gQnJ5YW4KPiA+ID4gPiA+ ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiBPbiAxLzkvMDYsIFN0ZXZlIFByaW5nbGUgPHN0ZXZlQHBy aW5nbGUuaG0+IHdyb3RlOgo+ID4gPiA+ID4gPiA+ID4gPiBDb3VsZCBzb21lb25lIHBsZWFzZSB0 ZWxsIG1lIGhvdyBvbmUgZ29lcyBhYm91dAo+ID4gPiA+ID4gPiA+ID4gPiBkZXRlcm1pbmluZwo+ ID4gPiA+ID4gPiA+ID4gd2hhdCB0eXBlCj4gPiA+ID4gPiA+ID4gPiA+IG9mIG1lc3NhZ2UgaGFz IGJlZW4gcmVjZWl2ZWQgaW4gdGhlCj4gPiA+ID4gPiA+ID4gPiBBcHBsaWNhdGlvbi5wcm9jZXNz TWVzc2FnZShNZXNzYWdlCj4gPiA+ID4gPiA+ID4gPiA+IGluKSBtZXRob2Q/Cj4gPiA+ID4gPiA+ ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+IEhlcmUncyBhIGNvZGUgc25pcHBldCwgd2hpY2ggaXMg YmVpbmcgc2VudCBhbgo+ID4gQURUX0EwMSBtc2csCj4gPiA+ID4gPiA+ID4gPiBidXQgSSBoYXZl Cj4gPiA+ID4gPiA+ID4gPiA+IG5vIGlkZWEgaG93IHRvIGRldGVybWluZSB0aGF0IGl0IGlzIGFu IEFEVF9BMDEuICBBbGwgSQo+ID4gPiA+ID4gPiA+ID4gPiB3YW50Cj4gPiA+ID4gPiA+ID4gPiB0 byBkbyBpcwo+ID4gPiA+ID4gPiA+ID4gPiBkZXRlcm1pbmUgd2hpY2ggbWVzc2FnZSB0eXBlIHdh cyBzZW50LCBnZXQgdGhlIGRhdGEgSQo+ID4gPiA+ID4gPiA+ID4gPiBuZWVkLAo+ID4gPiA+ID4g PiA+ID4gdGhlbiBzZW5kCj4gPiA+ID4gPiA+ID4gPiA+IGFuIEFDSy4KPiA+ID4gPiA+ID4gPiA+ ID4KPiA+ID4gPiA+ID4gPiA+ID4gcHVibGljIGNsYXNzIEFCQXBwbGljYXRpb24gaW1wbGVtZW50 cyBBcHBsaWNhdGlvbiB7Cj4gPiA+ID4gPiA+ID4gPiA+IC4uLgo+ID4gPiA+ID4gPiA+ID4gPiAg ICBwdWJsaWMgTWVzc2FnZSBwcm9jZXNzTWVzc2FnZShNZXNzYWdlIGluKSB0aHJvd3MKPiA+ID4g PiA+ID4gPiA+IEFwcGxpY2F0aW9uRXhjZXB0aW9uCj4gPiA+ID4gPiA+ID4gPiA+ICAgICAgICB7 Cj4gPiA+ID4gPiA+ID4gPiA+ICAgICAgICBNZXNzYWdlIG91dCA9IG51bGw7Cj4gPiA+ID4gPiA+ ID4gPiA+ICAgICAgICAgICAgICAgIFBpcGVQYXJzZXIgcGFyc2VyID0gIG5ldyBQaXBlUGFyc2Vy KCk7Cj4gPiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+ICAgICAgICB0cnkKPiA+ID4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgewo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gU3lzdGVt Lm91dC5wcmludGxuKCJcbm1zZyBOYW1lOiAiICsKPiA+ID4gPiA+ID4gPiA+IGluLmdldE5hbWUo KSk7Cj4gPiA+ID4gPiA+ID4gPiA+Cj4gPiBTeXN0ZW0ub3V0LnByaW50bG4oIlxubXNnIE5hbWU6 ICIgKwo+ID4gPiA+ID4gPiA+ID4gPiBpbi5nZXRDbGFzcygpLmdldE5hbWUoKSk7Cj4gPiA+ID4g PiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgU3lzdGVtLm91dC5wcmludGxuKCJcbm1z Zwo+ID4gPiA+IFZlcnNpb246ICIgKwo+ID4gPiA+ID4gPiA+ID4gPiBpbi5nZXRWZXJzaW9uKCkp Owo+ID4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgIFN5c3RlbS5vdXQucHJp bnRsbigiXG5tc2cgPzogIiArCj4gPiA+ID4gPiA+ID4gPiA+IGluLmdldCgiTVNIIikuZ2V0TmFt ZSgpKTsKPiA+ID4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICAgICAgICBTdHJpbmdbXSBuYW1lcyA9IGluLmdldE5hbWVzKCk7Cj4gPiA+ID4gPiA+ID4gPiA+ Cj4gPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgZm9yIChpbnQgaSA9IDA7 IGkgPAo+ID4gPiA+IG5hbWVzLmxlbmd0aDsgaSsrKQo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gU3lz dGVtLm91dC5wcmludGxuKCIqKiAiICsKPiA+ID4gPiA+ID4gPiA+IG5hbWVzW2ldKTsKPiA+ID4g PiA+ID4gPiA+ID4gLi4uCj4gPiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+IEhlcmUn cyB0aGUgb3V0cHV0Ogo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4gPiBtc2cgTmFt ZTogR2VuZXJpY01lc3NhZ2UkVjIyCj4gPiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+ IG1zZyBOYW1lOiBjYS51aG4uaGw3djIubW9kZWwuR2VuZXJpY01lc3NhZ2UkVjIyCj4gPiA+ID4g PiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+IG1zZyBWZXJzaW9uOiAyLjIKPiA+ID4gPiA+ID4g PiA+ID4KPiA+ID4gPiA+ID4gPiA+ID4gbXNnID86IE1TSAo+ID4gPiA+ID4gPiA+ID4gPiAqKiBN U0gKPiA+ID4gPiA+ID4gPiA+ID4gKiogRVZOCj4gPiA+ID4gPiA+ID4gPiA+ICoqIFBJRAo+ID4g PiA+ID4gPiA+ID4gPiAqKiBOSzEKPiA+ID4gPiA+ID4gPiA+ID4gKiogUFYxCj4gPiA+ID4gPiA+ ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+IFRoYW5rcywKPiA+ID4gPiA+ID4gPiA+ID4gU3RldmUg UFJpbmdsZQo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ ID4gPgo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiA+ID4gPiA+ID4gPiA+ IFRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogU3BsdW5rIEluYy4KPiA+IERvIHlv dSBncmVwCj4gPiA+ID4gPiA+ID4gPiB0aHJvdWdoIGxvZwo+ID4gPiA+ID4gPiA+ID4gPiBmaWxl cyBmb3IgcHJvYmxlbXM/ICBTdG9wISAgRG93bmxvYWQgdGhlIG5ldyBBSkFYIHNlYXJjaAo+ID4g PiA+ID4gPiA+ID4gZW5naW5lIHRoYXQKPiA+ID4gPiA+ID4gPiA+ID4gbWFrZXMgc2VhcmNoaW5n IHlvdXIgbG9nIGZpbGVzIGFzIGVhc3kgYXMgc3VyZmluZyB0aGUKPiA+ID4gPiA+ID4gPiA+ID4g d2ViLgo+ID4gPiA+ID4gPiA+ID4gIERPV05MT0FECj4gPiA+ID4gPiA+ID4gPiA+IFNQTFVOSyEK PiA+ID4gPiA+ID4gPiA+ID4gaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQ9NzYzNyZhbGxvY19p ZD0xNjg2NSZvcD1jbGljawo+ID4gPiA+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiA+ID4gPiA+ID4gPiBIbDdhcGktZGV2ZWwg bWFpbGluZyBsaXN0Cj4gPiA+ID4gPiA+ID4gPiA+IEhsN2FwaS1kZXZlbEBsaXN0cy5zb3VyY2Vm b3JnZS5uZXQKPiA+ID4gPiA+ID4gPiA+ID4KPiA+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2Uu bmV0L2xpc3RzL2xpc3RpbmZvL2hsN2FwaS1kZXZlbAo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiA+ID4gPiA+ID4gPiBU aGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNwbHVuayBJbmMuIERvIHlvdQo+ID4g PiA+ID4gPiBncmVwIHRocm91Z2gKPiA+ID4gPiA+ID4gPiA+IGxvZyBmaWxlcyBmb3IgcHJvYmxl bXM/ICBTdG9wISAgRG93bmxvYWQgdGhlIG5ldyBBSkFYCj4gPiA+ID4gPiA+IHNlYXJjaCBlbmdp bmUKPiA+ID4gPiA+ID4gPiA+IHRoYXQgbWFrZXMgc2VhcmNoaW5nIHlvdXIgbG9nIGZpbGVzIGFz IGVhc3kgYXMKPiA+ID4gPiBzdXJmaW5nIHRoZSAgd2ViLgo+ID4gPiA+ID4gPiA+ID4gRE9XTkxP QUQgU1BMVU5LIQo+ID4gPiA+IGh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkdjM3JmFsbG9jX2lk ODY1Jm9w77+9awo+ID4gPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiA+ID4gPiA+ID4gPiA+IEhsN2FwaS1kZXZlbCBtYWlsaW5nIGxp c3QKPiA+IEhsN2FwaS1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+ID4gPiA+ID4gPiA+ IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2hsN2FwaS1kZXZl bAo+ID4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ ID4gPgo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ ID4gPiA+ID4gVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBTcGx1bmsgSW5jLiBE byB5b3UKPiA+ID4gPiBncmVwIHRocm91Z2gKPiA+ID4gPiA+ID4gbG9nIGZpbGVzIGZvciBwcm9i bGVtcz8gIFN0b3AhICBEb3dubG9hZCB0aGUgbmV3IEFKQVgKPiA+ID4gPiBzZWFyY2ggZW5naW5l Cj4gPiA+ID4gPiA+IHRoYXQgbWFrZXMgc2VhcmNoaW5nIHlvdXIgbG9nIGZpbGVzIGFzIGVhc3kg YXMKPiA+IHN1cmZpbmcgdGhlICB3ZWIuCj4gPiA+ID4gPiA+IERPV05MT0FEIFNQTFVOSyEKPiA+ IGh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkdjM3JmFsbG9jX2lkODY1Jm9w77+9awo+ID4gPiA+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4g PiA+ID4gPiBIbDdhcGktZGV2ZWwgbWFpbGluZyBsaXN0IEhsN2FwaS1kZXZlbEBsaXN0cy5zb3Vy Y2Vmb3JnZS5uZXQKPiA+ID4gPiA+ID4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlz dHMvbGlzdGluZm8vaGw3YXBpLWRldmVsCj4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+Cj4gPiA+ID4g Pgo+ID4gPiA+ID4KPiA+ID4gPiA+Cj4gPiA+ID4gPgo+ID4gPiA+ID4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiA+ID4gPlRoaXMgU0Yu bmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogU3BsdW5rIEluYy4gRG8geW91IGdyZXAKPiA+ID4g PiB0aHJvdWdoIGxvZwo+ID4gPiA+ID5maWxlcyBmb3IgcHJvYmxlbXM/ICBTdG9wISAgRG93bmxv YWQgdGhlIG5ldyBBSkFYIHNlYXJjaCBlbmdpbmUKPiA+ID4gPiA+dGhhdCBtYWtlcyBzZWFyY2hp bmcgeW91ciBsb2cgZmlsZXMgYXMgZWFzeSBhcyBzdXJmaW5nIHRoZSAgd2ViLgo+ID4gPiA+IERP V05MT0FECj4gPiA+ID4gPlNQTFVOSyEgaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWR2MzcmYWxs b2NfaWQ4NjUmb3BpY2sKPiA+ID4gPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiA+ID4gPiA+SGw3YXBpLWRldmVsIG1haWxpbmcgbGlzdCBIbDdhcGkt ZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gPiA+ID4gPmh0dHBzOi8vbGlzdHMuc291cmNl Zm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2hsN2FwaS1kZXZlbAo+ID4gPiA+Cj4gPiA+ID4KPiA+ ID4gPgo+ID4gPgo+ID4gPgo+ID4gPgo+ID4gPgo+ID4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ID5UaGlzIFNGLm5ldCBlbWFpbCBp cyBzcG9uc29yZWQgYnk6IFNwbHVuayBJbmMuIERvIHlvdSBncmVwCj4gPiB0aHJvdWdoIGxvZwo+ ID4gPmZpbGVzIGZvciBwcm9ibGVtcz8gIFN0b3AhICBEb3dubG9hZCB0aGUgbmV3IEFKQVggc2Vh cmNoIGVuZ2luZSB0aGF0Cj4gPiA+bWFrZXMgc2VhcmNoaW5nIHlvdXIgbG9nIGZpbGVzIGFzIGVh c3kgYXMgc3VyZmluZyB0aGUgIHdlYi4KPiA+IERPV05MT0FECj4gPiA+U1BMVU5LISBodHRwOi8v YWRzLm9zZG4uY29tLz9hZF9pZHYzNyZhbGxvY19pZDg2NSZvcGljawo+ID4gPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiA+SGw3YXBpLWRldmVsIG1h aWxpbmcgbGlzdAo+ID4gPkhsN2FwaS1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+ID5o dHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9obDdhcGktZGV2ZWwK PiA+Cj4gPgo+ID4KPgo+Cj4K |