Mirth-Migration

Diese Seite beantwortet die Frage, die vor jedem Wechsel steht: Was von meinem Mirth läuft in Brio-IO weiter — und was nicht? Sie beschreibt den heutigen Stand, ohne Zusagen für später.

Die kurze Antwort

Die Skript-Mechanik kommt unverändert mit. E4X-Brackets, Mutation, msg am Ende zurückgeben — und selbst die Komponenten-Pfade bleiben, wie du sie kennst, weil beide Systeme positional nummerieren:

// Läuft in Mirth. Läuft in Brio-IO js-legacy. Unverändert.
var nachname = msg['PID']['PID.5']['PID.5.1'].toString();

Das aus Mirth gewohnte new XML(msg) entfällt sogar — msg ist in Rhino bereits ein E4X-Objekt.

Was nicht mitkommt, sind die Stellen, an denen Mirth-Skripte die Plattform selbst ansprechen: Channel-zu-Channel-Dispatch, direkter Connector-Versand und Mirth-eigene Java-Klassen. Dazu unten mehr.

Der Importer

Brio-IO liest eine exportierte Mirth-Channel-XML oder ein ZIP-Archiv und legt daraus Connectoren und Channels an. Vor dem Import bekommst du eine Vorschau, die zeigt, was passieren würde — sie ändert nichts.

Transporte, die abgebildet werden

Mirth	Brio-IO
HTTP Listener	http-listener
HTTP Sender	http-sender
TCP Listener	mllp-listener
TCP Sender	mllp-sender
File Reader	file-reader
File Writer	file-writer
Database Reader	jdbc-reader
Database Writer	jdbc-writer
JMS Listener	jms-listener
JMS Sender	jms-sender
SMTP Sender	smtp-sender

Ein „TCP Listener” aus Mirth wird bewusst auf mllp-listener abgebildet — in der Praxis trägt ein Mirth-TCP-Listener im Healthcare-Umfeld fast immer HL7-über-MLLP.

Transporte, die nicht abgebildet werden

Ein DICOM Listener wird als Source-Transport erkannt, aber nicht abgebildet. Der Importer meldet ihn als nicht unterstützt. Dasselbe gilt für jeden anderen Transport, der nicht in der Tabelle oben steht.

Wichtig für die Planung: Eine nicht unterstützte Destination lässt den Import des Channels nicht scheitern — sie wird übersprungen und als Warnung gemeldet. Der Rest des Channels kommt an. Ein nicht unterstützter Source dagegen macht den Channel unbrauchbar, weil ihm der Eingang fehlt.

Wovor der Importer warnt

Beim Import werden Skripte auf bekannte, nicht portierbare Aufrufe geprüft. Diese Warnungen erscheinen im Import-Ergebnis:

Erkanntes Muster	Warnung
router.routeMessage(...)	steht in Brio-IO nicht zur Verfügung — stattdessen Destinations am Channel verwenden
$co(...)	Connector-Versand steht nicht zur Verfügung — stattdessen Destinations
Packages.com.mirth.*	Mirth-eigene Java-Pakete stehen nicht zur Verfügung

Die Skripte werden dabei nicht umgeschrieben. Sie kommen unverändert an und werden auf js-legacy gesetzt — die Warnung sagt dir, wo du von Hand nacharbeiten musst.

Die drei Muster, die du ersetzen musst

router.routeMessage() → Destination am Channel

In Mirth schickt ein Skript eine Nachricht in einen anderen Channel. In Brio-IO ist das keine Skript-Operation, sondern Konfiguration: Der Zielkanal hängt als Destination am Channel.

Wenn du echten Channel-zu-Channel-Transport brauchst, verbindest du heute einen http-sender mit dem http-listener des Zielkanals. Einen eigenen Channel-Connector gibt es noch nicht.

$co(...) → Destination am Channel

Derselbe Gedanke: Wohin eine Nachricht geht, steht im Channel, nicht im Skript. Das ist der Grund, warum man im Message-Browser sehen kann, wohin eine Nachricht lief — bei einem Versand aus dem Skript heraus wäre das unsichtbar.

Packages.com.mirth.* → nicht ersetzbar

Mirth-eigene Java-Klassen gibt es in Brio-IO nicht. Skripte, die davon Gebrauch machen, brauchen eine fachliche Neufassung. Das ist der einzige der drei Punkte, für den es keinen mechanischen Ersatz gibt.

Nach dem Import: der Migrationsweg

1. Alles läuft zunächst auf js-legacy. Der Importer setzt importierte Skripte automatisch darauf. E4X-Mechanik und Komponenten-Pfade laufen unverändert weiter. Ein Blick in den Message-Browser bestätigt dir für jede empfangene Nachricht die kanonische XML, gegen die deine Pfade laufen.
2. Skript für Skript auf Groovy oder GraalJS umstellen — die Bracket-Strings durch Property-Zugriff ersetzen (msg.PID.PID_5.PID_5_1, in Groovy mit .text()). Siehe Transformer-Handbuch.
3. Fertig, wenn kein js-legacy-Skript mehr übrig ist — dann verschwindet auch die Deprecation-Warnung beim Deploy.

Das ist ausdrücklich kein Big Bang. Ein Channel darf einen Groovy-Filter und einen js-legacy-Transformer gleichzeitig tragen.

Rhino hat ein Ablaufdatum

js-legacy ist bewusst deprecated. Jeder Deploy eines Channels mit mindestens einem Rhino-Skript erzeugt eine Deprecation-Warnung — im Log und in der API-Antwort — und nennt die betroffenen Skripte namentlich.

Version	Verhalten
Brio-IO 1.x (heute)	Rhino läuft, Warnung beim Channel-Deploy
Brio-IO 2.x	Warnung wird prominenter (Banner im Channel-Editor)
Brio-IO 3.x	Rhino nur noch per Feature-Flag aktivierbar
Brio-IO 4.0	Rhino und Punkt-Notation werden entfernt

Der Vorlauf ist mit Absicht lang: Migration soll Skript für Skript passieren können, nicht unter Zeitdruck.

Was sich sonst noch unterscheidet

Konfiguration liegt in Git. Es gibt keinen Export-Knopf, dessen Ergebnis man irgendwo ablegt — jede Änderung ist ein Commit. Siehe Konzepte.

Verworfene Nachrichten bleiben sichtbar. Was ein Filter aussortiert, erscheint als FILTERED-Zeile im Message-Browser statt spurlos zu verschwinden.

Änderungen lassen sich vorab gegen echten Traffic prüfen. Shadowing und Vergleich haben in Mirth keine Entsprechung — siehe Konzepte.