Difference in using seg.name() between Mirth Connect versions

Sat, Aug 21, 2010 One-minute read

Ran into something recently when moving a channel I inherited from an instance of Mirth Connect 1.8.2.4472 to a server running 1.8.1.4211.

I was seeing the following error in the log when messages were hitting the newly moved channel:

ERROR-300: Transformer error
ERROR MESSAGE:  Error evaluating transformer
com.webreach.mirth.server.MirthJavascriptTransformerException:
CHANNEL:        MedI - Convert orders to HL7 NEW
CONNECTOR:      sourceConnector
SCRIPT SOURCE:
LINE NUMBER:    378
DETAILS:        TypeError: Cannot call method "toString" of null
        at com.webreach.mirth.server.mule.transformers.JavaScriptTransformer.evaluateScript(JavaScriptTransformer.java:460)
        at com.webreach.mirth.server.mule.transformers.JavaScriptTransformer.transform(JavaScriptTransformer.java:356)
        at org.mule.transformers.AbstractEventAwareTransformer.doTransform(AbstractEventAwareTransformer.java:48)
        at org.mule.transformers.AbstractTransformer.transform(AbstractTransformer.java:197)
        at org.mule.transformers.AbstractTransformer.transform(AbstractTransformer.java:200)
        at org.mule.impl.MuleEvent.getTransformedMessage(MuleEvent.java:251)
        at org.mule.routing.inbound.SelectiveConsumer.isMatch(SelectiveConsumer.java:61)
        at org.mule.routing.inbound.InboundMessageRouter.route(InboundMessageRouter.java:83)
        at org.mule.providers.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:493)
        at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:272)
        at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:231)
        at com.webreach.mirth.connectors.vm.VMMessageReceiver.getMessages(VMMessageReceiver.java:178)
        at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:108)
        at org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:90)
        at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Unknown Source)

Somewhat vague, and it took me a few minutes to track it down.

What it turned out to be was a .toString() in a spot that worked in 1.8.2.4472, but not in 1.8.1.4211.

There was a Javascript transformer that was looping over the input XML and performing different tasks as it found specific segments. The code was as follows:

for each (seg in msg.children()) {

  if (seg.name().toString() == "order") {

Removing the .toString() from seg.name() seems to have solved the issue. So now the code looks like:

for each (seg in msg.children()) {

  if (seg.name() == "order") {