|
#1
|
|||
|
|||
|
I have channel that reads a file (which happens to be XML/CCD). THen it passed that file using:
var vmResponse = router.routeMessage('ProcessCCD', contents, true); The second channel ("ProcessCCD") can see the xml ok and I can parse the ccd data content ok. However, If I change the routeMessage call to pass the last parameter as "false" so no que, The second channel gets the xml, but there seems to be a namespace issue. Questions: 1) If I call a channel using routeMessage, and need result data from that channel, then is using the "false" as the last parameter the right thing to do? 2) Why does this change how the second channel sees the xml data? |
|
#2
|
|||
|
|||
|
That's interesting... can you post your channels for reference? Also, when you route the messages with and without queues, what is the difference in the raw data received by the second channel?
|
|
#3
|
|||
|
|||
|
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:
Code:
function ProcessFile(filePath) {
logger.debug(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;
}
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: Code:
default xml namespace = msg.namespace(); 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: Code:
if (msg.namespace("") != undefined) { default xml namespace = msg.namespace(""); } else { default xml namespace = ''; }
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. |
|
#4
|
|||
|
|||
|
** I would love to know that ( debug Mirth scripts )! Please post any info you can on the
(single step, breakpoints, context, etc) , I didn’t even know you could do that. I also thought I stumbled over the multi commenting, where I could highlight and hit a key and a // was placed in front of the lines, am I thinking of something else?
__________________
Mike Caldwell Alliance HealthCare - GE VAR Rocklin, CA Centricity PM/EMR Support - Developer - Network Engineer http://MirthPRO.Com |
|
#5
|
|||
|
|||
|
As Mike Caldwell stated.
I too love to know how to debug without the logger statements. |
|
#6
|
|||
|
|||
|
We're planning on implementing JavaScript debugging features, but in the meantime you can read up on it here: https://developer.mozilla.org/en-US/...cript_Debugger
__________________
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first. ![]()
|
![]() |
| Tags |
| namespace, xml |
| Thread Tools | |
| Display Modes | |
|
|