WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

HTTPAsyncResponse-Knoten

Mit dem HTTPAsyncRequest-Knoten können Sie in Verbindung mit dem HTTPAsyncResponse-Knoten ein Nachrichtenflusspaar erstellen, das asynchron mit einem Web-Service interagiert.

Dieses Thema ist in folgende Abschnitte eingeteilt:

Zweck

Der HTTPAsyncRequest-Knoten sendet eine Web-Service-Anforderung, wartet jedoch nicht auf den Empfang der entsprechenden Web-Service-Antwort. Die Web-Service-Antwort wird von dem HTTPAsyncResponse-Knoten empfangen, der sich zwar in einem separaten Nachrichtenfluss befinden kann, aber in derselben Ausführungsgruppe befinden muss. Die Knoten werden als Paar verwendet und stellen anhand einer eindeutigen ID eine Korrelation zwischen den Antworten und den ursprünglichen Anforderungen her. Der HTTPAsyncRequest-Knoten übergibt das Anforderungs-Socket an den HTTPAsyncResponse-Knoten, damit der Back-End-Server ihn für die Antwort verwendet. Wenn der Back-End-Server eine lange Latenzzeit aufweist, antwortet er möglicherweise nicht innerhalb des Socketzeitlimits.

Die Übergabe des HTTP-Sockets an den HTTPAsyncResponse-Knoten ermöglicht es dem Nachrichtenfluss, die nächste Nachricht aus der Warteschlange abzurufen, ohne auf die Antwort warten zu müssen. Auf diese Weise nutzt er Threads und Speicher effizienter als ein synchroner Nachrichtenfluss.

Der HTTPAsyncResponse-Knoten bearbeitet Nachrichten in den folgenden Nachrichtendomänen:

  • DFDL
  • XMLNSC
  • JSON
  • BLOB
  • MIME
  • MRM
  • XMLNS

Der HTTPAsyncResponse-Knoten befindet sich im HTTP-Fach der Palette und wird im WebSphere Message Broker Toolkit durch folgendes Symbol dargestellt:

Symbol für HTTPRequest-Knoten

HTTPAsyncResponse-Knoten in einem Nachrichtenfluss verwenden

Verwenden Sie den HTTPAsyncResponse-Knoten und den HTTPAsyncRequest-Knoten als paarige Knoten, um eine HTTP-Anforderung zu stellen und asynchron eine Antwort zu empfangen. Der HTTPAsyncRequest-Knoten sendet eine Anforderung an den Web-Service. Der HTTPAsyncResponse-Knoten empfängt die Antwort vom Web-Service und analysiert sie, um sie in seine Ausgabebaumstruktur aufzunehmen.

Weitere Informationen zum Arbeiten mit HTTP finden Sie im Abschnitt HTTP-Nachrichten verarbeiten.

Wenn die lokale Umgebungseigenschaft LocalEnvironment.Destination.HTTP.RequestIdentifier an den paarigen HTTPAsyncRequest-Knoten übergeben wurde, wird sie an die lokale Umgebung für den HTTPAsyncResponse-Knoten übermittelt.

Fehler behandeln

Der Knoten interagiert über TCP/IP direkt mit einem externen Service, sodass folgende Fehlerarten auftreten können:

  • Fehler, die von TCP/IP generiert werden, z. B. connection reset by peer (Verbindung vom Peer zurückgesetzt).

    Wenn der Knoten diese Fehler erkennt, generiert er eine Ausnahmebedingung und leitet sie an das Fehlerterminal weiter.

  • Fehler, die vom Web-Server zurückgegeben werden. Dabei handelt es sich um HTTP-Statuscodes, die außerhalb des Bereichs von 100 bis 299 liegen. Wenn der Knoten diese Fehler erkennt, leitet er die Anwort an das Fehlerterminal weiter, unter Beachtung der Eigenschaften, die auf der Registerkarte Fehler angegeben sind.

    Die Antwort wird als BLOB-Nachricht erstellt, da der Knoten das Format der Antwort nicht bestimmen kann. Antworten mit einem Umleitungsstatuscode (3xx) werden auf dieselbe Weise behandelt.

