All Versions of Mirth Connect
"When in doubt, log it out"
There are a few ways to do this in Mirth Connect without access to the application config, its logs, or the host:
- Make calls to
logger
. In your case, since you don't have access to the server, you will have to do this as logger.error("your data")
as the logger level is set at the server in log4j.properties
. These will be visible in the MC dashboard which provides a partial view of the log. A good practice would be to prepend your logger statement with the location from where it came from, for example logger.info(channelName + " transformer step 1 " + "your other data")
otherwise other team members may be left wondering what channel originated the log message on the console.
- Use the Mirth Connect maps to log detailed information about variable values. Be wary of this as putting large objects in maps, particularly the
channelMap
and globalChannelMap
will make your message payloads excessively large. Of course you can also use channel map variables to store informational data like you hit a piece of code. For example: $c('patient is in table', true)
which is also the same as channelMap.put('patient is in table', true)
- At the extreme end, you can intentionally overwrite your messages with only debug data. This is useful in cases where you need to log out large objects. It adds a lot of complexity to your debugging though.
For either case make your recorded values:
- only recorded when a
debug
flag is set - this ensures your logging and debugging is not spamming data out when you are not actively needing to capture the data
- have meaningful messages - Don't just log out
"x = 12"
, log out "MsgId: " + msg.getMessageId() + " in method foobar() had x = 12"
New in Mirth Connect 4.0
MC 4.0 introduced a means to launch the Rhino Debugger from Mirth connect. See the release notes for MC 4.0 to learn how to use it.