Mithilfe von Musterparametern können Sie eine Musterinstanz mit Werten generieren, die für Ihre eigene Musterinstanz festgelegt werden. Sie müssen jedoch auch die Musterinstanz implementieren und verwalten. Möglicherweise müssen darüber hinaus bestimmte operative Kontexte geändert werden.
Das Muster nutzt eine einfache Topologie, bei der alle Nachrichtenflüsse auf einem einzelnen Nachrichtenbroker ausgeführt werden. Dieses Thema enthält Informationen zur Implementierung und Verwaltung einer Musterinstanz, die diese einfache Topologie verwendet. Außerdem erfahren Sie, wie Sie die Musterinstanz verwalten können.
Das Muster enthält einige spezielle Anpassungspunkte, über die Sie eigene Änderungen hinzufügen können.
Dieses Thema enthält folgende Abschnitte:
Vor der Generierung der Musterinstanz können Sie ein MQSC-Script für die Definition der vom Muster benötigten Warteschlangen generieren, indem Sie im Abschnitt General (Allgemein) der Registerkarte Configure Pattern Parameters (Musterparameter konfigurieren) das Kontrollkästchen Generate scripts (Scripts generieren) aktivieren. Dieses Script namens queues.mqsc befindet sich im Stammverzeichnis des Musterinstanzprojekts und definiert grundlegende Warteschlangen und Themen.
Sie können das MQSC-Script mit folgendem Befehl ausführen (dabei gibt MBQMGR den Namen des Warteschlangenmanagers für Ihren Broker an):
runmqsc MBQMGR < queues.mqsc
Durch eine entsprechende Bearbeitung dieses MQSC-Scripts können Sie ihm Beschreibungen für Ihre Umgebung hinzufügen und geeignete Warteschlangenlängen festlegen.
Sie müssen insbesondere die Länge der Warteschlange flowprefix.DUPID prüfen, die den Speicher für doppelte Daten enthält. In dieser Warteschlange sind alle Daten gespeichert, die für die Duplikatprüfung verwendet werden. Wenn die Duplikatprüfung aktiviert ist, wird die erforderliche Länge dieser Warteschlange durch die Multiplikation der maximalen Empfängernachrichtenrate mit der Dauer der Ablaufeinstellung berechnet. Wenn die maximale Rate beispielsweise zehn Nachrichten pro Sekunde beträgt und als Ablaufeinstellung 24 Stunden (86.400 Sekunden) festgelegt sind, lautet die erforderliche Länge 864000.
Es wird erwartet, dass andere Warteschlangen überwacht werden und deren Inhalt in regelmäßigen Abständen gelöscht wird. Da diese Warteschlangen mit einer Standardgröße erstellt werden, müssen Sie deren Verwendung überprüfen und sicherstellen, dass ihre Länge ausreicht.
Sie müssen das MQSC-Script vor der Implementierung der Musterinstanz ausführen.
Wenn Sie die Sequenzbildung aktiviert und die Option für separate Sequenzwarteschlangen ausgewählt haben, generiert das Muster eine konfigurierbare Servicedatei. Wenn Sie eine Instanz des Musters generieren, wird diese Datei im Stammverzeichnis des Containerprojekts erstellt, das die generierten Nachrichtenflüsse enthält. Dieser konfigurierbare Service teilt den Resequence-Knoten mit, wo folgegebundene Informationen gespeichert werden sollen. Der konfigurierbare Service muss vor der Implementierung des Musters für den Broker implementiert werden.
Laden Sie die Nachrichtengruppe 'HL7v25P' herunter. Weitere Informationen hierzu finden Sie unter Ressourcen für das Muster Healthcare: HL7 an HL7.
Diese Nachrichtengruppe erfüllt die Standards, die im HL7-Standard der Version 2.5 festgelegt sind. Als Nachricht wird vom Muster die HL7-Nachricht in der Nachrichtendefinitionsdatei segments.mxsd verwendet. Wenn Quellen- oder Zielanwendungen Änderungen am Standard vornehmen, müssen diese Änderungen im Nachrichtenmodell reflektiert werden. Die gängigsten Änderungen lauten wie folgt:
Z-Segmente werden von Anwendungen zum Senden oder Empfangen von Daten verwendet, die außerhalb der HL7-Spezifikation definiert sind. Sie können Z-Segmente modellieren und diese in Ihrer Implementierung verwenden:
HL7-Implementierungen können die durch HL7 definierten Standardsegmente ergänzen, indem am Ende eines Segments zusätzliche Felder hinzugefügt werden. Diese Zusätze werden in der Regel durch ein Remainder-Feld am Ende jeder Segmentdefinition modelliert. Sie können vor dem Remainder-Feld jedoch die zusätzlichen Felder hinzufügen, die von Herstellern benötigt werden.
Den Benutzern des Musters stehen drei Hauptanpassungspunkte zur Verfügung. Darüber hinaus sind jedoch noch weitere Anpassungspunkte verfügbar.
Der Hauptnachrichtenfluss 'TransformAndRoute' ruft den untergeordneten Fluss 'SubCustomize' auf, bevor er die Nachrichten an verschiedene Ziele verteilt und gegebenenfalls das kanonische Format der Nachricht erstellt.
Der standardmäßige untergeordnete Fluss 'SubCustomize' hat keine Auswirkung auf die Nachricht, Sie können mit diesem Anpassungspunkt jedoch Daten aus der Quelle standardisieren, damit Ihre Anforderungen erfüllt werden. Es kann beispielsweise vorkommen, dass Ihr Standard für Datumsangaben das Format JJJJ-MM-TT vorschreibt, die Quelle jedoch ein anderes Datumsformat verwendet. Mit diesem Anpassungspunkt können Sie beliebige Quellendaten ändern. Es kann auch gelegentlich sinnvoll sein, an diesem Punkt Daten einzufügen, die in anderen Quellen wie zum Beispiel Datenbanken verfügbar sind.
Für jedes Ziel gibt es einen standardmäßigen untergeordneten Fluss zur Anpassung (namens Destn, wobei n für die Nummer des Ziels steht), der keine Auswirkung auf die Nachricht hat. Sie können mit diesem untergeordneten Fluss jedoch eine Ausgabenachricht erstellen, die den Spezifikationen entspricht, die von dem betreffenden Ziel benötigt werden. Das Ziel könnte beispielsweise die folgenden Änderungen erfordern:
Wenn Sie sich für die Generierung eines Quellenfeeds oder kanonischen Feeds entschlossen haben, generiert jede vom Fluss 'Receiver' verarbeitete Nachricht eine Kopie der Quellennachricht oder der Nachricht nach der Kanonisierung. Diese Nachrichten werden in eine WebSphere MQ-Warteschlange geschrieben oder veröffentlicht, je nachdem, was durch Ihre Musterparameter angegeben ist.
Möglicherweise möchten Sie Nachrichten an Ziele senden, die nicht mit dem Muster kompatibel sind. Beispiele hierfür wären ein Data-Warehouse, ein Nicht-HL7-Ziel oder ein Ziel, das einen anderen Transportmechanismus verwendet. Sie können Nachrichten an Ziele senden, die nicht mit dem Muster kompatibel sind, indem Sie Nachrichtenflussanwendungen für die Verarbeitung der Nachrichten aus den Quellenfeeds oder kanonischen Feeds schreiben.
Erstellen Sie eine neue Brokerarchivdatei (BAR-Datei) an der Position, an der Sie diese Ressourcen speichern möchten.
Die HL7v25P-Nachrichtengruppe muss in einer eigenen BAR-Datei gepackt werden:
Bei allen Nachrichtenflüssen im Muster werden Fehlerbenachrichtigungen in eine Fehlerwarteschlange geschrieben. Darüber hinaus wird ein Warteschlangentrace an der Position ausgegeben, die Sie während der Generierung des Musters definiert haben. Der MQRFH2-Header der Fehlernachricht enthält Informationen, die angeben, wo der Fehler aufgetreten ist. In diesem Abschnitt finden Sie Details zum Verhalten der einzelnen Nachrichtenflüsse.
Der Fluss 'Receiver' wird als Transaktion ausgeführt und sämtliche Ausgabenachrichten werden beim erfolgreichen Abschluss des Nachrichtenflusses festgeschrieben. Falls Bestätigungen erforderlich sind, sendet der Fluss 'Receiver' als letzte Aktion die Bestätigung (ACK). Sobald die Verarbeitung der Bestätigung erfolgreich abgeschlossen ist, wird der Fluss beendet und die Nachrichten werden festgeschrieben.
Für jede Aktion im Fluss 'Receiver' gilt Folgendes:
Falls ein Fehler auftritt, geschieht Folgendes:
Falls erforderlich, wird eine Antwort mit einer negativen Rückmeldung (NACK) generiert und an die Quellenanwendung gesendet.
Der Administrator muss die Fehlerwarteschlange und das Ereignisprotokoll überwachen, um festzustellen, wann Nachrichten nicht von der Empfängerwarteschlange verarbeitet wurden. Auf diese Weise kann er erforderliche Korrekturmaßnahmen ergreifen, um den Fehler zu beheben.
Der Fluss 'TransformAndRoute' wird als einzelne Transaktion ausgeführt. Sobald der Nachrichtenfluss erfolgreich abgeschlossen wurde, werden sämtliche Ausgabenachrichten an folgenden Positionen festgeschrieben:
Falls ein Fehler auftritt, geschieht Folgendes:
Der Administrator muss die Fehlerwarteschlange und das Ereignisprotokoll überprüfen, um festzustellen, welche Fehler aufgetreten sind. Sowohl die Fehlerwarteschlange als auch die Rücksetzwarteschlangen enthalten Informationen. Nach der Verarbeitung einer korrigierten Nachricht müssen diese Informationen gelöscht werden, um ein Ansteigen der Daten in der Warteschlange zu verhindern.
Der Administrator muss eine Rücksetzwarteschlange für die Eingabewarteschlange konfigurieren.
Wenn für eine Nachricht vom Fluss 'Routing and Transformation' ein Rollback durchgeführt wird, werden spätere Nachrichten dennoch verarbeitet und an die Sender-Flüsse übergeben. Diese Aktion kann jedoch bei jedem Ziel, das eine lockere oder strikte Sequenzbildung implementiert, eine Auswirkung auf die Sender-Flüsse haben, da die Folgenummer der fehlerhaften Nachricht fehlt. Dies führt dazu, dass Nachrichten in die Sequenzwarteschlange eingereiht werden, bis entweder eine Nachricht mit der richtigen Folgenummer empfangen wird, oder dass die Nachricht aufgrund einer Zeitlimitüberschreitung beendet wird, damit die fehlende Folgenummer übersprungen werden kann (nur bei der lockeren Sequenzbildung). Daher müssen Fehler im Fluss 'TransformAndRoute' möglichst schnell korrigiert werden.
Für die Korrektur eines Fehlers im Fluss 'TransformAndRoute' stehen zwei Möglichkeiten zur Verfügung:
<sup:MaintainSequence xmlns:sup=http://ibm/healthcare/support> <MessageGeneratedToMaintainSequence>true</ MessageGeneratedToMaintainSequence> </sup:MaintainSequence>
<SequenceNumber>2</SequenceNumber> <SequenceGroup>DEST1</SequenceGroup>
Sender-Flüsse, die die Sequenzbildung unterstützen, enthalten den Resequence-Knoten 'Maintain Sequence'. Ein Resequence-Knoten unterteilt den Fluss in zwei Transaktionen. Wenn vor dem Resequence-Knoten eine Ausnahmebedingung auftritt, wird eine Nachricht in die Fehlerwarteschlange außerhalb der Transaktion geschrieben und für die Eingabenachricht wird ein Rollback zur Eingabewarteschlange für den Fluss 'Sender' durchgeführt. Die Eingabewarteschlange muss mit einer Rücksetzwarteschlange konfiguriert werden.
Diese Art der Fehlerbehandlung wird auch angewandt, wenn der Fluss 'Sender' keine Sequenzbildung aufweist.
Korrigieren Sie den Fehler mit einer der folgenden Lösungen:
Wenn an diesem Punkt im Fluss Fehler auftreten, bedeutet dies, dass eine Folgenummer fehlt. Wenn für den Fluss 'Sender' eine Sequenzbildung verwendet wird, muss der Administrator die Fehlerwarteschlange überprüfen und den Fehler möglichst schnell korrigieren. Spätere Nachrichten in der Folge werden in internen Sequenzwarteschlangen gespeichert; daher kann ein Fehler zu einer hohen Menge an Nachrichten führen.
Wenn ein Fehler nach dem Resequence-Knoten, aber vor dem Versenden der Nachricht an die Zielanwendung auftritt, wird eine Fehlernachricht geschrieben und die Nachricht wird auf die interne Sequenzwarteschlange zurückgesetzt. Um diese Art von Fehler zu beheben, muss der Administrator sicherstellen, dass die Zielanwendung sowohl verfügbar als auch verbunden ist. Der Resequence-Knoten versucht weiterhin, die Nachricht zuzustellen, damit die Nachricht zugestellt wird, sobald die Verbindung hergestellt wird. Bei einer strikten Sequenzbildung werden spätere Nachrichten erst zugestellt, wenn die vorherige Zustellung erfolgreich war.
Ein Fehler kann auch nach der Zustellung einer Nachricht auftreten. Diese Art von Fehler tritt auf, wenn die Zielanwendung die Nachricht nicht verarbeiten kann und eine NACK-Meldung sendet. In diesem Fall setzt der Fluss die Nachricht nicht auf den Resequence-Knoten zurück, da die Nachricht denselben Fehler möglicherweise wiederholt verursacht. Stattdessen wird eine Nachricht in die Fehlerwarteschlange geschrieben. Der Administrator muss die Fehlerwarteschlange überprüfen und das Problem bei der Zielanwendung beheben. In diesem Fall fließen Nachrichten mit einer höheren Folgenummer weiterhin.
Administratoren, die Fehler beheben müssen, finden die wichtigsten Informationen in den Nachrichten, die sich in der Fehlerwarteschlange und in den Rücksetzwarteschlangen befinden. Darüber hinaus steht jedoch auch die SEQNOS-Warteschlange zur Verfügung, in der der Status der aktuellen folgegebundenen Informationen gespeichert ist. Diese Warteschlange bietet einen Überblick über den Fluss der Nachrichten an jedes der Musterziele.