ViREQ ist ihr freier Integrations- und Servicepartner für den neuen Mirth Connect Kommunikationsserver

Mirth Connect 3.7 - Was gibt es Neues?

 

Mirth Connect 3.7 führt dutzende neue Features, Verbesserungen und Fehlerbeseitigungen ein. Die Java-Unterstützung hat sich deutlich erweitert, da Mirth Connect jetzt Java 11 sowie die meisten OpenJDK-Distributionen unterstützt. Die von Mirth Connect verwendeten Datenbankverbindungen können nun in read/write und read-only Pools unterteilt werden, d.h. sie können die Skalierung der Lese-Replikat-Datenbank nutzen, um Mirth Connect in einem Cluster auszuführen.

Apropos Clustering: Mirth Connect hat das Advanced Clustering verbessert, um die garantierte Nachrichtenordnung für einen bestimmten Kanal im gesamten Cluster zu unterstützen! Viele weitere kleinere Verbesserungen wie z.B. die Unterstützung von JavaScript ES6, eine "Keep Connection Open"-Option für den File Writer und mehr.

 

Java 11 Support

Java 11 ist die neueste "Major"-Version von Java, und mit ihr kommen viele großartige Funktionen, wie die Unterstützung von TLS 1.3. Es ist auch die neueste LTS-Version für Oracle-Support-Kunden. Java 8 ist noch nicht EOL, so dass es definitiv noch verwendet werden kann.

Unterstützte Java-Versionen für jede Mirth Connect-Version werden in dieser Tabelle angezeigt:

 

  3.0.2 - 3.1.x 3.2.x - 3.4.x 3.5.x 3.6.x 3.7.x+
Java 6 X - - - -
Java 7 X X - - -
Java 8 X X X X X
Java 9 - - - X X
Java 10 - - - X X
Java 11+ - - - - X

 

OpenJDK Support

Im Januar 2019 wird Oracle keine kostenlosen, öffentlichen Sicherheitsupdates mehr für ihre offiziellen Distributionen von Java 8 anbieten. Java 9 und 10 sind kurzfristige Releases und dies sind bereits EOL. Java 11 wurde veröffentlicht, aber selbst dann bedeutet die neue Lizenzierungsänderung von Oracle, dass Sie Oracle-Support erwerben müssen, um ihr offizielles JDK in Produktion zu verwenden: https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

Aus diesem Grund hat Nextgen die Unterstützung für Mirth Connect auch für andere OpenJDK-Distributionen bereitgestellt. Die offizielle Oracle OpenJDK JDK-Distribution wird empfohlen, da Nextgen und ViREQ damit die meisten Tests durchgeführt hat. Sie können jedoch auch andere Distributionen wie Azul Zulu, AdoptOpenJDK, RedHat OpenJDK oder andere benutzerdefinierte Builds verwenden. Wenn also die Aktualisierungen der öffentlichen Sicherheit für Oracle JDK 8 eingestellt werden, sind Sie nicht gezwungen, Oracle-Support zu erwerben. Sie können jede beliebige Java-Distribution auswählen.

 

Database Connection Pool Options

3 7 0 DatabaseConnectionPoolOptions

In früheren Versionen gab es einen Verbindungspool für die Donkey-Engine (Nachrichtenverarbeitung) und einen separaten Pool für alles Andere, wie Administrator- oder API-Aktionen. In der neuen Version 3.7 wurde dies etwas geändert. Sie haben nun zwei Möglichkeiten:

 

Option 1: Verwenden Sie zwei Pools, einen read/write und einen read-only

  • Dies ist die Voreinstellung in der Version 3.7. Um dies zu aktivieren, setzen Sie dies in mirth.properties: database.enable-read-write-split = true
  • Wenn diese Einstellung aktiviert ist, wird der Datenbankverbindungspool in zwei Teile aufgeteilt: Ein Read-Only-Pool und ein  Read/Write-Pool. Der Read-Only-Pool wird für viele der Aufrufe der Administrator-API verwendet, die nur Daten abrufen. Der Read/Write Pool wird für die gesamte Backend-Message-Verarbeitung sowie für alle Operationen verwendet, die Daten erstellen, ändern oder löschen.

    Wenn die Verbindungspools aufgeteilt sind, können Sie die Einstellungen für den Read-Only-Pool mit den Optionen "database-readonly" separat konfigurieren. Standardmäßig ist keine der Optionen "database-readonly" gesetzt, was bedeutet, dass der Read-Only-Pool standardmäßig die gleiche Konfiguration wie der Haupt-Read/Write-Pool hat.

    Wenn beispielsweise "datenbankreadonly.max-connections" nicht gesetzt ist, wird standardmäßig die Einstellung "database.max-connections" verwendet. Wenn Sie also Ihre maximalen Verbindungen für den Read/Write-Pool auf 20 gesetzt haben, wird der Read-Only-Pool auch bis zu 20 Verbindungen haben, was bedeutet, dass die Gesamtzahl der Datenbankverbindungen höchstens 40 beträgt.

    Mit diesen Einstellungen können Sie auch den Read-Only Connection Pool auf eine völlig andere Datenbankinstanz verweisen. Dies kann sinnvoll sein, wenn Sie eine Master-DB und ein horizontal skalierendes Cluster von Read-Replica-DBs haben. Sie können den Haupt-Read/Write-Pool auf die Master-DB verweisen und stattdessen den Read-Only-Pool auf den Read-Replik-Cluster. Auf diese Weise können Sie den Traffic und die Belastung Ihrer Master-Datenbank reduzieren.

    Bei der Verwendung von Lese-Replikaten sollte jedoch das Konzept der "Replikationsverzögerung" berücksichtigt werden. Das bezieht sich auf die Zeit, die eine Read-Replikat-DB hinter der Master-DB liegt. Wenn Ihre Replikationsverzögerung ausreichend groß ist, können alle vom Read-Only-Pool getroffenen Auswahlen veraltete Informationen zurückgeben, was zu unbeabsichtigten Ergebnissen im Administrator führen kann.

    Der Server speichert interne Caches für Kanäle, Kanalgruppen, Codevorlagen und Codevorlagenbibliotheken. Standardmäßig verwenden diese Caches den Read-Only-Pool. Wenn es sich jedoch um eine Replikationsverzögerung handelt, können Sie mit einer separaten Option, dem "database.write-pool-cache", die Caches so umstellen, dass sie stattdessen den Read/Write-Pool verwenden.