HTTP-Antwortcodes

Der HTTPAsyncResponse-Knoten behandelt die Statuscodes der Serie 100 als Fortsetzungsantwort, löscht die aktuelle Antwort und wartet auf eine andere Antwort des Web-Servers.

Die Statuscodes der Serie 200 werden als Erfolg behandelt. Die Knoteneigenschaften bestimmen das Format der generierten Ausgabenachricht und die Antwort wird an das Ausgabeterminal des Knotens weitergeleitet.

Die Statuscodes der Serie 300 werden zur Umadressierung verwendet. Der HTTPAsyncResponse-Knoten unterstützt keine Umleitungen; Umleitungscodes werden deshalb als Fehler behandelt.

Die Statuscodes der Serien 400 und 500 sind Fehler. Wenn die Anforderung vom HTTPAsyncRequest-Knoten zwar erfolgreich versendet wird, der Web-Service jedoch nicht erfolgreich ist, wird die HTTP-Antwort (HTTPResponse) in die Nachrichtenbaumstruktur eingefügt und an das Fehlerterminal des HTTPAsyncResponse-Knotens weitergegeben. Möglicherweise muss diese Antwort mithilfe eines Compute-Knotens in eine entsprechende Codepage umgesetzt werden, bevor die Daten angezeigt werden können. Beispiel:
Set OutputRoot.XMLNS.error850 = CAST(InputRoot.XMLNS.error.BLOB as CHAR CCSID 850);
Informationen zu HTTP finden Sie unter Hypertext Transfer Protocol - HTTP/1.1. Weitere Informationen zu HTTP-Rückkehrcodes finden Sie unter HTTP-Antwortcodes.

Zeitlimits

Sie können auf dem HTTPAsyncRequest-Knoten ein Zeitlimitintervall festlegen. Wenn die gesamte Anforderung/Antwort-Operation mehr Zeit als angegeben benötigt, wird die Anforderung an das Fehlerterminal auf einem der paarweise verbundenen Knoten weitergegeben. Das Zeitlimitintervall beginnt in dem Moment, in dem die Anforderung vom HTTPAsyncRequest-Knoten gesendet wird, und endet in dem Moment, in dem die Antwort vom HTTPAsyncResponse-Knoten empfangen wird.

Der HTTPAsyncRequest-Knoten verwendet für jede von ihm verarbeitete Anforderung eine Verbindung, um die Anforderung zu senden, und übergibt die Verbindung an den paarigen HTTPAsyncResponse-Knoten, damit dieser die Antwort sendet. Wurde ein Zeitlimitintervall angegeben, wird das Socket nach Ablauf des Intervalls geschlossen. Damit wird sichergestellt, dass eine Anforderung nur die korrekte Antwort erhält. Alle Antwortdaten für eine Anforderung mit überschrittenem Zeitlimit werden gelöscht.

Die Anforderung/Antwort-Verarbeitung wird zwischen dem HTTPAsyncRequest-Knoten und dem HTTPAsyncResponse-Knoten aufgeteilt. Tritt während der Anforderungsphase der Verarbeitung eine Zeitlimitüberschreitung auf, wird eine Ausnahmebedingung an das Fehlerterminal des HTTPAsyncRequest-Knotens weitergegeben. Entsprechend wird die Anforderung an das Fehlerterminal des HTTPAsyncResponse-Knotens weitergegeben, wenn während der Antwortphase der Verarbeitung eine Zeitlimitüberschreitung auftritt.

Eine Zeitlimitüberschreitung tritt meistens dann auf, wenn auf eine Serverantwort gewartet wird. In diesen Fällen wird das Fehlerterminal des HTTPAsyncResponse-Knotens verwendet. In einigen Fällen kann eine Zeitlimitüberschreitung auftreten, wenn der Anforderungsknoten Daten an den Server sendet. Dann wird das Fehlerterminal des HTTPAsyncRequest-Knotens verwendet.

