Dieses Muster verwendet den GenericHL7Input-Knoten, um eingehende HL7-Nachrichten vollständig zu lesen; hinsichtlich der Segmente, die in eine Nachricht aufgenommen werden können, bestehen keinerlei Einschränkungen, sofern die Segmente in der HL7v25P-Nachrichtengruppe vorhanden sind, die vom Muster verwendet wird. Das Muster verwendet die HL7v25P-Nachrichtengruppe, die im IBM WebSphere Message Broker Connectivity Pack for Healthcare enthalten sind. Die HL7v25P-Nachrichtengruppe enthält Definitionen aller Segmente, die gültig sind und dem Standard HL7 Version 2.5 entsprechen. Sie können zusätzliche Z-Segmente zu dieser HL7v25P-Nachrichtengruppe hinzufügen. Z-Segmente werden von Anwendungen zum Senden oder Empfangen von Daten verwendet, die außerhalb der HL7-Spezifikation definiert sind.
Vom Fluss 'Receiver' werden für die Quellennachricht einmalig eine Folgenummerierung, Duplikatprüfung und HL7-Bestätigung ausgeführt.
Das Muster definiert die Anzahl der Ziele, an die eine eingehende Nachricht verteilt wird. Für jedes Ziel wird die Nachricht verarbeitet und es erfolgt eine Filterung. Diese Filterung bestimmt, ob die Nachricht für das Ziel erforderlich ist. Außerdem wird so festgelegt, welche Segmente in der Quellennachricht in die Ausgabenachricht aufgenommen werden.
Der Fluss 'Sender' für jedes Ziel stellt sicher, dass Nachrichten in der richtigen Reihenfolge an die Zielanwendung gesendet werden.
Dieses Thema enthält folgende Abschnitte:
Eine Eingabenachricht wird anfangs vom GenericHL7Input-Knoten im Fluss 'Receiver' als BLOB-Nachricht (BLOB = großes Binärobjekt) gelesen. Vor der Syntaxanalyse werden die führenden MLLP-Bytes entfernt. Wenn das führende Byte nicht gefunden wird, wird die Nachricht abgelehnt, da der Sender das MLLP-Protokoll nicht einhält. Die Verbindung wird geschlossen und eine Antwortnachricht mit einer negativen Rückmeldung (NACK) wird gesendet.
Der GenericHL7Input-Knoten analysiert die Nachricht gemäß der HL7-Nachrichtendefinition in der HL7v25P-Nachrichtengruppe; weitere Informationen finden Sie unter Ressourcen für das Muster Healthcare: HL7 an HL7 . Alle Segmente werden gelesen. Falls ein Segment zusätzliche Felder aufweist, werden diese Felder in ein Remainder-Feld für dieses Segment gestellt.
Im Fluss 'Receiver' erfolgt keine Standardüberprüfung der Nachrichtendaten. Es wird jedoch überprüft, ob die folgenden HL7-spezifischen Datenfelder im MSH-Segment vorhanden sind, da diese Felder für die weitere Verarbeitung erforderlich sind:
Jede eingehende HL7-Nachricht enthält ein MessageControlID-Feld im MSH-Headersegment, das den Datensatz identifiziert.
Mit den Musterparametern, die die Duplikatprüfung steuern, werden die funktional entsprechenden Eigenschaften auf dem GenericHL7Input-Knoten festgelegt.
Wenn das Kontrollkästchen Check duplicates (Duplikate prüfen) im WebShere Message Broker Toolkit ausgewählt ist, werden alle Kennungen gemeinsam mit der Bestätigung (ACK), die an den Sender zurückgesendet wurde, in der Warteschlange für Duplikate gespeichert. Die Kennung einer eingehenden Nachricht wird gegen die gespeicherten Kennungen abgeglichen, um festzustellen, ob es sich um ein Duplikat handelt.
Wenn ein Duplikat gefunden wird, wird es nicht verarbeitet. Allerdings erhält der Sender dieselbe Bestätigung, die bei der ersten Nachricht gesendet wurde.
Kennungen werden für eine bestimmte Zeit in der Warteschlange für Duplikate gespeichert. Nach Ablauf dieser Zeitspanne werden sie gelöscht und Nachrichten mit derselben Kennung werden nicht mehr als Duplikate behandelt. Der Standardzeitraum für das Speichern von Nachrichtenkennungen beträgt 24 Stunden, Sie können diesen Zeitwert jedoch mithilfe eines Musterparameters ändern. Die Warteschlange für Duplikate muss so groß sein, dass sie den Spitzenwert der im festgelegten Zeitraum erwarteten Nachrichtenkennungen enthalten kann.
Falls eine eingehende Nachricht kein Duplikat ist, wird sie zur weiteren Verarbeitung durch das Ausgangsterminal des GenericHL7Input-Knotens geleitet.
Wird ein Duplikat gefunden, sendet der GenericHL7Input-Knoten die Bestätigung (ACK) an den Anforderer zurück. Wenn die Berichterstellung über Duplikate ausgewählt ist und ein Duplikat gefunden wird oder ein anderer Fehler im GenericHL7Input-Knoten auftritt, wird die Nachricht an das Fehlerterminal übergeben und die Umgebung enthält eine Beschreibung des Fehlers.
Der Parameter Sequence numbers (Folgenummern) legt fest, wie der Fluss 'Receiver' einer Eingabenachricht Folgenummern zuweist, um sicherzustellen, dass Nachrichten in der richtigen Reihenfolge zugestellt werden.
Für die Zuweisung von Folgenummern stehen drei Optionen zur Verfügung:
Der Interaktionsstil für dieses Muster ist eine synchrone Interaktion zwischen der Quellenanwendung und dem Brokernachrichtenfluss. Dabei verbleibt die Nachricht in der Warteschlange für den Fluss 'TransformAndRoute', bis die synchrone Bestätigung gesendet wird.
Der HL7-Fluss 'Receiver' generiert standardmäßig eine Bestätigungsantwort (ACK) oder eine Antwortnachricht mit einer negativen Rückmeldung (NACK) als Antwort auf den erfolgreichen Empfang von Daten. Falls keine Bestätigungen erforderlich sind, wählen Sie das Kontrollkästchen für den Parameter Send acknowledgment (Bestätigung senden) ab.
Sobald die Bestätigung eingegangen ist, stellen die Brokernachrichtenflüsse sicher, dass entweder die Nachricht verarbeitet oder ein Fehler ausgegeben wird. In diesem Fall werden die Nachrichtendaten gespeichert, damit eine erneute Übergabe oder eine alternative Verarbeitung möglich ist.
Wenn die Nachricht Werte enthält, die für die Erstellung einer Bestätigung erforderlich sind, werden diese Werte verwendet.
Der aktuelle Status der End-to-End-Interaktion wird an allen wichtigen Stellen im Fluss gespeichert und die NACK-Nachrichten enthalten diese Fehlerinformationen.
Feldname | Feldwert in Bestätigungsnachricht | Falls in der Eingabenachricht nicht vorhanden |
---|---|---|
MSH.1.FieldSeparator | MSH.1.FieldSeparator aus der Eingabenachricht | '|' |
MSH.ServiceString | MSH.2.ServiceString aus der Eingabenachricht | '^~\&' |
MSH.3.SendingApplication | 'BROKER.RECEIVER' | |
MSH.4.SendingFacility | ' ' | |
MSH.5.ReceivingApplication | MSH.3.SendingApplication aus der Eingabenachricht | ' ' |
MSH.6.ReceivingFacility | MSH.4.SendingFacility aus der Eingabenachricht | ' ' |
MSH.7.DateTimeOfMessage | Aktuelles Datum und aktuelle Uhrzeit im Format JJJJMMTThhmmss . | |
MSH.9.MessageType | 'ACK' | |
MSH.10.MessageControlID | Neue eindeutige Kennung | |
MSH.11.ProcessingID | MSH.11.ProcessingID aus der Eingabenachricht | 'P' |
MSH.12.VersionID | MSH.12.VersionID aus der Eingabenachricht | '2.2' |
Feldname | Feldwert in Bestätigungsnachricht | Falls in der Eingabenachricht nicht vorhanden |
---|---|---|
MSA.1.AcknowledgmentCode | Beim erfolgreichen Empfang der Nachricht wird der MSA-Bestätigungscode auf AA gesetzt und das Feld MSA.3.TextMessage ist nicht belegt. | |
MSA.2.MessageControlID | MSH.10.MessageControlID aus der Eingabenachricht | '123456789' |
MSA.3.TextMessage | Beim erfolgreichen Empfang der Nachricht wird der MSA-Bestätigungscode auf AA gesetzt und das Feld MSA.3.TextMessage ist nicht belegt. | |
MSA.4.ExpectedSequenceNumber | MSH.13.ExpectedSequenceNumber aus der Eingabenachricht |
Fehler beim Entfernen des MLLP-Bytes. Der MSA-Bestätigungscode wird auf AR gesetzt und das Feld MSA.3.TextMessage enthält die Nachricht MLLP Error - missing start byte (MLLP-Fehler - Startbyte fehlt).
Fehler beim Überprüfen des eingehenden MSH oder beim Deduplizieren der Daten. Der MSA-Bestätigungscode wird auf AE gesetzt und das Feld MSA.3.TextMessage enthält die Nachricht Input Message Parsing or Validation Error (Syntaxanalyse- oder Überprüfungsfehler bei Eingabenachricht).
Fehler beim Anwenden der Sequenzlogik. Der MSA-Bestätigungscode wird auf AR gesetzt und das Feld MSA.3.TextMessage enthält die Nachricht An internal failure in the Sequence node (Interner Fehler im Sequence-Knoten).
Fehler beim Definieren der HL7-Nachricht als persistente Nachricht in einer Warteschlange. Der MSA-Bestätigungscode wird auf AR gesetzt und das Feld MSA.3.TextMessage enthält die Nachricht Error while committing message into processor queue (Fehler beim Festschreiben der Nachricht in Prozessorwarteschlange).
Die Quellennachricht wird zur Umsetzung und Weiterleitung in mindestens eine Warteschlange geschrieben. Die Nachricht wird für jeden Teil des Musters in eine Warteschlange geschrieben und jeder Teil des Musters wird dann an die erforderliche Anzahl an Zielen weitergeleitet.
Der Fluss 'TransformAndRoute' liest eine HL7-Nachricht aus der Warteschlange.
Wenn der Parameter Report remainders (Reste auflisten) ausgewählt ist, wird überprüft, ob Remainder-Felder vorhanden sind. Dabei handelt es sich um zusätzliche Felder, die in einem Segment festgestellt, jedoch nicht in die HL7-Nachricht modelliert werden, mit der eingehende Nachrichten syntaktisch analysiert werden. Falls Remainder-Felder gefunden werden, werden diese in eine Warteschlange geschrieben oder veröffentlicht. Diese Option wird während der Entwicklung für die Erkennung zusätzlicher Felder und für die Festlegung ihrer Verarbeitungsweise verwendet.
Die HL7-Nachricht wird in ihr kanonisches XML-Format umgesetzt und an den untergeordneten Fluss 'SubCustomize' übergeben. Dieser untergeordnete Fluss führt standardmäßig keine anderen Aktionen als die Weitergabe der Nachricht aus. Der untergeordnete Fluss stellt jedoch einen Ort dar, an dem Sie eine bestimmte Musterinstanz ohne Änderung der Flussstruktur anpassen können.
Wenn der Parameter Canonical feed (Kanonischer Feed) ausgewählt wird, wird zu diesem Zeitpunkt das kanonische Format ausgegeben. Weitere Informationen finden Sie unter Ausgabe aus einer Musterinstanz. Sie können das kanonische Format der Eingabenachricht als Feed für andere Anwendungen verwenden, die keine HL7-Basisnachrichten akzeptieren.
Das Muster stellt für jeden Teil des Musters bis zu sechs Ziele zur Verfügung. Sie können jedes Ziel gesondert konfigurieren. Wenn Sie weniger als sechs Ziele auswählen, werden nur die ausgewählten Ziele konfiguriert. Der Fluss 'TransformAndRoute' sendet für jedes Ziel eine Kopie der Nachricht an den filternden untergeordneten Fluss für den Fluss 'TransformAndRoute'. Für jedes Ziel wird ein Filter ausgeführt, mit dem festgelegt wird, ob eine eingehende Nachricht an das Ziel gesendet wird. Zur Generierung einer Liste mit zulässigen Paaren aus Nachrichtencode und Nachrichtenereignis wird von den Musterparametern für jedes Ziel ein filternder untergeordneter Fluss (DestnFilter) konfiguriert. Dabei steht n für die Nummer des Ziels. Nur übereinstimmende Nachrichten werden an die Zielanwendung übergeben.
Sobald eine Nachricht herausgefiltert wird, wird an den Fluss 'Sender' (DestnSender) eine Pseudonachricht übergeben. Dabei steht n für die Nummer des Ziels. Dies gilt jedoch nicht, wenn der Parameter Sequencing action (Sequenzbildungsaktion) auf No sequencing (Keine Sequenzbildung) gesetzt ist. Diese Pseudonachricht ist erforderlich, damit die richtige Sequenzbildung der Nachrichten aus der Quelle gewahrt bleibt.
Nach der Nachrichtenfilterung wird jede erforderliche Nachricht wieder in das HL7-Format umgesetzt. Wenn der Parameter Segment filtering (Segmentfilterung) ausgewählt ist, werden alle Segmente, die in der Tabelle Segment filters (Segmentfilter) für das Ziel aufgelistet sind, als Teil der Umsetzung entfernt.
Die Nachricht durchläuft anschließend einen untergeordneten Fluss zur Anpassung. Dieser untergeordnete Fluss führt standardmäßig keine anderen Aktionen als die Weitergabe der Nachricht aus. Der untergeordnete Fluss stellt jedoch einen Ort dar, an dem Sie eine bestimmte Musterinstanz anpassen können. Schließlich wird die Nachricht in die Warteschlange für den Fluss 'Sender' geschrieben.
Für jedes Ziel wird ein separater Nachrichtenfluss (der untergeordnete Fluss DestnSender) erstellt. Dabei steht n für die Nummer des Ziels.
Die Sequenzbildung für ein Ziel kann entweder strikt oder locker sein. Dies wird durch den Musterparameter Sequencing action (Sequenzbildungsaktion) bestimmt. Wenn die Sequenzbildung Strict (Strikt) ausgewählt wird, enthält der Fluss 'Sender' einen Resequence-Knoten ohne Zeitlimit. Treffen Nachrichten in falscher Reihenfolge ein, werden sie in der Sequenzbildungswarteschlange zurückgehalten, bis die fehlenden Nachrichten eintreffen. Wird diese Option ausgewählt, muss die Systemwarteschlange, in der sich anstehende Nachrichten befinden, überwacht werden und zur Bereitstellung fehlender Nachrichten muss eine entsprechende Maßnahme ergriffen werden.
Für jede Nachricht, die erfolgreich an ein Ziel zugestellt wird, werden die Folgenummern aus der Quelle und jede eventuelle Neusequenzbildung im Fluss 'Sender' in die Warteschlange Warteschlangenpräfix.SEQNOS geschrieben. Das Warteschlangenpräfix wird durch den Parameter Queue prefix (Warteschlangenpräfix) definiert, und zwar gemeinsam mit einer Zeitmarke und der Folgegruppe, die dem Ziel entspricht, das als Destn angegeben ist. Dabei steht n für die Nummer des Ziels.
Selbst bei einer strikten Sequenzbildung kann es vorkommen, dass einige Nachrichten nicht an ein Ziel weitergegeben werden, wenn die Option Message filtering (Nachrichtenfilterung) ausgewählt ist. In diesem Fall werden die Pseudonachrichten, die diese Nachricht darstellen und nicht für die Zustellung vorgesehen sind, nach der Neusequenzbildung entfernt und den folgenden Nachrichten werden vor ihrer Übergabe an das Ziel neue Folgenummern zugewiesen.
Wenn die Sequenzbildungsoption Lax (Locker) ausgewählt ist, werden Nachrichten im Allgemeinen der Reihe nach zugestellt. Falls jedoch nach Ablauf der Zeit, die über den Parameter Sequencing timeout (Zeitlimit der Sequenzbildung) angegeben ist, eine Nachricht fehlt, wird eine Nachricht an die Benachrichtigungswarteschlange gesendet und der Fluss wird fortgesetzt. Die fehlende Nachricht wird in den Fluss eingefügt, sobald sie eintrifft. Wenn eine fehlende Nachricht eintrifft, wird sie auch in die Warteschlange .NTFY geschrieben.
Standardmäßig sind folgende Sequenzbildungswarteschlangen des Systems definiert:
Wenn der Parameter Separate sequence queues (Separate Sequenzwarteschlangen) für ein Muster ausgewählt ist, werden Sequenzbildungswarteschlangen, die speziell für die Musterinstanz vorgesehen sind, über den Parameter Queue prefix (Warteschlangenpräfix) wie folgt definiert:
Diese vom Standard abweichenden Sequenzbildungswarteschlangen werden durch einen konfigurierbaren Service namens patternInstance_setSeqQs definiert. Die Musterinstanz erstellt eine Datei namens Musterinstanz.resequence.configurableservice mit einer Definition dieses Service. Diese muss auf dem Broker erstellt werden, auf dem die Musterinstanz ausgeführt werden soll. Die Flüsse des Typs 'Sender' werden ebenfalls für die Verwendung dieses konfigurierbaren Service konfiguriert.
Falls für ein Ziel keine Sequenzbildung erforderlich ist, werden der Resequence-Knoten und der Bericht über fehlende Nachrichten im Fluss übergangen.
Der GenericHL7Output-Knoten bereitet eine Nachricht für die Zielanwendung vor und ändert diese in einen Bitstrom. Dabei wird das erforderliche MLLP-Begrenzerbyte 0B (MLLP = Minimal Lower Layer Protocol) am Anfang hinzugefügt. Der GenericHL7Output-Knoten leitet diese vorbereitete Nachricht dann an den TCP/IP-Sendeknoten weiter, der versucht, die Nachricht an die Zielanwendung zu senden.
Falls die Zielanwendung den Erfolgscode AA zurückgibt, wird die Variable Environment.PatternVariables.FlowMilestoneReached gelöscht und die Nachricht wird an das Ausgangsterminal übergeben.
Falls die Zielanwendung den Antwortcode AE zurückgibt, wird die Variable Environment.PatternVariables.FlowMilestoneReached auf ACKAE gesetzt und die Nachricht wird an das Fehlerterminal übergeben. Im Anschluss an eine ACKAE-Antwort erfolgen keine Wiederholungen.
Wenn die Nachricht erfolgreich gesendet, jedoch keine oder eine ungültige Bestätigung erhalten wurde, wird sie genau wie eine AE-Antwort behandelt. Allerdings wird die Variable Environment.PatternVariables.FlowMilestoneReached auf TIMEOUT , RECEIVEACK oder ACKERROR gesetzt, bevor die Nachricht an das Fehlerterminal übergeben wird. Es erfolgen keine Wiederholungen.
Wenn der GenericHL7Output-Knoten die Nachricht nicht an das Ziel senden kann oder wenn eine AR-Bestätigung vom Ziel zurückgegeben wird, wird die Nachricht an das Terminal für Wiederholungsprotokollierung weitergegeben. Die Zustellung der Nachricht wird wiederholt, sobald die Steuerung nach der Protokollierung zurückgegeben wird, und zwar bis sie erfolgreich ist oder die Anzahl der Wiederholungen den Grenzwert erreicht hat, der durch den Parameter Retry limit (Wiederholungslimit) festgelegt ist.
Sobald das Wiederholungslimit erreicht wurde, wird die Variable Environment.PatternVariables.FlowMilestoneReached auf ACKARTOOMANYREPEATS gesetzt und die Nachricht wird an das Fehlerterminal übergeben.
Die Inhaltsüberprüfung wird auf einer Zielbasis ausgewählt. Dabei wird der Parameter Validation (Überprüfung) im Abschnitt Destination communications (Zielübertragungen) verwendet. Wenn für ein Ziel eine Überprüfung ausgewählt ist, wird der Parameter Validation (Überprüfung) auf dem GenericHL7Input-Knoten für den relevanten Sender-Fluss auf Content (Inhalt) gesetzt. Die Eigenschaft Parse timing (Zeitpunkt für Syntaxanalyse) auf diesem Knoten wird durch das Muster als Immediate (Sofort) definiert, damit die Überprüfung vor der weiteren Verarbeitung erfolgt. Die Überprüfung erstreckt sich nur auf die Überprüfung der Nachricht anhand der HL7v25P-Nachrichtengruppe. Sie bietet beispielsweise keine vollständige HL7-Überprüfung abhängiger Felder.
Die HL7v25P-Nachrichtengruppe wird in Verbindung mit dem MRM-Parser für die Syntaxanalyse und das Schreiben von HL7-Nachrichten verwendet. Die resultierende Nachrichtenbaumstruktur kann in ein kanonisches XML-Format serialisiert werden. Die Nachrichtendefinitionen sind so flexibel, dass lokale Abweichungen toleriert werden, ohne dass eine Anpassung erforderlich ist. Sie können auch erweitert werden, damit die Syntaxanalyse von lokal definierten Z-Segmenten und zusätzlichen Feldern möglich ist. Wenn lokale Abweichungen auftreten und die Daten in diesen lokalen Abweichungen verarbeitet werden müssen, muss das HL7-Modell geändert werden, damit es einer passenden Spezifikation entspricht. Nur so ist sichergestellt, dass auf alle Daten zugegriffen werden kann.
Das kanonische Format kann von Ihrem Unternehmen zum Speichern einer Darstellung Ihrer Daten verwendet werden, die auf einem beliebigen Betriebssystem ausgeführt werden. Diese Daten können in Form von standardisierten Datums- und Zeitangaben, in einem bestimmten Zahlenformat oder in Übereinstimmung mit sonstigen Anforderungen an die Datenstandardisierung angegeben werden, die von Ihrem Unternehmen verlangt werden. Das kanonische Format stellt eine Trennung der Quellen- und Zielanwendungen dar, was eine maximale Wiederverwendung bei geringem Verwaltungsaufwand ermöglicht. In den von Ihnen generierten Mustern ist ein untergeordneter Anpassungsfluss für dieses kanonische Format enthalten.
Die HL7v25P-Nachrichtengruppe enthält globale Elementdefinitionen für alle Segmente, die in der HL7-Spezifikation der Version 2.5 definiert sind. Die Komponenten und Unterkomponenten in jedem Segment werden mit den richtigen Begrenzern modelliert. Sie können eine generische Nachrichtendefinition namens HL7 verwenden, um eine beliebige Folge von HL7-Segmenten syntaktisch zu analysieren.
Hinweis: Das in WebSphere Message Broker bereitgestellte Beispiel 'Healthcare' verfügt ebenfalls über eine HL7-Nachrichtengruppe. Zur Vermeidung von Konflikten hat die von IBM WebSphere Message Broker Connectivity Pack for Healthcare verwendete Nachrichtengruppe einen anderen Namen (HL7v25P). Da die Nachrichtengruppe HL7v25P aktueller ist, müssen Sie diese Nachrichtengruppe in Verbindung mit dem Muster Healthcare: HL7 an HL7 verwenden.
Neben den HL7-Nachrichten, die an angegebene Ziele weitergeleitet werden, stellt dieses Muster mehrere sonstige Ausgaben zur Verfügung. Diese Ausgaben werden entweder in eine Warteschlange geschrieben oder an einen Veröffentlichungsknoten gesendet. Die Zieladresse wird durch den Musterparameter Publish (Veröffentlichen) bestimmt. Wenn die Option Publish (Veröffentlichen) ausgewählt ist, werden alle Informationen unter Verwendung einer Themenhierarchie veröffentlicht, die mit dem Namen der Musterinstanz beginnt.
Ist die Option Write to Queue (In Warteschlange schreiben) ausgewählt, wird die Ausgabe an Warteschlangen gesendet, deren Namen auf Basis des Musterparameters Queue prefix (Warteschlangenpräfix) und einer festen Suffixgruppe generiert werden. Eine entsprechende Auflistung finden Sie in der folgenden Tabelle.
Hinweis: Die anfängliche Facette jedes Themas und jeder Warteschlange (der Name der Musterinstanz) wird nicht angezeigt.
Ausgabe | Warteschlange | Thema | Hinweise |
---|---|---|---|
Quellenfeed | .SRC | /Receiver/Source | Eine unveränderte Kopie der empfangenen Quellennachricht wird geschrieben. |
Journal | .JRNL | /Receiver/Journal | Diese Ausgabe stellt ein Journal eingehender Nachrichten im Standardmusterformat zur Verfügung.
Siehe Hinweis 1. |
An TransformAndRoute-Flüsse | .RXFn | Nicht zutreffend | Für jedes Ziel wird eine Nachricht an den Fluss 'TransformAndRoute' gesendet. |
Fehlerhafte Nachrichten | .ERR | Nicht zutreffend | Nachrichten, die nicht ordnungsgemäß verarbeitet werden können, werden an die Fehlerwarteschlange gesendet. Sie enthalten Fehlerinformationen in einem MQRFH2-Header. |
Nachrichten-IDs für die Duplikatprüfung | .DUPID | Nicht zutreffend | Nachrichtenkennungen und zugehörige Bestätigungsnachrichten werden zum Vergleich mit späteren eingehenden Nachrichten gespeichert, damit doppelte Nachrichten erkannt werden können.
Siehe Hinweis 2. |
Reste | .REM | /Remainders | Nachrichten mit Remainder-Feldern können optional geschrieben werden. |
Kanonisch | .CAN | /Canonical | Wenn die Option für die Ausgabe eines kanonischen Feeds ausgewählt ist, wird ein kanonisches XML-Format der Eingabenachricht geschrieben. |
An Sender-Flüsse | .DESTn | Nicht zutreffend | Für jedes Ziel wird eine Nachricht an den Fluss 'Sender' gesendet. |
Sequenzbildungsdaten | SYSTEM.BROKER.EDA.EVENTS | Nicht zutreffend | Die Systemwarteschlange, die standardmäßig von den Resequence-Knoten in den Sender-Flüssen verwendet wird. |
Sequenzbildungsdaten | SYSTEM.BROKER.EDA.COLLECTIONS | Nicht zutreffend | Die Systemwarteschlange, die standardmäßig von den Resequence-Knoten in den Sender-Flüssen verwendet wird. |
Sequenzbildungsdaten | SYSTEM.BROKER.EDA.Warteschlangenpräfix.EVENTS | Nicht zutreffend | Die Warteschlange, die von den Resequence-Knoten in den Sender-Flüssen verwendet wird, wenn die Option Separate sequence queues (Separate Sequenzwarteschlangen) ausgewählt ist. |
Sequenzbildungsdaten | SYSTEM.BROKER.EDA.Warteschlangenpräfix.COLLECTIONS | Nicht zutreffend | Die Warteschlange, die von den Resequence-Knoten in den Sender-Flüssen verwendet wird, wenn die Option Separate sequence queues (Separate Sequenzwarteschlangen) ausgewählt ist. |
Nachrichten in falscher Reihenfolge | .SEQNTFY | Nicht zutreffend | Wenn die Sequenzbildungsoption Lax (Locker) ausgewählt ist, werden Nachrichten, die in falscher Reihenfolge eintreffen, in diese Warteschlange geschrieben und an das Ziel zugestellt. |
Folgenummern | SEQNOS | Nicht zutreffend | Diese Warteschlange erfasst die aktuellste Folgenummer, die an jedes Ziel zugestellt wird. Wenn die Sequenzbildungsoption Strict (Strikt) ausgewählt ist, wird mit der Warteschlange die letzte an ein Ziel zugestellte Folgenummer bestimmt. |
Hinweis 1: Aus einer Quellennachricht wird durch das Hinzufügen von MQMD- und MQRFH2-Headern eine Journalnachricht erstellt. Der MQRFH2-Header enthält Folgendes:
Hinweis 2: Jede Nachricht wird bei ihrem Eintreffen von der Warteschlange auf Nachrichten-IDs überprüft, um festzustellen, ob eine frühere Nachricht mit derselben ID vorhanden ist. Diesen Nachrichten wird ein Zeitlimit zugewiesen, das durch einen Nachrichtenparameter bestimmt wird. Nach dessen Ablauf werden die Nachrichten aus der Warteschlange entfernt. Daher erfolgt die Duplikatprüfung nur für einen vorgegebenen Zeitraum. Die Standardeinstellung beträgt 24 Stunden.