Tuesday, 19 April 2016

The prefix "s" for element "s:Envelope" is not bound

I've always found the way Mirth handles namespaces in xml painful at best - to strip namespaces or not to strip namespaces! It is particularly painful when you come from the .NET world using the Web Service Sender. Here's an error I have come across a few times now.

Transformer error
ERROR MESSAGE: Error evaluating transformer
com.mirth.connect.server.MirthJavascriptTransformerException:
CHANNEL:    Hunter outbound HL7
CONNECTOR:    Send ORU HL7
SCRIPT SOURCE:    TRANSFORMER
SOURCE CODE:   
209: var responseMessage = destination.getMessage();
210:
211: //logger.info(responseMessage);
212:
213: // Wrap the SOAP string into an XML object so that we can parse it.
214: var soapMsg = new XML(responseMessage);
215:
216: // Find the XML tag that has the RTF file. It's Base-64 encoded
217: var base64EncodedRtf = soapMsg..*::FileByteStream.toString();
218:
LINE NUMBER:    214
DETAILS:    TypeError: The prefix "s" for element "s:Envelope" is not bound.
    at 6d9945af-8559-413e-8652-3c6747667665:214 (doTransform)
    at 6d9945af-8559-413e-8652-3c6747667665:335 (doScript)
    at 6d9945af-8559-413e-8652-3c6747667665:337
    at com.mirth.connect.server.transformers.JavaScriptFilterTransformer$FilterTransformerTask.call(JavaScriptFilterTransformer.java:154)
    at com.mirth.connect.server.transformers.JavaScriptFilterTransformer$FilterTransformerTask.call(JavaScriptFilterTransformer.java:119)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

clip_image001

So in this Channel I have a few destinations doing separate things, but the last two are supposed to pull in a medical document, then insert this into an HL7 message and send it.

It gets the document fine, but then the "Send ORU HL7" throws the above error.

Well, the error certainly looks like a namespace problem, so I jump into the channels Set Date Types dialog and start making adjustments.

clip_image002

As you can see here, I am already not stripping the namespace, but as I try changing to different combinations of stripping and not stripping I still cannot fix the problem. Finally I concede that I need to focus on the destination prior, the "Request Document From Corridor". It is indeed that message that returns the "s:" namespace.

clip_image003

So I adjust it's namespace stripping too without any luck. But then I had a thought - what if I treat it as a different datatype. Even though it is returning a xml message I simply tell Mirth it is HL7 V2.x

clip_image004

That was it. Problem solved. I certainly get why this workaround works, but what I don't really understand is why I had to do it that way.

I'd love any feedback on other peoples experiences here, an I can look at doing a future post following up on this.

No comments:

Post a Comment