Header bearbeiten

Der HTTPResponse-Header, in dem die vom fernen Web-Service zurückgegebenen Header enthalten sind, bildet den ersten Header in der Nachricht (nach den Eigenschaften), der vom Knoten weitergegeben wird. Dieser Vorgang erfolgt unabhängig von den ausgewählten Optionen. Wenn die Antwort des HTTPAsyncResponse-Knotens in eine WebSphere MQ-Warteschlange gestellt werden soll, müssen Sie die Header deshalb so bearbeiten, dass es sich bei dem ersten Header nach den Eigenschaften um einen MQMD-Header handelt.

Das folgende Beispiel enthält ESQL-Code, der den HTTP-Header entfernt:
SET OutputRoot = InputRoot;
SET OutputRoot.HTTPResponseHeader = NULL; 
Das folgende Beispiel enthält ESQL-Code zum Verschieben des HTTP-Headers und somit zur Beibehaltung der damit bereitgestellten Informationen:
SET OutputRoot = InputRoot;
DECLARE HTTPHeaderRef REFERENCE TO OutputRoot.HTTPResponseHeader;
DETACH HTTPHeaderRef;
ATTACH HTTPHeaderRef TO OutputRoot.MQMD AS NEXTSIBLING;

Terminals und Eigenschaften

In der folgenden Tabelle werden die HTTPAsyncResponse-Knotenterminals beschrieben .

Terminal Beschreibung
Fehlerterminal (Failure) Das Ausgabeterminal, an das die Eingabenachricht geleitet wird, wenn während der Verarbeitung im Knoten ein Fehler auftritt.
Ausgang Das Ausgabeterminal, an das die Nachricht weitergeleitet wird, wenn sie für eine erfolgreiche Beendigung der Web-Service-Anforderung steht und innerhalb des Nachrichtenflusses eine weitere Verarbeitung erforderlich ist.
Fehler Das Ausgabeterminal, an das Nachrichten mit einem HTTP-Statuscode, der nicht im Bereich 200 bis 299 liegt, einschließlich Umleitungscodes (3xx), weitergegeben werden. Der HTTPAsyncResponse-Knoten unterstützt keine Umleitungen.
Catch-Terminal Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn nachgeschaltet eine Ausnahmebedingung ausgegeben und von diesem Knoten abgefangen wurde.

In den folgenden Tabellen werden die Knoteneigenschaften beschrieben. Die Spalte O zeigt an, ob die Eigenschaft obligatorisch ist (markiert mit einem Sternchen in der Anzeige, wenn ein Wert eingegeben werden muss, weil kein Standardwert definiert ist). Die Spalte K zeigt an, ob die Eigenschaft konfigurierbar ist (Wert kann geändert werden, wenn der Nachrichtenfluss zur BAR-Datei hinzugefügt wird, um ihn einzusetzen).

In der folgenden Tabelle werden die Beschreibungseigenschaften des HTTPAsyncResponse-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung
Knotenname Nein Nein Knotentyp, z. B. HTTPAsyncResponse Der Name des Knotens.
Kurzbeschreibung Nein Nein   Kurze Beschreibung des Knotens.
Langbeschreibung Nein Nein   Text, der den Zweck des Knotens im Nachrichtenfluss beschreibt.

In der nachfolgenden Tabelle werden die grundlegenden Eigenschaften des HTTPAsyncResponse-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Eindeutige ID Ja Nein   Geben Sie die eindeutige Kennung an, durch die das Paar aus HTTPAsyncRequest- und HTTPAsyncResponse-Knoten verknüpft werden. asyncRequestCorrelator

In der folgenden Tabelle werden die Eigenschaften von 'Syntaxanalyse der Antwortnachricht' des HTTPAsyncResponse-Knotens beschrieben.