Option 2: Verwenden Sie einen Verbindungstool für alles

  • Um alle von Mirth Connect verwendeten Datenbankverbindungen in einem einzigen Pool zusammenzufassen, setzen Sie dies in mirth.properties: database.enable-read-write-split = false
  • Alle "database-readonly" Optionen werden in diesem Fall ignoriert. Wenn Sie in diesen Modus wechseln, beachten Sie, dass Sie möglicherweise "database.max-connections" erhöhen möchten, um den Wert "database-readonly.max-connections" zu kompensieren, der nicht mehr verwendet wird

 

Features / Verbesserungen

  • JavaScript ES6: Es gibt eine neue Einstellung für mirth.properties, die bestimmt, welche JavaScript/ECMAScript-Version die Rhino-Engine verwenden soll. Für migrierte Server bleibt die Einstellung als "Standard" erhalten, so dass sich kein Verhalten ändert. Für Neuinstallationen ist die Einstellung "es6", was einige ES6-spezifische Funktionen wie Pfeilfunktionen ermöglicht.
  • File Writer – Verbindung offen halten: Das Standardverhalten ist, dass File Writer beim Senden der ersten Nachricht eine neue Verbindung öffnen und diese Verbindung für immer offen halten, bis der Konnektor gestoppt wird. In der Version 3.7 gibt es zusätzliche Optionen, so dass Sie wählen können, ob Sie Verbindungen offen halten möchten oder nicht. Wenn Sie die Verbindungen offen halten, können Sie auch wählen, wie lange eine Verbindung im Leerlauf bleiben darf, bevor sie automatisch geschlossen wird.
  • Umgebungsname: Zusätzlich zum Servernamen auf der Registerkarte "Servereinstellungen" gibt es nun ein neues Feld "Umgebungsname". Der Unterschied besteht darin, dass der Umgebungsname pro Datenbank eindeutig ist, während dieser Servername pro Serverinstanz eindeutig ist. Wenn Sie also mehrere Server in einem Cluster haben, gibt es einen einzigen Umgebungsnamen und möglicherweise mehrere Servernamen.
  • Aktivieren / Deaktivieren von Schritten: Filterregeln und Transformatorschritte können nun nach eigenem Ermessen deaktiviert und aktiviert werden. Auf diese Weise können Sie Fehler einfacher beheben, testen und an Änderungen arbeiten, ohne dass sie im Kanal noch aktiviert sind.
  • Administratoreinstellungen zurücksetzen: Es gibt viele versteckte Einstellungen, die auf Ihrem lokalen Computer gespeichert sind, wenn Sie den Administrator verwenden, wie z.B. Spaltengröße/Reihenfolge für die Dashboard-Tabelle. Auf der Registerkarte "Administratoreinstellungen" können Sie nun alle diese Einstellungen vollständig zurücksetzen, wenn Sie möchten.
  • Verdecken Sie die Werte der Konfigurationskartenwerte: Die Werte auf der Registerkarte "Configuration Map" sind nun standardmäßig verdeckt, d.h. sie werden erst dann auf dem Bildschirm angezeigt, wenn Sie den Wert bearbeiten oder die Option "Werte anzeigen" aktivieren.

Advanced Clustering – Guaranteed Message Order (Nextgen Plugin)

Die Advanced Clustering-Erweiterung (kommerzielles Nextgen Plugin) eignet sich hervorragend für die horizontale Skalierung Ihrer Mirth Connect Server. In Verbindung mit einem Load Balancer (wie dem Mirth Appliance Load Balancer oder etwas anderem wie HAproxy) können Sie den Durchsatz erheblich verbessern, indem Sie einem Kanal erlauben, mehrere Server gleichzeitig zu betreiben und auszuführen. 

In einigen Fällen können Sie jedoch auch die Nachrichten für einen bestimmten Kanal in der Reihenfolge verarbeiten lassen. Mit der Version 3.7 ist dies nun mit Advanced Clustering möglich. Eine Option "Guarantee Message Order" kann kanalweise eingestellt werden, so dass Sie die Reihenfolge auf einen Kanal beschränken können, während Sie den Rest allein lassen. Es kann auch auf der Ebene der einzelnen Ziel-Warteschlangen eingestellt werden, wo die Warteschlange nur auf einem einzigen Knoten verarbeitet wird.


User Authorization – Channel Tags / Groups (Nextgen Plugin)

In früheren Versionen konnten Sie bestimmte Kanäle auswählen, auf die eine Rolle beschränkt werden sollte. Dies wurde in der Version 3.7 um zusätzliche Tag-/Gruppenoptionen erweitert. Damit können Sie fein abgestimmte Rollen erstellen. So können Sie beispielsweise festlegen, dass ein bestimmter Benutzer nur Kanäle anzeigen/verwalten kann, die ein bestimmtes Tag haben oder zu einer bestimmten Gruppe gehören.