Develop Reference

HL7 version 2.7 parser using java except Hapi

Is there any good parser which can parser HL7 V2.7 message using Java except HAPI. My goal is to convert the message into a XML file.

There is my own open source alternative called HL7X, which does work with any HL7v2 version. It converts your HL7 String into a XML String.
Example:
MSH|^~\&|||||20121116122025||ADT^A01|5730224|P|2.5||||||UNICODE UTF-8
EVN|A01|20130120151827
PID||0|123||Name^Firstname^^^^||193106170000|w
PV1||E|
Gets transformed to
<?xml version="1.0" encoding="UTF-8"?>
<HL7X>
<HL7X>
<MSH>
<MSH.1>^~\&</MSH.1>
<MSH.6>20121116122025</MSH.6>
<MSH.8>
<MSH.8.1>ADT</MSH.8.1>
<MSH.8.2>A01</MSH.8.2>
</MSH.8>
<MSH.9>5730224</MSH.9>
<MSH.10>P</MSH.10>
<MSH.11>2.5</MSH.11>
<MSH.17>UNICODE UTF-8</MSH.17>
</MSH>
<EVN>
<EVN.1>A01</EVN.1>
<EVN.2>20130120151827</EVN.2>
</EVN>
<PID>
<PID.2>0</PID.2>
<PID.3>123</PID.3>
<PID.5>
<PID.5.1>Name</PID.5.1>
<PID.5.2>Firstname</PID.5.2>
</PID.5>
<PID.7>193106170000</PID.7>
<PID.8>F</PID.8>
</PID>
<PV1>
<PV1.2>E</PV1.2>
</PV1>
</HL7X>

this http://www.dcm4che.org/confluence/display/ee2/Home open source Java software can receive various HL7 messages through the MLLP protocol, convert them to XML, run through XSLT transformer and then load them into database and serve to DICOM clients as needed. In order to do this in the code base there is the HL7->XML code. Just find it, copy/paste it and use it.
Once I knew where exactly this code is as I was troubleshooting message character set problem. At that time I have found that the HL7 parser is rather simple-minded and can understand only 1 character set provided in the configuration. It does not read/use character set (MSH-18, Table 0211, Grahame Grieve's encoding tips) provided in the messages neither does it support switching character sets during the message decoding (see chapter "Escape sequences supporting multiple character sets" in HL7 specification).
So I know the parser code is there. It is in Java. It produces XML inputs for the customer-specific XSLT transformation script. It should be quite easy to reuse.
You should be able to find it by yourself. Otherwise your question would turn out as plain finding a tool §4 is an off-topic :)

Java WebService adding CDATA field in response

I'm working on a webservice where, i created the wsdl and generated the java classes using apache axis2.
The problem I'm trying to solve is, while creating web service response I have to set text with special characters like Books & Pens Or Value is <10> in some of the fields. I am looking for ways to just put these field content in CDATA sections.
Example response my WebService has to send:
<BOOKSHOP>
<ITEM><![CDATA[BOOKS & PENS]]></ITEM>
</BOOKSHOP>
I'm not able to find a way to do this. I have googled but found no solution.
Any help would be really appreciated.
I'm aware of converting these special characters explicitly into & amp ; or & lt; but that does not work for us.
Also, We want to put just the required fields in CDATA and not entire XML response.
I tried #XmlCDATA but it works only if my text is XML structured.

Convert DFDL to XML

I'm trying to parse a web service response message in the following format (message tree):
Message
Properties
Properties..[]
DFDL
ObjectIWantUnmarshalled
AllItsDataIwant[]
And unmarshal the "ObjectIWantUnmarshalled". However, this data is in DFDL format.
In my request, I use the following line in order to format from XML to DFDL:
Document outDocument = outMessage.createDOMDocument(MbDFDL.PARSER_NAME);
But there doesn't seem to be a way to to the opposite, of DFDL to XML.
I have tried:
Document outDocument = inMessage.createDOMDocument(MbXMLNSC.PARSER_NAME);
As well as other attempts to simply unmarshal the data directly from the MbMessage:
jaxbContext_COBOL.createUnmarshaller().unmarshal(inMessage.getDOMDocument())
But I have not been able to get a Document node this way, or any other way, it is always null.