Eigenschaft M C Standardwert Beschreibung
Nachrichtendomäne Nein Nein BLOB (Binary large object) Die Domäne für die Syntaxanalyse der Nachricht. Wenn das Feld leer ist, ist der Standardwert BLOB.
Nachrichtenmodell Nein Nein Nicht ausgewählt Der Name bzw. die Position der Nachrichtenmodell-Schemadatei, in der die Nachricht definiert ist. Diese Liste ist mit allen verfügbaren Nachrichtenmodell-Schemadateien für die ausgewählte Nachrichtendomäne gefüllt.
Nachricht Nein Nein Nicht ausgewählt Der Name bzw. die Position des Nachrichtenstamms innerhalb der Nachrichtenmodell-Schemadatei. Diese Liste wird mit allen verfügbaren Nachrichten belegt, die in dem von Ihnen ausgewählten Nachrichtenmodell definiert sind.
Physisches Format Nein Nein Nicht ausgewählt Der Name des physischen Formats der Nachricht. Wenn Sie den MRM- oder IDOC-Parser verwenden, wählen Sie das physische Format der ankommenden Nachricht aus der Liste aus. Diese Liste umfasst alle physischen Formate, die für das ausgewählte Nachrichtenmodell definiert wurden. Wenn Sie die Eigenschaft Nachrichtendomäne auf DataObject setzen, können Sie diese Eigenschaft auf XML oder SAP ALE IDoc setzen. Legen Sie für diese Eigenschaft SAP ALE IDoc fest, wenn ein Bitstrom aus einer externen Quelle analysiert und eine Nachrichtenbaumstruktur generiert werden muss.

In der folgenden Tabelle werden die Eigenschaften für die Parser-Optionen des HTTPAsyncResponse-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung
Zeitpunkt für Syntaxanalyse Nein Nein Bei Bedarf Durch diese Eigenschaft wird gesteuert, zu welchem Zeitpunkt eine Antwortnachricht syntaktisch analysiert wird. Gültige Werte sind Bei Bedarf, Sofort und Vollständig. Der Standardwert Bei Bedarf bewirkt, dass das Analysieren der Nachricht verzögert wird.

Eine vollständige Beschreibung dieser Eigenschaft finden Sie unter Bedarfsgerechte Syntaxanalyse.

Baumstruktur unter Verwendung von XML-Schemadatentypen erstellen Nein Nein Nicht ausgewählt Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser Syntaxelemente in der Nachrichtenbaumstruktur mit Datentypen erstellt, die aus dem XML-Schema entnommen wurden. Diese Eigenschaft kann nur ausgewählt werden, wenn für die Eigenschaft Auswerten auf der Registerkarte Auswertung Inhalt oder Inhalt und Wert festgelegt wurde.
XMLNSC-Kompaktparser für XMLNS-Domäne verwenden Nein Nein Nicht ausgewählt Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Kompaktparser für Nachrichten in der XMLNS-Domäne verwendet wird. Wenn Sie diese Eigenschaft festlegen, werden die Antwortnachrichtendaten in Knoten, die mit dem Ausgabeterminal verbunden sind, unter XMLNSC angezeigt, wenn es sich beim MQRFH2-Eingabeheader oder der Eigenschaft 'Domäne' unter 'Syntaxanalyse der Antwortnachricht' um XMLNS handelt.
Zugriff auf gemischten Inhalt Nein Nein Nicht ausgewählt Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser beim Feststellen von gemischtem Text in einer Antwortnachricht Elemente in der Nachrichtenbaumstruktur erstellt. Wenn Sie das Kontrollkästchen aktivieren, werden Elemente für gemischten Text erstellt. Andernfalls wird gemischter Text ignoriert und es werden keine Elemente erstellt.
Kommentare beibehalten Nein Nein Nicht ausgewählt Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser beim Feststellen von Kommentaren in einer Antwortnachricht Elemente in der Nachrichtenbaumstruktur erstellt. Wenn Sie das Kontrollkästchen aktivieren, werden Elemente für Kommentare erstellt. Andernfalls werden Kommentare ignoriert und es werden keine Elemente erstellt.
Verarbeitungsanweisung beibehalten Nein Nein Nicht ausgewählt Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser Elemente in der Nachrichtenbaumstruktur erstellt, wenn er Verarbeitungsanweisungen in einer Antwortnachricht feststellt. Wenn Sie das Kontrollkästchen aktivieren, werden Elemente für Verarbeitungsanweisungen erstellt. Andernfalls werden Verarbeitungsanweisungen ignoriert und es werden keine Elemente erstellt.
Nicht transparente Elemente Nein Nein Leer Diese Eigenschaft legt eine Liste der Elemente der Antwortnachricht fest, die vom XMLNSC-Parser nicht transparent analysiert werden sollen. Die nicht transparente Syntaxanalyse wird nur ausgeführt, wenn keine Gültigkeitsprüfung aktiviert ist (das heißt, wenn die Eigenschaft Auswerten auf Keine gesetzt ist); Einträge, die in Nicht transparente Elemente angegeben sind, werden ignoriert, wenn die Gültigkeitsprüfung aktiviert ist.

