Informationen zum Beispielprogramm 'Message Map'

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.

Handhabung vollständiger Nachrichtenassemblierungen

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.

Headerassemblierung

Headerassemblierung

Eine WebSphere Message Broker-Nachrichtenassemblierung enthält vier Elemente, die im Bild nummeriert sind:

  1. den LocalEnvironment-Ordner;
  2. den Eigenschaftenordner (Properties);
  3. die Transportschichtgruppe für Nachrichtenheader (Message Headers);
  4. die Nutzdaten oder den Hauptteil der Nachricht.

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.

Zurück zum Anfang.

Nachrichtenflussverarbeitung mit einer Zuordnung steuern

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.

Route To Label-Nachrichtenfluss

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:

Route To Label-Nachrichtenzuordnung

In diesem Beispielprogramm gilt Folgendes:

Zurück zum Anfang.

Alle Header kopieren

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.

Alle Header kopieren

Zurück zum Anfang.

Eigenschaften zuordnen

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:

Eigenschaftenmodell

  1. Physisches Format der Nachricht
  2. Transportschicht "Servicequalität"
  3. Informationen zum Antwortpfad
  4. Publish/Subscribe-Thema

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.

Zurück zum Anfang.

Header zuordnen

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.

  1. Die MQ-Gruppierung beinhaltet die MQMD- und MQRFH2-Header. Beachten Sie, dass es sich hierbei um die Definition der Headerstruktur handelt; während der Laufzeit werden Quellenparser automatisch von einer Zuordnung verarbeitet. Für ein MQRFH2-Ziel wählt die Zuordnung dynamisch in Brokern der Version 5 den MQRFH2-Parser und in Brokern der Version 6 den leistungsfähigeren MQRFH2C-Parser aus.
    Sämtlicher ESQL-Code, der einer Nachrichtenzuordnung nachgeschaltet ist und den MQRFH2-Header zuordnet (im Gegensatz zum Kopieren über die Funktion zum Kopieren aller Header), muss mit dem richtigen Parsernamen für diesen Header konfiguriert werden.
  2. Die HTTP-Gruppierung umfasst alle Standardheader; sonstige HTTP-Header werden ignoriert. Wenn Sie angepasste HTTP-Header verarbeiten müssen, müssen Sie einen ESQL-Rechenknoten (Compute) konfigurieren, um die Zuordnung aufzurufen. Siehe Beschreibung unten.
  3. Die JMS-Gruppierung beinhaltet die JMS-Standardheader. Zur Verarbeitung angepasster Versionen müssen Sie den angepassten JMS-Header in einer Nachrichtengruppe definieren und einen ESQL-Rechenknoten (Compute) konfigurieren, um die Zuordnung aufzurufen. Siehe Beschreibung unten.
Header-Modell

Zurück zum Anfang.

Mehrere Ausgabenachrichten erstellen

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:

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.

Zurück zum Anfang.

Mehrere Ausgabenachrichten für ein Wiederholungsfeld erstellen

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.

Stapelwiederholung

Zurück zum Anfang.

Mehrere Ausgabenachrichten für eine mehrteilige Eingabenachricht erstellen

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.

Stapelwiederholung

Zurück zum Anfang.

Mehrere Ausgabenachrichten für sich nicht wiederholende Eingaben erstellen

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.

Stapelwiederholung

Zurück zum Anfang.

Felder in einer Nachricht sortieren, gruppieren oder anders anordnen

Die Musterdateien für dieses Szenario befinden sich im Ordner sorting im Projekt Message Map Sample Message Flows. Hierbei gibt es 2 Varianten:

Sortierung mit bereits bekannten Schlüsseln

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.

Sortierung mit Schlüsseln aus einer Datenbank

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:

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.

Zurück zum Anfang.

Eine Zuordnung aus ESQL aufrufen

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:

Eine Submap im Assistenten für neue Nachrichtenzuordnungen erstellen

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.

Zurück zum Anfang.

Nachrichtenzuordnung in einem Aggregationsszenario verwenden

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.

Zurück zum Anfang.

XML-Schemaszenarios

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.

Zurück zum Anfang.

Platzhalterelemente

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.

Mehrteilige 'Envelope'-Nachricht

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.

Mehrteilige 'Contained'-Nachricht

Zurück zum Anfang.

Typenvererbung

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.

Zurück zum Anfang.

Substitutionsgruppen

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.

Zurück zum Anfang.

Sich wiederholende Modellgruppen

Die Musterdateien für dieses Szenario befinden sich im Ordner modelgroups im Projekt Message Map Sample Message Flows.

Zurück zum Anfang.

Symbol für die Hauptseite   Zurück zum Beginn des Beispielprogramms