4.2.0 What's New
Mirth Connect 4.2.0 includes new features such as message integrity as well as many smaller changes, updates, and improvements. This release also contains several improvements to commercial extensions.
-
Core Mirth Connect
- New Features
-
Fixed Defects
- Mirth Connect Login with LDAP Plugin Case-sensitivity
- JMS Connectors Failing to Load Classes in Resources
- ER7 Serialization Error when Using
Strip NamespacesandUse Strict Parser - Mirth Connect RPM Failing to Install Using Some RPM Versions
- Restore Config Fails Without "admin" user
- Fixing Errors With Newer JavaFX Versions
- INFO and DEBUG Logger Statements are not Human Readable
- Security Improvements
- Mirth Connect Administrator Launcher
- Commercial Extension Improvements
You can find the list of completed issues for this release here.
We added a new button to the channel configuration screen that will allow users to see a list of ports already in use by other channels. (Community Issue)
We added the username to the warning message to notify the current user that another user has made changes to this channel since opening the Channel Edit panel. (Community Issue)
We added the Channel ID - Message ID and Channel Name columns to the Events screen. This change allows the user to sort on either of these new columns. (Community Issue)
We added the ability to select multiple messages from the Open Text or Open Binary File Dialogs when sending messages to the channel. When multiple files have been selected, the edit window will show "Multiple Messages Selected" and will disable the editing function. Each file will be sent as individual transactions. (Community Issue)
We added 3 new JavaScript utility methods to allow hashing of channel messages. The resulting hex hash can be passed along to destinations for verification of message integrity. For more information, please see the Mirth Connect and JavaScript > Using JavaScript in Mirth Connect section in the Mirth Connect User Guide. (Community Issue)
A SHA-256 hash is now automatically generated for the encoded data of each outgoing message. You can use the ${HASH} velocity variable, which is available as Message Hash in the Destination Mappings list, to send the hash value to the receiving system. For example, using an HTTP Sender, you can add the hash to an HTTP header named hash. (Community Issue)
You can also use the new JavaScript utility methods, described above, to verify the hash of an incoming message. For example, using an HTTP Listener, if you assume the incoming messages include the message hash in a header named hash, you can use the following script in a Source Filter step:
// Get the received hash from the request header
var receivedHash = sourceMap.get('headers').getHeader('hash');
// Generate a hash from the received message content
var generatedHash = HashUtil.generate(msg, 'UTF-8', 'SHA-256');
// Accept the message only if the hashes match
return receivedHash != null && generatedHash != null && generatedHash == receivedHash;
We fixed a defect where JMS connectors failed to find classes in resources that should be available to them. JMS connectors will not fail when using library resources. (Community Issue)
Because the ER7 serialization (strict parser) requires the proper namespace to convert an XML to ER7, we added the required namespace to the XML if it's missing. (Community Issue)
We fixed an issue in which the Mirth Connect RPM package failed to install on some versions of RPM. (Community Issue)
We have added more detailed Server Log error messages for each part of the Server Restore Config when the Restore Config fails. This will help users more accurately identify which part of the Server Restore Config failed and why. (Community Issue)
Using a newer version of JavaFX caused "Invalid function reference" JSExceptions to be sent to the client console log. (Community Issue)
In certain JavaScript coding areas within the channel, previously the logger statements displayed like a variable dump. For example, INFO (filter:?): ParameterizedMessage[messagePattern=Destination Filter Info Test, stringArgs=[], throwable=null]. We fixed the logger statements to be human readable in all locations where this error occurred. (Community Issue)
We updated the Apache commons-text library to version 1.10.0 in Mirth Connect and all of its extensions. This was done to address a critical CVE present in the library. It should be noted that Mirth Connect wasn't using the vulnerable functionality of the library, but it's best practice to update libraries with known critical CVEs. (Community Issue)
We removed the Remove All Events button in the Events screen to comply with CURES certification security requirements. If developers need to remove all events, they can use the Prune Events in the Data Pruner tab of the Settings screen. This is the preferred method to remove/prune events. (Community Issue)
This is not directly tied to the Mirth Connect 4.2.0 release, but worth noting here anyway. We've also released a new version of the Mirth Connect Administrator Launcher (1.3.0).
In case you're not aware, this tool replaces the old/deprecated Java Web Start, and allows you an easy way to launch any version of the Mirth Connect Administrator, using any Java installation you want.
The version of Mirth Connect Administrator Launcher now displays in the title bar. (Community Issue)
Included libraries like log4j, BouncyCastle, and several others have been updated to the latest versions. These are just the libraries used by the launcher itself, and will not affect the actual Connect Administrator that gets launched.
Optional, and in most cases you will not need to set this. However in case you want or need to use a specific installation of JavaFX, you can point to it using this setting.
The Connections table can now be drag-resized at will, in case you have connections with longer names and you can't see the entire name.
The "clear" keystroke in the client console used to be "c", which made it tricky to copy text since it conflicts with Ctrl+C. That has now been changed to "l".
All OCSP requests are now being cached while the launcher is open. In most cases, every single JAR that you download is going to have the same signing cert. So in that scenario, you should now only see a few OCSP requests total, rather than a flood of hundreds of such requests.
In addition, the SYN/connect timeout for CRL/OCSP requests has been reduced from 60s to 10s. This does not eliminate slowdowns if your machine doesn't have any internet at all (or a firewall is dropping packets). But at least now, you should only experience that slowdown on the first launch. After that, those OCSP "null responses" are cached, so it does not attempt to make a request next time.
The required JVM module options were not being set when Java 18+ was used to launch the Administrator. That has been fixed now, so any Java 18+ can be used without launch/login errors.
Certain scenarios could cause the Administrator to crash after launching. This was seen most often on newer versions of macOS, and especially on M1 (AArch64) systems.
OpenJFX 17.0.2 has been included, both the JARs for the classpath as well as native libraries for the JVM library path, for Windows/Linux/macOS and multiple architectures. Whether OpenJFX 11 or 17 gets used depends on the version of Java you're launching with, the operating system you're on, and whether you're on an aarch64 system. As a special case, aarch64 will always use the newer OpenJFX 17.0.2 even when launching with Java 11-16.
The JAVA_HOME environment variable will now be higher in the list when launching the Administrator using the "Default" Java installation.
Previously the launcher would just automatically attempt to find another JVM if the custom Java home was invalid. However that could lead to confusion, because the Administrator may have been launched with a different version of Java than what was expected. Now the launcher will error out if the custom Java home could not be found or is not a valid Java home directory.
We added the username to the warning message to notify the current user that another user has made changes to this channel since opening the Channel History dialog.
The CURES Certification Support is designed to determine if the Event Log has been altered by manually changing the database. If the Event Log has been tampered with, an error message will be sent to the server log. In addition, a Server Event and Error Event will be created, the latter of which can be used to trigger Alerts.
The CURES Certification Support extension is designed to work with or without using the Advanced Clustering extension. When used in conjunction with Advanced Clustering, each server in the cluster verifies its own Event Log.
We fixed a defect with the FHIR Sender where the URI was incorrect whenever the connector retried sending a message. This was due to the FHIR resource path being appended to the URI on each retry. For example, when sending a Bundle resource, if the connector retried sending a message after initially failing, the URI was incorrectly set to https://<destination>/Bundle/Bundle.
We fixed a defect where users were unable to use their LDAP login unless they used all lowercase characters for their username. Users are now able to to use their LDAP login with a case-insensitive username. (Community Issue)
Fixed the SSL Manager advanced setting dialog. Previously if default connector extensions were disabled, the SSL Advanced settings dialog would fail to appear when clicking on the wrench icon in the connector settings.
The User Authorization extension has been renamed to Role-Based Access Control. All references to "User Authorization" in the User and Extension Guides, in-app UI elements, and the GitHub Wiki have been changed to "Role-Based Access Control". Going forward, the User Authorization extension will be referred to as the Role-Based Access Control extension; however, the extension artifacts will still be named "auth".
If a new user was created with the same username as a deleted user, previously it was assigned the roles from the deleted user. To correct this, the role assignments are now updated in the database correctly.
We fixed an issue where whenever a message is retried on an XCPD sender, a new WS security header element is appended to the header rather than it being overwritten. This can make messages very large. Now, the WS security header element will be overwritten with a new one. (Community Issue)
The HDH sender now has the ability to add custom headers to the request whenever sending a message. This new ability is enabled for Basic and Advanced configurations. Like the HTTP Sender, you can choose to create your headers by using the Table or Map options. The headers will be applied to the request prior to the dispatch of the message. (Community Issue)