In der folgenden Tabelle werden die Validierungseigenschaften des HTTPAsyncResponse-Knotens beschrieben.

Eine vollständige Beschreibung zu diesen Eigenschaften erhalten Sie unter Auswertungseigenschaften.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Auswertung Nein Ja Ohne Durch diese Eigenschaft wird gesteuert, ob eine Auswertung stattfindet. Gültige Werte sind Keine, Inhalt und Wert, Inhalt und Übernehmen.

Sie finden detaillierte Informationen hierzu unter Nachrichten überprüfen und Auswertungseigenschaften.

validateMaster
Fehlerbehebungsmaßnahme Nein Nein Ausnahme Durch diese Eigenschaft wird gesteuert, was beim Fehlschlagen der Auswertung geschieht. Diese Eigenschaft kann nur angegeben werden, wenn Auswerten auf Inhalt oder Inhalt und Wert gesetzt ist. Gültige Werte sind Benutzertrace, Lokales Fehlerprotokoll, Ausnahmebedingung und Ausnahmeliste.  
Die Überwachungseigenschaften des Knotens werden in der folgenden Tabelle beschrieben.
Eigenschaft O K Standardwert Beschreibung
Ereignisse Nein Nein Ohne Auf dieser Registerkarte werden Ereignisse angezeigt, die Sie für den Knoten definiert haben. Standardmäßig sind für keinen Knoten in einem Nachrichtenfluss Überwachungsereignisse definiert. Über Hinzufügen, Bearbeiten und Löschen können Sie Überwachungsereignisse für den Knoten erstellen, ändern oder löschen (Details siehe Überwachungsereignisquellen mithilfe von Überwachungseigenschaften konfigurieren).

Sie können hier angezeigte Ereignisse aktivieren oder inaktivieren, indem Sie das Kontrollkästchen Aktiviert aktivieren oder inaktivieren.

Überschreibungen der lokalen Umgebung

Sie können Informationen, die vom verknüpften HTTPAsyncRequest-Knoten festgelegt wurden, aus der folgenden Eigenschaft unter 'LocalEnvironment.Destination.HTTP' abrufen:

Einstellung Beschreibung
UserContext Kontextdaten, die vom HTTPAsyncRequest-Knoten gespeichert wurden, können aus der folgenden Position in der lokalen Umgebung abgerufen werden:
SET myVar = InputLocalEnvironment.Destination.HTTP.UserContext;
Kontextdaten werden als großes Binärobjekt (BLOB) gespeichert. Wenn Sie Kontextdaten abrufen möchten, ordnen Sie die Variable mit dem Typ BLOB zu oder verwenden Sie einen CAST-Ausdruck. Beispiel:
DECLARE myVar BLOB;
SET myVar = InputLocalEnvironment.Destination.HTTP.UserContext;
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:22:26


ReferenzthemaReferenzthema | Version 8.0.0.5 | bc19309_