Informationen zum Mustercode 'IMS Synchronous Request'
Im Mustercode 'IMS Synchronous Request' wird der IMSRequest-Knoten verwendet. Eine Übersicht über die Funktionsweise und Konfiguration dieses Knotens finden Sie unter IBM Information Management System (IMS) in der Dokumentation zu WebSphere Message Broker.
Im Bespielprogramm wird eine DSPALLI-Transaktion (Display All Invoices) verwendet. Dabei handelt es sich um
eine IMS-Mustertransaktion, die normalerweise auf einem IMS-System installiert ist. Vergewissern Sie sich vor Verwendung dieses Mustercodes beim
Systemadministrator, dass diese Transaktion installiert ist. Je nach der Konfiguration der DSPALLI-Transaktion kann damit ein
REXX-Programm (DFSSAM07) oder ein COBOL-Programm (DFSSAM7) ausgeführt werden, um Details
zu Rechnungen abzurufen. Obwohl diese Programme dieselbe Funktion erfüllen und zu
denselben logischen Daten führen, weisen sie bei der Verbindung unterschiedliche
physische Formate auf (z. B. unterschiedliche Größenfelder und zusätzliche Segmente). Standardmäßig
ist die DSPALLI-Transaktion auf 'REXX' eingestellt. Sie können die Einstellung ändern,
sodass die DSPALLI-Transaktion stattdessen COBOL verwendet, doch in diesem Fall müssen
Sie das COBOL-Programm auch kompilieren und verknüpfen, da es nicht in einsatzbereitem
Zustand zum Lieferumfang gehört. Dieser Mustercode funktioniert mit beiden
Programmen. Zu Beginn lässt sich der Aufbau von Nachrichtenflüssen, die den
Anforderungsknoten verwenden, leichter anhand der REXX-Version nachvollziehen. Die COBOL-Version wird jedoch schneller ausgeführt als die REXX-Version.
Der Musternachrichtenfluss verdeutlicht, wie ein Nachrichtenfluss in WebSphere Message
Broker für die Interaktion mit einem IMS-System aufgebaut sein kann.
Die folgenden zwei
Aspekte müssen bei der Interaktion mit IMS berücksichtigt werden:
- Die Verbindung und Interaktion mit IMS Connect
- Der Aufbau der IMS-Nachricht, mit der eine IMS-Transaktion (oder IMS-Befehl)
ausgelöst wird
Die Unterscheidung zwischen diesen beiden Elementen ist wichtig, weil die IMS-Nachricht
selbst nicht einfach nur zu verarbeitende Daten enthält, sondern auch
Strukturinformationen zur Größe der Daten (LIZZ-Datei zu Beginn eines jeden
Nachrichtensegments) sowie Metadaten mit Informationen zur Verarbeitungsweise der Daten
(der Transaktions- oder Befehlsname ist der erste Teil der Daten).
Erläuterungen zur Struktur dieser Nachrichten finden Sie im Abschnitt IBM Information Management System (IMS).
Der IMSRequest-Knoten stellt Konnektivität zu IMS Connect her und ermöglicht die Auswahl
des Festschreibungsmodus und der Synchronisationsebene, unter denen die Transaktion
ausgeführt wird. Im Mustercode sind diese Eigenschaften auf die Standardwerte eingestellt: Der Festschreibungsmodus lautet send_then_commit und
die Synchronsisationsebene lautet confirm. Diese Werte werden
normalerweise beim Ausführen einer synchronen Anforderung verwendet. Der Knoten erwartet
den Empfang einer Nachrichtenbaumstruktur, die er in eine IMS-Nachricht mit bereits
festgelegten LLZZ-Daten serialisieren kann. Außerdem leitet er den Antwortbitstrom von
IMS an den Parser weiter, der auf der Registerkarte Syntaxanalyse
der Antwortnachricht des Anforderungsknotens konfiguriert ist.
Von 'DSPALLI' verwendete Nachrichtenstrukturen
Die in diesem Mustercode verwendete DSPALLI-Transaktion benötigt eine
Eingabenachricht mit nur einem Segment und erstellt eine Ausgabenachricht mit
mehreren Segmenten. Die tatsächliche Anzahl der für die Ausgabe erstellten Segmente hängt
von der Verarbeitung durch das Programm ab. Bei Verwendung der REXX-Version des Programms
besteht eine Nachricht über erfolgreiche Ausführung aus fünf Segmenten, die zu Beginn
der Nachricht einen Header bilden, und je einem Segment für jede angezeigte Rechnung. Bei der COBOL-Version sind es drei Segmente, die von den Rechnungssegmenten gefolgt
werden.
Sie können die beiden Formate daran unterscheiden, dass das dritte Segment beim
COBOL-Format Daten enthält, während dies beim REXX-Format nicht der Fall ist.
Sofern die REXX-Version nicht ausdrücklich erwähnt ist, beziehen sich die
Informationen in diesem Thema ausschließlich auf die COBOL-Version, weil weitaus mehr
Anwendungen in COBOL als in REXX geschrieben werden und WebSphere Message Broker
den Import von COBOL-Copybooks unterstützt, wodurch die Entwicklung der erforderlichen Nachrichtengruppe erleichtert wird.
Wenn ein Fehler auftritt, wird von 'DSPALLI' eine
Antwort mit nur einen Segment zurückgegeben, dass die Fehlerursache enthält.
Die COBOL-Strukturen für die COBOL-Version befinden sich in folgendem Programm: SRC
DFSSAM7.
Darin sind die Strukturen für jedes vom Programm
verwendete Segment definiert.
Das Programm verwendet die folgenden drei Hauptsegmente:
- TERM-IN-AREA. Dies ist das Eingabesegment, das den Transaktionsnamen und die zu
verarbeitenden Daten enthält.
- DETAIL-OUT. Dieses Segmente wird für jede Rechnung wiederholt und enthält die
Details der jeweiligen Rechnung.
- REJECT-MESSAGE. Mit diesem Segment wird eine Fehlernachricht zurückgegeben, wenn
die Ausführung der Transaktion fehlschlägt.
Das Programm enthält darüber hinaus auch Datenstrukturen für andere Segmente, bei denen
es sich jedoch um Header-Strukturen handelt, die für diesen Mustercode nicht
relevant sind und deshalb auch nicht importiert werden müssen. Diese Segmente können
einfach in der Form 'LL' plus dem Rest der Daten ungeparst bleiben.
Wie bei den Eingabesegmenten vieler anderer Transaktionen wird auch dem Segment
'TERM-IN-AREA' die Transaktion als Präfix voran gestellt:
006010 01 TERM-IN-AREA. 00350000
006020 02 CHAR-COUNT PICTURE S99 COMPUTATIONAL. 00360000
006030 02 FILLER PICTURE S99 COMPUTATIONAL. 00370000
006040 02 TRANS-CODE PICTURE X(7). 00380000
006050 02 MESSAGE-TEXT-START PICTURE X(125). 00380000
Folgende Schlüsselstrukturen werden verwendet:
- CHAR-COUNT: Das Feld 'LL'. Das Programm kann diesem Feld einen beliebigen
Namen geben (in diesem Fall 'CHAR-COUNT'). Es enthält immer den Datentyp 'S99'.
- FILLER: Das Feld 'ZZ'. Dieses Feld wird vom Programm nie verwendet und muss
die Leerzeichen bereitstellen, die das Feld im Bitstrom verwendet.
In diesem Fall hat das
Programm es als Füllzeichenfeld bezeichnet.
- TRANS-CODE: Die Transaktion, die zum Aufrufen dieses Programms ausgeführt wurde. Die Standardregeln besagen, dass die Größe dieses Feldes dem Transaktionscode plus
ein Leerzeichen entspricht, es sei denn, die Transaktion enthält acht Zeichen. Bei 'DISAPPI' entspricht das Feld der Größe der Transaktion ohne Leerzeichen. Deshalb muss das Segment 'MESSAGE-TEXT-START' mit einem Leerzeichen beginnen.
- MESSAGE-TEXT-START: Die Eingabedaten mit einer Länge von 125 Byte. Bei unterschiedlichen Programmen kann diese Feld eine unterschiedliche Größe haben. Die maximale Größe beträgt 32 KB. Beim Erstellen einer Nachrichtendefinition in MRM können Sie die Eigenschaft Längeneinheiten auf Ende des Bitstroms setzen, statt einen bestimmten Wert für die Länge dieses Felds festzulegen.
Die Ausgabenachricht über erfolgreiche Ausführung besteht aus drei Headerabschnitten und
einem sich wiederholenden Detailabschnitt.
- HEADER-1-AREA
- HEADER-2-AREA
- HEADER-3-AREA
- DETAIL-OUT
Der Mustercode parst nur den Detailabschnitt und lässt die Headerabschnitte
ungeparst. Im folgenden Abschnitt,
MRM-Nachrichtengruppe für 'DSPALLI' erstellen,
wird erläutert, wie diese Syntaxanalyse in MRM ausgeführt werden kann.
Im folgenden Mustercode werden die ersten paar Zeilen des Segments 'DETAIL-OUT'
dargestellt. Die vollständige Struktur finden Sie im Abschnitt
DFSSAM7.
010010 01 DETAIL-OUT. 00900000
010020 02 DO-CHAR-CNT PICTURE S99 VALUE +84 COMP. 00910000
010030 02 FILLER PICTURE S99 VALUE +0 COMP. 00920000
010050 02 DO-LINE-CNT PICTURE Z9. 00930000
010055 02 FILLER PICTURE X VALUE '.'. 00940000
010060 02 FILLER PICTURE XX VALUE SPACES. 00950000
Folgende Schlüsselstrukturen werden verwendet:
- DO-CHAR-CNT: Das Feld 'LL'. Für dieses Feld gibt es keine Namenskonvention.
Die Größe dieses Feldes, bei dem es sich um ein Feldgrößensegment handelt, ist immer
84, was den Aufbau eines Nachrichtentyps, der auf diesem Format basiert, sehr vereinfacht.
- FILLER: Das erste Füllzeichen wird für die ZZ-Daten verwendet. Die anderen Füllzeichen dienen der Formatierung. Viele Transaktionen verwenden keine
Formatierungsfüllzeichen, weil die Formatierung für das Endterminal von MFS ausgeführt
wird. Der IMSRequest-Knoten verarbeitet ausschließlich Transaktionsdaten, die nicht von MFS
konvertiert wurden.
- DO-LINE-CNT: Die ersten Anwendungsdaten in der Struktur 'DETAIL-OUT'. In diesem Feld wird die Zeilennummer des Detailsegments angegeben (es können mehrere
Instanzen dieses Segments vorhanden sein).
- ...: Wird für alle Anwendungsdatenfelder wiederholt.
Das letzte im Mustercode verwendete Segment ist
REJECT-MESSAGE. Es wird ausgegeben, wenn beim
Abrufen der Rechnungsdetails durch die Transaktion ein Fehler auftritt
(normalerweise wegen einer ungültigen Teilenummer):
015010 01 REJECT-MESSAGE. 01450000
015020 02 REJ-CHAR-CNT PICTURE S99 COMPUTATIONAL. 01460000
015030 02 FILLER PICTURE S99 COMPUTATIONAL VALUE +0. 01470000
015050 02 FILLER PICTURE X(8) VALUE '.PART = '. 01480000
015060 02 REJ-PN PICTURE X(16) VALUE SPACES. 01490000
015070 02 REJECT-REASON PICTURE X(110). 01500000
Folgende Schlüsselstrukturen werden verwendet:
- REJ-CHAR-CNT: Das Feld 'LL'.
- FILLER: Das erste Füllzeichen wird für die ZZ-Daten verwendet. Die anderen Füllzeichen dienen der Formatierung. Viele Transaktionen verwenden keine
Formatierungsfüllzeichen, weil die Formatierung für das Endterminal von MFS ausgeführt
wird. Der IMSRequest-Knoten verarbeitet ausschließlich Transaktionsdaten, die nicht von MFS
konvertiert wurden.
- REJ-PN: Der Ursachencode für den Fehler. Dieses Feld wird im Mustercode nicht verwendet.
- REJECT-REASON: Die Ursachenbeschreibung für die Ablehnung.
MRM-Nachrichtgruppe für 'DSPALLI' erstellen
Alle für 'DSPALLI' erforderlichen Datenstrukturen sind im Programm DFSSAM7 enthalten. Als erster Schritt beim Erstellen einer MRM-Nachrichtengruppe werden die erforderlichen Strukturen mithilfe des
COBOL-Importprogramms in eine Nachrichtengruppe importiert. Führen Sie dazu folgende
Schritte aus:
- Erstellen Sie eine neue Nachrichtengruppe mit dem binären physischen Format COBOL.
- Erweitern Sie die neue Nachrichtengruppe, klicken Sie mit der rechten Maustaste
auf den Ordner Nachrichtendefinition und klicken Sie
anschließend auf Neu > Nachrichtendefinitionsdatei aus >
COBOL-Datei.
- Suchen Sie nach der Datei DFSSAM7.cbl
(die entweder von Ihrem eigenen System abgerufen oder aus
DFSSAM7 extrahiert wurde).
- Klicken Sie auf Weiter, um den Bildschirm 'Message and Structure Selection' ((Nachrichten- und Strukturenauswahl) aufzurufen. Fügen Sie dem Abschnitt
Import Structure (Importstruktur) die drei
Strukturen 'TERM-IN-AREA', 'DETAIL-OUT' und 'REJECT-MESSAGE' hinzu.
- Aktivieren Sie die Kontrollkästchen neben 'TERM-IN-AREA' und 'REJECT-MESSAGE',
damit Nachrichtentypen für diese Elemente erstellt werden. 'DETAIL-OUT' ist kein eigener
Nachrichtentyp, sondern nur ein Teil einer Antwortnachricht.
Lassen Sie alle anderen
Optionen unverändert.
- Klicken Sie auf Weiter und dann auch Fertigstellen.
Es wird eine neue Nachrichtendefinition mit dem
Namen 'DSPALLI' erstellt, die zwei Nachrichtentypen enthält: msg_TERMINAREA
und msg_TERMINAREA.
Die Transaktion 'DSPALLI' kann je nachdem, welche Ereignisse im Programm auftreten
(z. B. bei einem Fehler), unterschiedliche Strukturen zurückgeben. Um dies zu erreichen
führt der Mustercode die Syntaxanalyse der Antwort zunächst mit einer allgemeinen
Struktur aus, um die Antwort in Segmente aufzuteilen. Anschließend ermittelt er die
korrekte Struktur für das jeweilige Segment und führt die Syntaxanalyse erneut damit aus. Um die allgemeine Struktur (die für die Antwort einer jeden IMS-Transaktion verwendet
werden kann) zu erstellen, führen Sie folgende Schritte aus:
- Öffnen Sie die Nachrichtendefinition 'DSPALLI' im Editor, klicken Sie mit der
rechten Maustaste auf Nachrichten und auf Nachricht hinzufügen.
- Geben Sie für die neue Nachricht den Namen
msg_IMSMessage an.
- Klicken Sie mit der rechten Maustaste auf Typen und klicken Sie auf Komplexen Typ hinzufügen.
- Geben Sie für den Typ den Namen
segmentType an.
- Fügen Sie msg_IMSMessage ein neues
Element vom Typ segment mit dem Namen
IMSSegment hinzu.
Stellen Sie sicher, dass der Parameter Maximale Anzahl des Elements den Wert -1 (unbegrenzt) hat.
- Fügen Sie dem Typ zwei lokale Elemente hinzu: eines mit dem Namen
LL und eines mit dem Namen ZZdata. Dem Feld LL muss der Datentyp int zugeordnet sein und das Feld ZZdata muss den Datentyp string (Zeichenfolge) aufweisen.

- Wählen Sie das Feld 'ZZdata' aus und wechseln Sie von Übersicht nach Eigenschaften.
- Ändern Sie die physische Darstellung der COBOL-Felder von
Länge in Längenverweis.
- Setzen Sie das Feld Längenverweis auf LL.
- Wählen Sie die Option Einschließender Längenverweis
aus, weil das Feld LL der Länge des gesamten Segments
einschließlich 'LL' und 'ZZ' entspricht.
Mit dem Nachrichtentyp msg_IMSMessage kann
jetzt jede beliebige IMS-Antwortnachricht syntaktisch analysiert und dabei in
einzelne Segmente aufgeteilt werden (eine Syntaxanalyse der einzelnen Segmente ist
jedoch nicht möglich). Der Mustercode führt zunächst mit diesem Nachrichtentyp eine
Syntaxanalyse der Rückantwort vom IMS-System aus und unterzieht die Antwort danach einer
weiteren Syntaxanalyse mit einem anderen Nachrichtentyp.
Der Fehlernachrichtentyp msg_REJECTMESSAGE wurde für die Verarbeitung
abgelehnter Nachrichten bereits definiert.
Der letzte erforderliche Nachrichtentyp ist der
Typ für Nachrichten über die erfolgreiche Ausführung. Er enthält alle Segmente vom Typ
'DETAIL-OUT':
- Öffnen Sie die Nachrichtendefinition 'DSPALLI' im Editor, klicken Sie mit der
rechten Maustaste auf Nachrichten und klicken Sie
anschließend auf Nachricht hinzufügen.
- Geben Sie für den neuen Nachrichttyp den Namen
msg_COBOLRESPONSE an.
- Fügen Sie dem neuen Typ zwei Elemente hinzu: eines mit dem Namen
IMSSegment vom Typ
segmentType und eines mit dem Namen
msg_DETAILOUT vom Typ
DETAILOUT.
- Für das Element IMSSegment müssen die
Parameter Mindestanzahl und
Maximale Anzahl jeweils mit dem Wert 3 angegeben werden (für die drei Headersegmente, die nicht syntaktisch analysiert werden).
- Für das Segment msg_DETAILOUT muss
der Parameter Mindestanzahl mit dem Wert 0 und
der Parameter Maximale Anzahl mit dem Wert unbegrenzt (-1) angegeben werden.
Alle erforderlichen Datenstrukturen sind erstellt worden. Der Nachrichtenfluss des
Mustercodes veranschaulicht, wie es mithilfe dieser Strukturen möglich ist, zunächst
XML-Dokumente den IMS-Anforderungen zuzuordnen, anschließend die IMS-Antworten syntaktisch
zu analysieren und diese schließlich erneut den XML-Dokumenten zuzuordnen.
Funktionsweise des Nachrichtenflusses
Die Grundfunktion des Mustercodes besteht darin, eine XML-Nachricht aus einer WebSpere MQ-Warteschlange abzurufen, sie in eine IMS-Anforderung umzuwandeln, die Transaktion in IMS auszuführen und die Antwort erneut in eine XML-Nachricht umzuwandeln und in eine WebSphere MQ-Warteschlange einzureihen. Der Nachrichtenfluss ist im folgenden Diagramm dargestellt:

Die für die einzelnen Knoten aufgeschlüsselte Verarbeitung ist in folgender Liste
beschrieben:
- Der MQInput-Knoten ruft die Nachricht aus der Warteschlange 'IMS_SYNC_REQUEST_IN1'
ab und führt mit dem XML-Parser eine Syntaxanalyse aus.
- Der InputMapping-Knoten ordnet der Nachricht
msg_TERMINAREA die XML-Struktur zu.
Außerdem berechnet der Knoten den Wert für das Feld 'LL', der nicht automatisch vom
Nachrichtentyp generiert werden kann.
- Der Rechenknoten 'SaveMQMD' speichert die MQMD, um die Nachrichten-IDs und Korrelations-IDs zu sichern. (Dieser Knoten kann ausgelassen werden, wenn Sie eine andere Transportmethode verwenden oder die Nachrichten-IDs und Korrelations-IDs für die Antwortnachricht nicht benötigt werden.)
- Der IMSRequest-Knoten serialisiert die Daten und sendet sie zur Ausführung an IMS.
Der Knoten führt mithilfe des allgemeinen Nachrichtentyps
msg_IMSMessage eine Syntaxanalyse des
Rückgabebitstroms aus, um den Bitstrom in einzelne Segmente aufzuteilen.
- Der Filterknoten 'Reject?' zählt die Anzahl der Segmente: Wenn ein Segment vorhanden ist, wird ein Fehler gemeldet, und wenn mehrere Segmente vorhanden sind, wird der Erfolg gemeldet.
- Der untergeordnete Nachrichtenfluss 'ProcessSuccessReponse' sorgt für die erneute
Syntaxanalyse des Bitstroms, diesmal mit dem Format
msg_COBOLRESPONSE, und konvertiert ihn in ein
XML-Format.
- Der untergeordnete Nachrichtenfluss 'ProcessRejectResponse' sorgt für die erneute
Syntaxanalyse des Bitstroms, diesmal mit dem Nachrichtentyp
msg_REJECTMESSAGE, und ordnet ihn in einer
XML-Antwort zu.
- Der Rechenknoten 'RestoreMQMD' fügt die ursprüngliche MQMD hinzu.
- Der MQOutput-Knoten reiht die XML-Nachricht in die Warteschlange
'IMS_SYNC_REQUEST_OUT1' ein.
Der wichtigste Teil des Nachrichtenflusses ist die Syntaxanalyse der Antwortnachricht.
Diese Syntaxanalyse wird dadurch kompliziert, dass IMS-Transaktionen kein festes Muster
haben, sondern eine nicht festgelegte Anzahl oder Kombination von Segmenten zurückgeben
kann. Deshalb wird die Antwort im Nachrichtenfluss zunächst mit einem allgemeinen
Nachrichtentyp für segmentierte Nachrichten, der für alle zulässigen Rückgaben vom
IMSRequest-Knoten verwendet werden kann, syntaktisch analysiert. Erst dann wird die
Antwort in einem Filter-Knoten (oder einem beliebigen Routing-Knoten) logisch
ausgewertet, um die Nachricht an eine Verarbeitungsstufe weiterzuleiten, von der sie mit
einem anerkannten Nachrichtentyp erneut syntaktisch analysiert wird. Die hier verwendete allgemeine Logik kann auf jede beliebige IMS-Transaktion angewendet
werden, sofern die Segmentdefinitionen importiert (oder manuell erstellt) werden können
und die Segmente einige Daten enthalten, anhand derer ermittelt werden kann, welcher
Nachrichtentyp verwendet werden muss.
In diesem Nachrichtenfluss werden
ResetContentDescriptor-Knoten für die erneute Syntaxanalyse verwendet, die jedoch
auch mithilfe von ESQL-Anweisungen ausgeführt werden kann.
Funktionsweise eines Nachrichtenflusses mit der REXX-Version
Die vorangehende Beschreibung bezieht sich hauptsächlich auf COBOL. Der
Nachrichtenfluss funktioniert jedoch auch mit der REXX-Version des Programms, da für die
REXX-Version dieselbe Eingabenachricht wie für das COBOL-Programm verwendet wird. Der
Hauptunterschied besteht bei der Antwortnachricht. Die folgenden beiden
Hauptunterschiede bestehen zwischen den Antwortnachrichten:
- Bei der REXX-Version stehen fünf Headersegmente vor dem Detailabschnitt.
- Bei der REXX-Version hat jedes Datenfeld ein unterschiedliches physisches Format
(wobei Anzahl und Typen der Felder bei beiden Versionen identisch sind).
Deswegen sind für den Mustercode zwei unterschiedlich Antwortformate erforderlich: msg_COBOLRESPONSE
und msg_REXXRESPONSE. Der
Hauptunterschied zwischen diesen beiden Formaten besteht darin, dass bei der REXX-Version
fünf Headersegmente vor dem Detailsegment stehen.
Das Detailsegment ist dasselbe, doch
es wurde ein neues physisches REXX-Format hinzugefügt, mit dem die unterschiedlichen
Datentypen bearbeitet werden können. Bei der Syntaxanalyse der REXX-Antwort wird der
Nachrichtentyp msg_REXXRESPONSE mit dem Format
'REXX' verwendet.
Zurück zum Beginn des
Mustercodes