Dieses Programm enthält Beispiele für Nachrichtenzuordnungen und -flüsse, durch die die Möglichkeiten der Nachrichtenzuordnungstools veranschaulicht werden. Die in diesen individuellen Nachrichtenzuordnungen gezeigten Funktionen können in einem einfachen Nachrichtenfluss für ein komplexes Geschäftsszenario kombiniert werden. Die Musterdateien sind nicht zur Implementierung vorgesehen.
Die Musterdateien für die Verarbeitung vollständiger Nachrichtenassemblierungen befinden sich im Ordner message_assembly im Projekt Message Map Sample Message Flows.
Eine Nachrichtenassemblierung ist die Kombination aller Header und des Hauptteils oder der Nutzdaten der Nachricht. Die Zuordnungs-, Dateneinfüge-, Datenlösch- und Extraktionsknoten in einem Nachrichtenfluss bearbeiten stets eine vollständige Nachrichtenassemblierung. Dies bedeutet, dass die Zuordnung für diese Knoten immer ein Nachrichtenassemblierungsmodell als Quellen und Ziele einer Zuordnung anzeigen.
Es gibt zwei Nachrichtenassemblierungsmodelle in WebSphere Message Broker: das vereinfachte Eigenschaftenmodell und das vollständige Headermodell. Die Auswahl des Modells hängt davon ab, was Ihren Szenarioanforderungen entspricht. Das linke Bild zeigt das Eigenschaftenmodell einer Nachrichtenassemblierung; das rechte Bild zeigt das Headermodell einer Nachrichtenassemblierung.
Eine WebSphere Message Broker-Nachrichtenassemblierung enthält vier Elemente, die im Bild nummeriert sind:
Sie können einen Nachrichtenfluss so konfigurieren, dass er nach einem der Zuordnungsknoten einen Sprung zu einem Knoten des Typs 'Weiterleitung_an_Zieladresse' ausführt; dies ist bei inhaltsbasierten Weiterleitungsszenarios innerhalb von Flüssen hilfreich.
In diesem Beispielprogramm sind drei allgemeine Szenarios implementiert:
In allen Fällen sind Hauptteil oder Nutzdaten der Nachricht das letzte Element in der Nachrichtenassemblierung.
Mit Hilfe des Nachrichtenassemblierungselements labelName
kann nach einem Zuordnungsknoten die Weiterleitung einer Nachricht gesteuert werden. Dies ist hilfreich bei Szenarios, in denen Sie die nächsten Nachrichtenflussknoten auswählen möchten, um mit der Verarbeitung über eine Zuordnung fortzufahren.
In der folgenden Abbildung ist die Beispielnachrichtenflussdatei RouteToLabelUsingMap.msgflow dargestellt. Diese wurde mit einem Zuordnungsknoten (Mappping), einem Knoten 'Weiterleitung_an_Zieladrese' (Route To Label) und mehreren Zieladressenknoten (Label) konfiguriert. Für die Zieladressen der Label
-Knoten wurden in der Konfiguration ihre Namen übernommen.
Um auszuwählen, welcher Zieladressenknoten die Ausgabenachricht verarbeitet, muss die Zuordnung die Eigenschaft 'Zielbezeichnung' des Zieladressenknotens angeben. In der Beispielzuordnungsdatei SetLabelNodeLabelName.msgmap erfolgt dies unter Verwendung einer if
-Zeile mit 2 Bedingungen (conditions
) und einem else
-Ausdruck:
In diesem Beispielprogramm gilt Folgendes:
$source/rtl:body/content
gleich Null ist, werden von nachgeschalteten Flussknoten des Zieladressenknotens 'Target1' verarbeitet;
$source/rtl:body/content
größer als Null ist, werden von nachgeschalteten Flussknoten des Zieladressenknotens 'Target2' verarbeitet;
Häufig konzentriert sich eine Zuordnung ausschließlich auf den Hauptteil einer Nachricht. In diesem Szenario sollen alle Header unverändert von der Zuordnung kopiert werden.
Verwenden Sie das Eigenschaftenmodell, um alle Header unverändert zu kopieren. Wenn Sie das vereinfachte Nachrichtenassemblierungsmodell 'Properties' verwenden, werden mit Ausnahme des Eigenschaftenordners alle Nachrichtenheader kopiert, und zwar der Reihe nach und unverändert.
Sobald Sie eine Nachrichtenzuordnung des Eigenschaftenmodells erstellt haben, ordnen Sie das komplexe Element $source/Properties
dem komplexen Element $target/Properties
zu. Dadurch wird der Eigenschaftenordner unverändert von Quelle zu Ziel kopiert, und zwar gemeinsam mit allen übrigen unveränderten Headern.
Die folgende Grafik stellt die Musterdatei CopyAllHeaders.msgmap dar, die so konfiguriert ist, dass alle Header (einschließlich Properties) unverändert kopiert werden sollen.
Das Eigenschaftenmodell ermöglicht viele Brokerszenarios, ohne dass die Komplexität der Zuordnung mehrerer Header gehandhabt werden muss. Das Eigenschaftenmodell arbeitet die meisten wichtigen Headerattribute für MQ Series und den MRM-Parser heraus und präsentiert diese in einem einzigen Paket. Verwenden Sie zusätzlich zum Szenario 'Copy All Headers' das Eigenschaftenmodell in Situationen, bei denen MQ Series als Transportschicht verwendet wird und MRM der Parser des Nachrichtenhauptteils ist. Diese Attribute können wie folgt kategorisiert werden:
Sie müssen beachten, dass in einem Eigenschaftenmodell (Properties
) alle Felder festgelegt werden müssen. Wenn Sie ein einzelnes Feld festlegen müssen, z. B. MessageFormat
zur Auswahl des physischen Formats der Ausgabenachricht, müssen Sie auch die übrigen Werte im Ordner Properties
festlegen bzw. die entsprechenden Werte kopieren. Damit die Felder in die Ausgabenachricht kopiert werden, müssen sie explizit festgelegt werden.
Das Headermodell (Headers
) bietet die Möglichkeit, neben den Eigenschaften ausgewählte Header zuzuordnen. Beachten Sie, dass vom Headers
-Modell die Funktion zum Kopieren aller Header ("copy all headers") nicht unterstützt wird: Es werden nur Header als Bestandteil des Ziels erstellt, die explizit zugeordnet wurden.
Die Header werden als MQMD-, MQ-, HTTP- und JMS-Header kategorisiert. Verwenden Sie das Modell Headers
für Szenarios des Typs JMS, SOAP über JMS sowie HTTP. Verwenden Sie das Modell Headers
für MQ-Szenarios, wenn das Modell Properties
nicht die benötigte Steuerung bietet.
Compute
) konfigurieren, um die Zuordnung aufzurufen. Siehe Beschreibung unten.Compute
) konfigurieren, um die Zuordnung aufzurufen. Siehe Beschreibung unten.
Die Musterdateien für Szenarios mit mehreren Ausgabenachrichten befinden sich im Ordner multiple_output im Projekt Message Map Sample Message Flows.
Die Basisregel zur Erstellung mehrerer Ausgabenachrichten besteht in der impliziten oder expliziten Deklarierung mehrerer $target
-Zeilen. Mehrere Zeilen können unter Verwendung einer for
-Zeile implizit deklariert werden. Mit Hilfe einer for
-Zeile werden null oder mehrere Ausgabenachrichten erstellt, eine pro Quellenelement, das als for
-Zeilenquelle bereitgestellt wird. Mehrere Ausgabenachrichten können auch erstellt werden, indem unter Verwendung des Menüs Quellen und Ziele hinzufügen mehrere Ziele explizit hinzugefügt werden. Mit jedem dieser Ziele wird eine Ausgabenachricht erstellt. Sie können sogar for
-Zeilen mit mehreren Zielen kombinieren, wenn jedes Element in einer Quelle mehrere Ausgabenachrichten selbst erstellt.
Es gibt mehrere Szenarios, bei denen es hilfreich ist, eine Nachrichtenzuordnung zur Ausgabe mehrerer Nachrichten zu konfigurieren. Nachfolgend werden einige dieser Szenarios genannt:
In diesem Szenario wird eine einzelne Nachricht in unterschiedliche Nachrichten umgewandelt, die an verschiedene Informationssysteme im Unternehmen gerichtet sind. In anderen Fällen können mehrere Wiederholungsfelder enthalten sein, die am besten einzeln verarbeitet werden.
Eine mehrteilige Nachricht ist eine Nachricht, die unter Verwendung der Brokerfunktion als mehrteilige Nachricht modelliert wurde. Dabei können Nachrichten in unterschiedlichen physischen Formaten oder sogar in unterschiedlichen Wörterverzeichnissen in einer einzelnen Stapelnachricht kombiniert werden.
Eine Quellennachricht enthält Daten, die in separate Nachrichten für mehrere EIS-Systeme umgewandelt werden müssen. Individuelle, sich nicht wiederholende Felder müssen zur Erstellung mehrerer Ausgabenachrichten kombiniert werden.
Eine Quellennachricht enthält ein Wiederholungsfeld (beispielsweise eine Rechnung), das auf Basis eines Werts im Feld (beispielsweise auf Basis einer Handelspartnerkennung) in mehrere Ausgabenachrichten umgewandelt werden muss.
Mit den Tools zur Nachrichtenzuordnung können mehrere Ausgabenachrichten einfach generiert werden: Sie müssen lediglich mehrere Zielnachrichtenassemblierungen angeben oder eine Zielnachrichtenassemblierung in eine for
-Zeile einschließen.
Die Musterdateien für dieses Szenario befinden sich im Ordner multiple_output im Projekt Message Map Sample Message Flows.
Zur Erstellung mehrerer Ausgabenachrichten für ein Wiederholungsquellenfeld muss lediglich die Zielnachrichtenassemblierung in eine for
-Zeile aufgenommen werden, von der die Wiederholungsquelle verarbeitet wird.
Die Beispielnachrichtenzuordnung repeating_source.msgmap konvertiert ein Wiederholungsfeld in einer Quellennachrichtenassemblierung in einen Strom aus Nachrichtenassemblierungen im aufrufenden Nachrichtenfluss. repeating_source.msgmap schließt die Zeile $target
in eine for
-Zeile ein, um mehrere Ausgabenachrichtenassemblierungen zu erstellen (eine pro sich wiederholender Eingabe). Für jede Assemblierung wird der Eigenschaftenordner kopiert. Dies bedeutet, die Funktion zum Kopieren aller Header (copy all headers) wird genutzt. Anschließend wird in jeder Ausgabenachrichtenassemblierung eine einzelne Instanz von rtl:body
kopiert.
Die Musterdateien für dieses Szenario befinden sich im Ordner multipart_messages im Projekt Message Map Sample Message Flows.
Wie bei Wiederholungsfeldern muss zur Erstellung mehrerer Ausgabenachrichten für eine sich wiederholende mehrteilige Quellennachricht lediglich die Zielnachrichtenassemblierung in eine for
-Zeile aufgenommen werden, von der die Definition der sich wiederholenden mehrteiligen Nachricht verarbeitet wird.
Der Hauptunterschied zwischen einer mehrteiligen Nachricht und einem regulären Wiederholungsfeld besteht darin, dass eine mehrteilige Nachricht von einer lokalen Inhaltsgruppe mit dem Inhaltsmodell open
oder open-defined
definiert wird (eine Brokererweiterung des XML-Schemas), während ein Wiederholungsfeld von einem Element definiert wird.
Es wird kein anderes Nachrichtenzuordnungskonstrukt für eine mehrteilige Nachricht eingeführt, sondern die Inhaltsgruppe wird behandelt, als ob ihr Inhalt ein Platzhalterzeichen des XML-Schemas wäre. Für die Erstellung einer Zuordnung für ein Platzhalterelement des XML-Schemas muss eine aufgerufene Submap verwendet werden.
Wie das Beispielprogramm verdeutlicht, werden Platzhalterelemente durch die Verwendung einer elementspezifischen Submap zugeordnet. Tatsächlich wird das Platzhalterzeichen oder "unbekannte" Element von einem Submap-Aufruf in ein "bekanntes" Element umgewandelt.
Die Musterdatei für dieses Szenario heißt nonrepeating_source.msgmap und befindet sich im Ordner multiple_output im Projekt Message Map Sample Message Flows.
Ob es sich um eine wiederholende oder nicht wiederholende Quelle handelt, hat keine Auswirkung auf das Verfahren zur Erstellung mehrerer Nachrichten. In diesem Fall werden mehrere $target
-Zeilen explizit von der Zuordnung deklariert. Jede deklarierte Zielzeile erstellt eine Ausgabenachricht. In den Wiederholungsszenarios wurden die Mehrfachassemblierungen implizit durch die for
-Zeilen deklariert, die die Zielassemblierungen enthielten und eine Ausgabeassemblierung pro Element in der for
-Zeile erstellten.
Die Musterdateien für dieses Szenario befinden sich im Ordner sorting im Projekt Message Map Sample Message Flows. Hierbei gibt es 2 Varianten:
Mit der Datei sorting.msgmap wird die Sortierung oder Gruppierung demonstriert, wenn die Schlüsselwerte für die Sortierung während der Erstellung der Zuordnung bekannt sind. Drei mögliche Feldwerte werden in drei separate Nachrichten sortiert, und zwar unter Verwendung des Designmusters Mehrere Ausgabenachrichten für sich nicht wiederholende Eingaben erstellen.
Häufig müssen Gesamtsummen oder Satzzählungen berechnet werden, nachdem eine einzelne Nachricht in mehrere Nachrichten umgewandelt wurde. Dies muss in einem zweiten Schritt erfolgen - in der Datei total.msgmap. Der Nachrichtenfluss sort.msgflow verdeutlicht, wie zwei Zuordnungsknoten verbunden werden, um dieses Ergebnis zu erzielen.
Die Musterdatei heißt sorting_dynamic.msgmap. Dieses Beispiel entspricht weitgehend dem Verfahren zur Sortierung mit bereits bekannten Schlüsseln. Der entscheidende Unterschied liegt darin, dass die Zuordnung die Liste gültiger Schlüssel aus einer Datenbank beziehen muss. Die Schritte in der Zuordnung lauten wie folgt:
$db:select
-Zeile wird die Liste der Schlüssel aus einer Datenbank bezogen.
for
-Zeile verarbeitet wiederum jedes Element aus $db:select
. for
-Auswahlzeile ist eine weitere for
-Zeile eingebettet. In diesem Fall wird jeder Datensatz in der Quelle ausgewählt. if
-Zeile und eine condition
-Zeile filtern die beiden for
-Zeilen, so dass nur Zeilen, für die die Schlüssel stimmen, eine Ausgabenachricht erstellen. $target
-Zeile die Ausgabenachrichten, eine pro eindeutigem Schlüsselwert sowohl in der Datenbank als auch der Quellennachricht.
Wie im vorherigen Beispiel wird dadurch noch keine korrekte Ausgabenachricht erstellt. Die Zuordnung total.msgmap muss erneut aufgerufen werden, um die Summen pro Ausgabenachricht zu berechnen.
Die Musterdateien befinden sich im Ordner esql_calling_msgmap im Projekt Message Map Sample Message Flows.
Das Beispiel demonstriert den Aufruf einer Zuordnung aus ESQL. Es wird davon ausgegangen, dass Benutzer eher Submaps als Hauptzuordnungen aufrufen. Eine Submap ist eine beliebige Nachrichtenzuordnung, die aus einer anderen Zuordnung oder ESQL aufgerufen werden soll. Sie können eine Submap im Assistenten für neue Nachrichtenzuordnungen (Datei>Neu>Nachrichtenzuordnung
) erstellen, indem Sie das Optionsfeld Diese Zuordnung wird aus einer anderen Zuordnung aufgerufen... auswählen:
Die erwartete ESQL-Signatur für den Aufruf einer Submap lautet wie folgt:
Submapname( Quellenpfad1, [Quellenpfad2, [...]] [Zielpfad, ] InputLocalEnvironment [, OutputLocalEnvironment])
Mindestens ein Parameter für den Quellenpfad (sourcePath
) ist immer vorhanden; dieser repräsentiert die Messaging-Eingabe, die den Nachrichtenflussknoten steuert. Bei den Quellenpfaden (sourcePath
) handelt es sich um ESQL-REFERENCE
-Variablen, die vor dem Aufruf der Nachrichtenzuordnung zum Verweis auf den Quellenbaumstrukturknoten initialisiert werden.
Beim Zielpfad (targetPath
) handelt es sich um eine optionale ESQL-REFERENCE
-Variable, die auf den Knoten der Zielstammbaumstruktur verweist. Sie muss vor dem Aufruf der Nachrichtenzuordnung initialisiert werden. targetPath
ist optional, und wenn eine Nachrichtenzuordnung keine Zielparameter hat, erstellt die Zuordnung keine Messaging-Ausgabe. Diese Methode wird bei Nachrichten im Zusammenhang mit Datenbankszenarios verwendet, bei denen Nachrichten über ESQL-Datenbankknoten (Database
) aufgerufen werden.
InputLocalEnvironament und OutputLocalEnvironment sind ESQL-REFERENCE
-Variablen, die in Bezug auf die Korrelationsnamen des zugehörigen ESQL-Knotens initialisiert werden. Da Nachrichtenzuordnungen als Schema-Bereichs-Prozeduren (schema-scope) implementiert werden, können sie nicht direkt auf die Korrelationsnamen zugreifen.
Der Mustercode initialisiert die erforderlichen Parameter und ruft die Zuordnung auf.
Die Musterdateien befinden sich im Ordner esql_calling_msgmap im Projekt Message Map Sample Message Flows.
Das Basismuster des ESQL-Aufrufs einer Zuordnung wurde implementiert. Der ESQL-Code
MODULE
wurde geschrieben, um die Ordner Properties
und Headers
zu initialisieren, die erforderlichen Referenzen zu erstellen und die Zuordnung aufzurufen.
Die Zuordnung erstellt eine einzelne Ausgabenachricht aus allen Aggregate
-Knotenordnern (Request1, Request2 usw.). Da der ESQL-Code MODULE
die Eigenschaften und Header verarbeitet, muss lediglich noch der Inhalt aus
LocalEnvironment.Aggregate.AgregateRequestOrdnername
in die Ausgabenachricht kopiert werden.
Diese Beispielszenarios demonstrieren das Designmuster für die Umwandlung von XML-Schemamodellen, die Platzhalterzeichen, Typerweiterungen und -einschränkungen, Substitutionsgruppen sowie Inhaltsmodellgruppen in einer Nachrichtenzuordnung verwenden.
Die Musterdateien für die Verarbeitung von Platzhalterelementen und Attributen befinden sich im Ordner 'multipart_messages' im Projekt 'Message Map Sample Message Flows'.
Platzhalterelemente werden durch den Aufruf einer Submap verarbeitet. In der Submap ist der Name des Elements fest codiert. Verwenden Sie zur Verarbeitung verschiedener Elementnamen auf Basis desselben Platzhalterzeichens Zeilen des Typs if
, condition
und else
.
Das Beispielprogramm implementiert ein einfaches Wiederholungsfeld-Szenario. Dieses ist jedoch etwas komplexer, da die Wiederholungsquelle als eine mehrteilige Nachricht des Brokers modelliert wird. Die mehrteilige Nachricht wird von den Zuordnungstools als Platzhalterelement behandelt. Die Verarbeitung von Platzhalterzeichen erfolgt über den Aufruf einer Submap für den richtigen Elementnamen.
In der ersten Zuordnung ist die Zielnachrichtenassemblierung in einer
for
-Zeile enthalten. Die for
-Zeile agiert über die sich wiederholende, mehrteilige Nachricht, die in der einzelnen Quellennachricht enthalten ist. Der Behalt der Zielassemblierung in der for
-Zeile bedeutet, dass komplette Zielnachrichtenassemblierungen ausgegeben werden, und zwar eine pro eingegebene mehrteilige Nachricht in der Quelle. Die erste Nachrichtenzuordnung enthält auch eine Zuordnung für die Platzhalternachricht, die mehrteilige Nachrichten unterstützt. Diese Zuordnung ruft eine Submap auf, die eine komplette Definition des Elements zurückgibt, für das das Platzhalterzeichen steht.
In der zweiten Zuordnung wurde das Platzhalter-Nachrichtenelement auf ein rtl:body
-Element beschränkt. In dieser Submap sind Quelle und Ziel identisch, und es wird zur Erstellung des Ziels eine tiefe Kopie der Quelle erstellt.
Die Musterdatei für dieses Szenario heißt type_to_substitutiongroup.msgmap und befindet sich im Ordner xmlschema im Projekt Message Map Sample Message Flows.
Im Editor der Nachrichtenzuordnung werden spezielle 'Ordner' für Quellen- und Zielbaumstruktur verwendet, um die gültigen Typkombinationen darzustellen. Der Name des Ordners lautet specializations for Basistyp. Innerhalb des Ordners werden die Elemente in Kombination mit allen nicht abstrakten Ableitungen vom Basistyp angezeigt. Jede dieser konkreten Elementdarstellungen enthält ihren vollständigen Inhalt; dabei sind alle möglichen Attribute gefolgt von allen gültigen Elementen. Im Wesentlichen werden in der Baumstruktur die verschiedenen XML-Elemente angezeigt, die vom XML-Schemamodell beschrieben werden.
In der Beispielnachrichtenzuordnung wird die Quelle unter Verwendung eines XML-Schemamodells beschrieben, das Alternativen des Typs extensionType1
und extensionType2
ermöglicht. All diese Alternativen können einzeln dem Ziel zugeordnet werden.
Hierarchien der Typerweiterung können mit Auswahlmodellen, Substitutionsgruppen usw. kombiniert werden. In diesem Beispielprogramm wird eine derartige Komplexität jedoch vermieden.
Die Musterdatei für dieses Szenario heißt type_to_substitutiongroup.msgmap und befindet sich im Ordner xmlschema im Projekt Message Map Sample Message Flows.
Im Editor der Nachrichtenzuordnung werden spezielle 'Ordner' für Quellen- und Zielbaumstruktur verwendet, um die gültigen Elemente unter Verwendung der Kombinationen der Substitutionsgruppen darzustellen. Der Name des Ordners lautet substitutions for Regelheaderelement. Innerhalb des Ordners werden die verschiedenen Elementnamen in Kombination mit jeder nicht abstrakten Ableitung zum Basistyp angezeigt. Jede dieser konkreten Elementdarstellungen enthält ihren vollständigen Inhalt; dabei sind alle möglichen Attribute gefolgt von allen gültigen Elementen. Im Wesentlichen werden in der Baumstruktur die verschiedenen XML-Elemente angezeigt, die vom XML-Schemamodell beschrieben werden.
In der Beispielnachrichtenzuordnung wird das Ziel unter Verwendung eines XML-Schemamodells beschrieben, das Alternativen des Typs Substitute1
und Substitute2
zum abstrakten Element HeadElement
ermöglicht. All diese Alternativen können einzeln der Quelle zugeordnet werden.
Substitutionsgruppen können mit Typhierarchien kombiniert werden. In diesem Beispiel wird eine derartige Komplexität jedoch vermieden.
Die Musterdateien für dieses Szenario befinden sich im Ordner modelgroups im Projekt Message Map Sample Message Flows.