3.0.0 Upgrade Guide

Message Migration

If you are upgrading to Mirth Connect 3.x from Mirth Connect 2.x, your existing messages will not be upgraded. This includes any queued messages that have not been sent, as well as any historical message records. After upgrading, Mirth Connect 2.x messages will not be available in the Mirth Connect Administrator, but will remain in the database in the OLD_MESSAGE table.

Any messages that were queued at the time of upgrade from 2.x will not be processed. If you would like to ensure these messages are processed, we recommend flushing out all queued messages before upgrading:

For non-polling channels

Pause the channel Wait for all queued messages to finish processing

For polling channels

1. Edit the channel, export the source connector (to have a backup)
2. Change the source connector type to Channel Reader
3. Redeploy the channel
4. Wait for all queued messages to finish processing
5. Edit the channel again, restore the exported source connector, but do not redeploy

Do the above for all channels until there are no more queued messages. If any queued messages cannot be processed because the external system is down, you can search for the queued messages and export them as XML or Plain Text for manual processing later.

To simply remove all queued messages you can remove them from the Message Browser, which should also remove them from the file system, or simply delete the queuestore folder (or individual channel folders inside of queuestore) in your appdata directory.

Channel Updates

The API in Mirth Connect 3.0 has changed dramatically. All old JavaScript references and variables from the Reference List should still work properly, but they may log messages stating the code you are using has been deprecated, and recommend code changes that you should complete. Any deprecated methods may be removed in an upcoming version.

Calls to any unsupported internal Mirth Connect code may have changed and may no longer work. This includes any JavaScript that has to import or reference anything in the com.mirth.connect.* package. If you are using any unsupported internal Mirth Connect classes to perform actions like starting and stopping channels, please take a look at Mirth Connect 3.0's new ChannelUtil API.