web stats
Mirth Community - View Single Post - xml namespace issues with routeMessage when not queued
View Single Post
Old 05-01-2012, 09:19 AM
whmurray whmurray is offline
Mirth Newb
Join Date: Feb 2012
Posts: 14
whmurray is on a distinguished road

The top level channel has a "javaScript writer" destination. The following javaScript is used to read a CCD file and send it to the next channel:

function ProcessFile(filePath) {
	var contents = FileUtil.read(filePath);
	var vmResponse = router.routeMessage('ProcessCCD', contents, false); // cnl name, msg, queue, sync
	var theJsonText = new XML(vmResponse.getMessage()).JSONText;
	var hl7Doc = JSON.parse(theJsonText);
	return hl7Doc;
The channel the above calls has and xml template where I extract some fixed parts of the CCD, then go into javaScript to digest it further. It works if the above routeMessage call uses que. However, if it does not, the second channel was failing.

After a lot of debugging (see note below), I "fixed" this by adding an initial javascript step in my second channel to set the namespace as follows:

default xml namespace = msg.namespace();
I also added the sameline at the beginning of my javaScript destination xfrom (second channel). I also tried with and without the "strip namespaces" option which did not seem to affect results at all.
I know that mirth prepends and postpends some script to my scripts before they are compiled (see below), and there is this line it adds:

if (msg.namespace("") != undefined) { default xml namespace = msg.namespace(""); } else { default xml namespace = ''; }
All I know is that after I set the default xml namespace in the 2 places mentioned, my "ProcessCCD" channel works the same way regardless of if it is called as queued or not. Also, to answer your question regarding the input data to the second channel, I could not tell any difference in the input data for either queued or non queued. My conclusion is that in the queued path, something is setting the default xml namespace and that is not being done in the non queued path.

Regarding debugging: Having searched the forums, I could only find people suggesting to use the logger for debugging. Kinda of a step back in time I think. I spent 2 days to try to understand if something better is possible and in fact I found it is easy to debug Mirth scripts (single step, breakpoints, context, etc) once you understand the technique. I will post seperately if there is interest and if nobody tells me not to. I has saved me enormous time and provided great insight into what Mirth is doing.
Reply With Quote