Probably a lot too late, but you were going about this the wrong way.
When using WMB and IIB you should use the built-in XML support - not the javax.XML.* class library. So instead of using the JAXB unmarshaller, you should
create an XMLNSC tree under the output message root
copy the input DFDL message tree to the output XMLNSC message tree ( one line )
...and the message flow will serialize ( unmarshall ) the tree as XML whenever it needs to - when it encounters an output node, or when you call outMessage.toBitstream().

XML format received is not well formed?? why?

I am trying to write a ASP.net Web API that sends XML files from the database and recieve/read it on android
The XML file that I send is something like this
<ArrayOfMerchant xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/MvcApplication1.Models">
<Merchant>
<Address>ABC</Address>
<City>HHHH</City>
<Country>EEEE</Country>
<Id>1</Id>
<Latitude/>
<Longitude/>
<Name>Some store</Name>
</Merchant>
</ArrayOfMerchant>
Opened on browser and it looks fine.
On the Android side I am trying to receive and read it with HttpURLConnection.
Everything works , but when I try to convert the Input-stream into string, the string is something like
String = [{"Id":1,"Name":"Some store","Address":"ABC","City:"EEEE","Country":"Canada","Longitude":"","Latitude":""}]
Question:
1)Why does it display differently with different markup and also different ordering of the elements?
2)How can I receive / retrieve it as a normal XML file so I can parse it?

1) I dot know, depends on your ASP code and configuration. You can try to change parameters of your HTTP request to see how your ASP app respond when you change Accept header or User-Agent. There are some tools.
2) Actually, you don't need XML to parse the data .

Error while calling WebService Using CXF 2.3.3Unmarshalling Error: unexpected element

I'm getting the following error when I call the WebService using CXF 2.2.3. The error occurs when the WebService returns the data.
Unmarshalling Error: unexpected element ( uri:"http://service.claimservice.hospital.www.wcb.ab.in", local:"accidentAddress"). Expected elements are <{http://domain.claimservice.hospital.www.wcb.ab.in}employerContactInfo>,<{http://domain.claimservice.hospital.www.wcb.ab.in}accidentCountry>,<{http://domain.claimservice.hospital.www.wcb.ab.in}denialReason>,<{http://domain.claimservice.hospital.www.wcb.ab.in}workerContactInfo>,<{http://domain.claimservice.hospital.www.wcb.ab.in}accidentPostalCode>,<{http://domain.claimservice.hospital.www.wcb.ab.in}entitlementDecisionDate>,
Can anyone tel me if it is possible to get rid of this error by changing my wsdl?
Thanks,

The short answer is that the request contains an element in the XML with a fully-qualified name of {http://service.claimservice.hospital.www.wcb.ab.in}accidentAddress in a location for which only the elements on the 'Expected elements' list are valid.
This is based on the unmarshaller's context which is, ultimately, based on the schema(s) from which the datatypes were read (should be the schemas presented/imported into the WSDL 'types' section).
Based on the information in the question, the response pipeline is the problem, so the server-side marshaller and client-side unmarshaller are out of sync (were created from different schema(s)).
Suggested Troubleshooting (assuming use of a marshaller object on the server-side):
Capture the XML for the problematic message.
Determine if the XML is consistent with what is presented in the types section of the WSDL.
IF the XML is compliant with the WSDL, then the likely issue is that the client-side unmarshaller has been supplied with datatypes that are different than those presented in the WSDL.
IF the XML is not compliant with the WSDL, the server-side XML marshaller is creating an incorrect message (or it is creating a correct message and the WSDL is incorrect...it happens). In this case, the marshaller may have been created against outdated datatypes.
If not using a marshaller object and instead creating the service response by hand, the problem is that the accidentAddress element is being created when it is not a valid part of the XML message or it is a valid part of the message but in the wrong location relative to containing element.
This is a little long-winded, but hopefully contains enough information to help out.