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:
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.
Je nach Konfiguration erstellt dieser Knoten aus den angegebenen Inhalten der Eingabenachricht eine HTTP- bzw. eine HTTP over SSL-Anforderung (HTTPS) und sendet diese an den Web-Service. Der HTTPAsyncResponse-Knoten empfängt die Antwort vom Web-Service und analysiert sie, um sie in seine Ausgabebaumstruktur aufzunehmen. Der HTTPAsyncRequest-Knoten generiert HTTP-Header, falls diese in Ihrer Konfiguration erforderlich sind.
Der HTTPAsyncRequest-Knoten befindet sich im HTTP-Fach der Palette und wird im WebSphere Message Broker Toolkit durch folgendes Symbol dargestellt:
Die URL weist folgendes Format auf: http://<Adresse>[:<Port>]/<Funktion>. Beispiel: http://localhost:7080/request. Diese URL kann statisch in den HTTPAsyncRequest-Knotenparametern als Feld in der Nachricht selbst oder dynamisch als Feld in der lokalen Umgebung festgelegt werden.
Die Daten müssen sich in den meisten Anforderungen im Format CCSID 1208 befinden. Wenn die Anforderung erfolgreich ist, wird die HTTP-Antwort an den paarigen HTTPAsyncResponse-Knoten zurückgegeben.
Sie können über einen HTTP-Proxy eine Anforderung über eine temporäre Site weiterleiten. Mit der Ausführung von Tools als Proxy können Sie die Anforderung und die Antwort anzeigen und so Fehler in Ihren Nachrichtenflüssen beheben. Die HTTP-Zieladresse ergibt sich aus der Position des Proxy. Wenn Sie für die HTTP-Zieladresse 'localhost' (lokaler Host) angeben und der HTTP-Proxy auf einem anderen Rechner aktiv ist, wird die Anforderung an den fernen Proxy-Rechner und nicht an den Rechner, vom dem die Anforderung ursprünglich ausgegeben wurde, weitergeleitet.
Sie können 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, werden die Anforderung und eine Ausnahmebedingung an das Fehlerterminal des HTTPAsyncRequest-Knotens weitergegeben. Entsprechend wird eine Ausnahmebedingung 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 seltenen Fällen kann eine Zeitlimitüberschreitung auftreten, wenn der Anforderungsknoten Daten an den Server sendet. Dann wird das Fehlerterminal des HTTPAsyncRequest-Knotens verwendet.
Der HTTPAsyncRequest-Knoten kann in jedem Nachrichtenfluss verwendet werden, in dem eine HTTP-Anforderung gesendet und eine Antwort asynchron empfangen werden müssen. Das häufigste Beispiel ist ein Nachrichtenfluss, der einen Web-Service aufruft.
Weitere Informationen zum Arbeiten mit HTTP finden Sie im Abschnitt HTTP-Nachrichten verarbeiten.
Der Knoten interagiert über TCP/IP direkt mit einem externen Service; deshalb können Fehler auftreten, die durch TCP/IP verursacht werden. Beispiele für solche Fehler sind no route to host (Keine Verbindung zum Host) oder connection refused (Verbindung abgelehnt). Wenn der Knoten derartige Fehler feststellt, generiert er eine Ausnahmebedingung, füllt die Ausnahmeliste mit den empfangenen Fehlerdaten und leitet die Eingabenachricht unverändert an das Fehlerterminal weiter.
In der folgenden Tabelle werden die HTTPAsyncRequest-Knotenterminals beschrieben .
Terminal | Beschreibung |
---|---|
Eingabeterminal (In) | Das Eingabeterminal, das eine Nachricht zur Verarbeitung durch einen Knoten annimmt |
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. |
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 HTTPAsyncRequest-Knotens beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung |
---|---|---|---|---|
Knotenname | Nein | Nein | Knotentyp, z. B. HTTPAsyncRequest | 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 folgenden Tabelle werden die grundlegenden Eigenschaften des HTTPAsyncRequest-Knotens beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung | Eigenschaft des Befehls mqsiapplybaroverride |
---|---|---|---|---|---|
Eindeutige ID | Ja | Nein | Diese Eigenschaft ist die eindeutige Kennung, durch die einHTTPAsyncRequest- und ein HTTPAsyncResponse-Knoten verknüpft werden. | asyncResponseCorrelator | |
Web-Service-URL | Ja | Ja | Die URL des Web-Service. Sie muss im Format
http://Hostname[:Port]/[Pfad]
angegeben werden; dabei gilt Folgendes:
Der HTTPAsyncRequest-Knoten stellt die URL des Web-Service fest, an den eine Anforderung gesendet werden soll. Sie haben die Auswahl zwischen den folgenden drei Optionen: diese werden vom Knoten in der angegebenen Reihenfolge geprüft (die erste Option setzt also immer die zweite außer Kraft und die zweite Option die dritte):
Die ersten beiden Optionen bieten dynamische Methoden zur Festlegung einer URL für jede Eingabenachricht, die den Nachrichtenfluss durchläuft. Um eine dieser Optionen verwenden zu können, müssen Sie vor dem HTTPAsyncRequest-Knoten einen Compute-Knoten in den Nachrichtenfluss einfügen, mit dem der erforderliche Wert erstellt und initialisiert wird. Bei der dritten Option wird ein Wert bereitgestellt, der für jede in diesem Knoten empfangene Nachricht festgelegt ist. Legen Sie diese Eigenschaft so fest, dass sie eine Standardeinstellung enthält, die verwendet wird, wenn die anderen Felder nicht erzeugt wurden oder einen Nullwert enthalten. Wenn eines der Felder einen Wert enthält, wird die Einstellung dieser Eigenschaft ignoriert. Die Eigenschaft URL des Web-Service muss eine gültige URL enthalten, da die Implementierung sonst fehlschlägt. Sie müssen außerdem sicherstellen, dass der Wert, den Sie in 'X-Original-HTTP-URL' oder in 'LocalEnvironment.Destination.HTTP.RequestURL' angeben, auch eine gültige URL ist; ist dies nicht der Fall, verwendet der Knoten die Standardeinstellung aus der Eigenschaft Web-Service-URL. |
URLSpecifier | |
Zeitlimit für Anforderung (Sekunden) | Ja | Ja | 120 | Der Wert für die Zeit, die auf eine Antwort vom fernen Web-Server an den
HTTPAsyncResponse-Knoten gewartet wird. Der gültige
Bereich liegt zwischen 1 und (231)-1. Werte, die eine unbegrenzte Wartedauer angeben,
sind nicht zulässig. Weitere Informationen zum Zeitlimitverhalten finden Sie im Abschnitt Zeitlimits. |
timeoutForServer |
In der folgenden Tabelle werden die Eigenschaften für die HTTP-Einstellungen des HTTPAsyncRequest-Knotens beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung | Eigenschaft des Befehls mqsiapplybaroverride |
---|---|---|---|---|---|
HTTP(S)-Proxyadresse | Nein | Ja | Die Adresse des Proxy-Servers fest, an den Anforderungen gesendet werden. Dieser Wert muss das Format Hostname:Port haben. | httpProxyLocation | |
HTTP-Methode | Nein | Nein | POST | Die HTTP-Methode. Folgende Werte sind gültig: POST, GET, PUT, DELETE und HEAD. Standardmäßig verwendet der HTTPAsyncRequest-Knoten beim Aufbau einer Verbindung zum fernen Web-Server die HTTP-Methode POST. Mithilfe von HEAD wird ermittelt, ob ein Service verfügbar ist, beispielsweise von einem Netzdispatcher, der herausfinden möchte, welche Server verfügbar sind. Die richtigen Header (einschließlich content-length) werden zurückgesendet, enthalten jedoch keine Hauptteildaten. | |
Use compression (Komprimierung verwenden) | Nein | Ja | Ohne | Diese Eigenschaft bestimmt, ob der Inhalt der HTTP-Anforderung komprimiert wird. Zur Auswahl stehen die Optionen keine, gzip, zlib (komprimieren) und komprimieren. Wenn die Anforderung komprimiert wird, wird der Content-Encoding-Header gesetzt. Dieser weist darauf hin, dass der Inhalt komprimiert ist. Der Wert zlib (komprimieren) steht für eine Kombination aus RFC 1950 + RFC 1951. Der Wert komprimieren steht nur für RFC 1951. Der Standardwert lautet Keine, der Inhalt der Anforderung wird also nicht komprimiert. |
requestCompressionType |
Die SSL-Eigenschaften des HTTPAsyncRequest-Knotens werden in der folgenden Tabelle beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung | Eigenschaft des Befehls mqsiapplybaroverride |
---|---|---|---|---|---|
Protokoll | Nein | Ja | TLS | Gibt die SSL-Eigenschaft Protocol
für die Übergabe einer HTTPS-Anforderung an. Beide Seiten einer SSL-Verbindung müssen sich auf die Verwendung eines Protokolls einigen. Daher muss ein Protokoll ausgewählt werden, das vom fernen Server akzeptiert werden kann. Folgende Optionen stehen zur Verfügung:
|
protocol |
Erlaubte SSL-Verschlüsselungen | Nein | Ja | Eine durch Kommas getrennte Liste von Verschlüsselungen, die bei der
Erstellung einer SSL-Anforderung verwendet wird. Hier können Sie einen einzelnen Chiffrierwert (z. B. SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) oder eine Liste von Chiffrierwerten angeben, die als die einzigen Chiffrierwerte für diese Verbindung verwendet werden. Es muss dabei mindestens ein Chiffrierwert vorhanden sein, der vom fernen Server akzeptiert wird. Als Trennzeichen zwischen den Chiffrierwerten wird ein Komma verwendet. Der Standardwert ist eine leere Zeichenfolge. Er ermöglicht es dem Knoten, während des SSL-Verbindungs-Handshakes einen beliebigen oder alle verfügbaren Chiffrierwerte zu verwenden. Dadurch steht der größtmögliche Bereich für die Herstellung einer erfolgreichen SSL-Verbindung zur Verfügung. |
allowedCiphers | |
Hostnamenprüfung für SSL-Zertifikat aktivieren | Nein | Ja | Ja | Diese Eigenschaft gibt an, ob der Hostname des Servers, der die Anforderung empfängt, mit dem Hostnamen im SSL-Zertifikat übereinstimmen muss. | hostnameChecking |
Schlüsselaliasname für die SSL-Clientauthentifizierung | Nein | Ja | "" (leere Zeichenfolge) | Diese Eigenschaft legt den SSL-Authentifizierungsalias für die Clientseite einer HTTPAsyncRequest-Verbindung fest. Bei der Standardeinstellung wird automatisch der erste geeignete Schlüssel ausgewählt. | keyAlias |
In der folgenden Tabelle werden die erweiterten Eigenschaften des HTTPAsyncRequest-Knotens beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung | Eigenschaft des Befehls mqsiapplybaroverride | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
HTTP-Standard-Header auf Basis von Eingabe generieren | Nein | Nein | Ausgewählt | Wenn Sie dieses Kontrollkästchen aktivieren, wird ein HTTPRequestHeader
generiert. Wenn Sie das Kontrollkästchen inaktivieren, muss die Eingabenachricht einen gültigen
HTTPRequestHeader enthalten. Um den Inhalt des HTTPRequest-Headers zu steuern, der in der Anforderungsnachricht eingeschlossen ist, beziehen Sie einen Compute-Knoten mit ein, welcher der Eingabenachricht einen HTTPRequest-Header vor diesem HTTPAsyncRequest-Knoten im Nachrichtenfluss hinzufügt, und heben Sie die Auswahl dieses Kontrollkästchens auf.
Wenn Sie die Option Komprimierung verwenden oder Accept compressed responses by default (Standardmäßig komprimierte Antworten akzeptieren) ausgewählt haben, werden die HTTP-Header-Felder 'Content-Encoding' und 'Accept-Encoding' mit Werten belegt, wobei es keine Rolle spielt, ob Sie die Option HTTP-Standard-Header auf Basis der Eingabe generieren ausgewählt haben:
|
|||||||||
Accept compressed responses by default (Standardmäßig komprimierte Antworten akzeptieren) | Nein | Ja | Nicht ausgewählt | Über diese Eigenschaft wird festgelegt, ob komprimierte Antworten
standardmäßig vom HTTPAsyncResponse-Knoten bearbeitet
werden. Enthält der Anforderungsheader keinen Accept-Encoding-Header, wird der
Accept-Encoding-Header bei Auswahl dieser Option vom Knoten auf "gzip, deflate" (gzip,
komprimieren) gesetzt. Alle empfangenen komprimierten Antworten werden dann vom Antwortknoten
dekomprimiert. Umfasst die an den HTTPAsyncResponse-Knoten weitergegebene Nachricht einen Accept-Encoding-Header, sollten alle komprimierten Antworten vom Nachrichtenfluss oder der Clientanwendung bearbeitet werden. Die Auswahl dieser Option hat somit in diesem Falle keine Auswirkungen. |
acceptCompressedResponses |
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. |
Einstellung | Beschreibung |
---|---|
Compression | Überschreibt die Eigenschaft Use compression (Komprimierung verwenden) des Knotens. Beispiel:
Zur Festlegung einer Mindestgröße (in Byte), ab der komprimiert wird, verwenden Sie folgende Überschreibung:
|
ProxyConnectHeaders | Gibt zusätzliche Header
an, die verwendet werden, wenn es sich bei der abgehenden Anforderung um eine SSL-Verbindung über
einen Proxy handelt. Diese zusätzlichen Header werden mit der einleitenden CONNECT-Anforderung an
den Proxy gesendet. Sie können beispielsweise Proxy-Authentifizierungsdaten an einen Proxy-Server
senden, wenn Sie SSL verwenden. Es können mehrere Header gesendet werden, die jedoch alle durch
einen Rücklauf und einen Zeilenvorschub (ASCII 0x0D 0x0A) in Übereinstimmung mit RFC2616 getrennt
sein müssen; Beispiel:
Diese Einstellung wird nur verwendet, wenn es
sich bei der Anforderung um eine SSL-Anforderung über einen Proxy-Server handelt. Um
Proxy-Authentifizierungsdaten für eine Nicht-SSL-Anforderung zu senden, müssen Sie die einzelnen
Header im Ordner 'HTTPRequestHeader' angeben, so wie im folgenden Beispiel gezeigt:
|
ProxyURL | Überschreibt die Eigenschaft HTTP(S)-Proxyadresse auf dem Knoten. Beispiel:
|
QueryString | Ermöglicht die Einstellung der Parameter für abgehende Abfragezeichenfolgen. Jeder Parameter muss separat definiert werden. Beispiel:
Dieser ESQL-Code verschlüsselt die folgende Abfragezeichenfolge (gemäßhttp://tools.ietf.org/html/rfc3986) für die abgehende Anforderung:
Wenn die Ziel-URL bereits Abfrageparameter enthält, werden die hier angegebenen Parameter an die
vorhandene Liste angefügt. |
QueryStringCCSID | Gibt an, dass die Abfragezeichenfolgeparameter vor der Codierung in einen
anderen Zeichensatz als den Standardzeichensatz UTF-8 konvertiert werden müssen. Alle
Abfragezeichenfolgeparameter werden zuerst in die angegebene ID des codierten Zeichensatzes
konvertiert, bevor die Ergebniszeichenfolge gemäß
RFC3986 codiert wird.
Beispiel:
Der
oben gezeigte ESQL-Code bewirkt, dass alle QueryString-Parameter vor ihrer Codierung in die
Codepage 943 konvertiert werden. Hinweis: Alle Abfragezeichenfolgeparameter müssen die Daten in
Unicode enthalten. |
RequestLine.RequestURI | Überschreibt RequestURI, den Pfad hinter URL und Port. Beispiel:
|
RequestLine.HTTPVersion | Überschreibt die Eigenschaft HTTP-Version auf dem Knoten. Beispiel:
|
RequestLine.Method | Überschreibt die Eigenschaft HTTP-Methode auf dem Knoten. Beispiel:
|
RequestURL | Überschreibt die Eigenschaft Web-Service-URL auf dem Knoten. Beispiel:
|
SSLProtocol | Überschreibt das SSL-Protokoll.
Beispiel:
Folgende Werte sind gültig: SSL, SSLv3 und TLS. |
SSLCiphers | Überschreibt die Eigenschaft Erlaubte SSL-Verschlüsselungen auf dem Knoten. Beispiel:
|
UserContext | Sie können BLOB-Kontextdaten an der folgenden Position in der lokalen Umgebung speichern. Diese Daten können später vom HTTPAsyncResponse-Knoten abgerufen werden.
In UserContext gespeicherte Daten müssen im BLOB-Format sein. |
WrittenDestination = (
HTTP = (
RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
Compression = (
OriginalSize = 53 (INTEGER)
CompressedSize = 71 (INTEGER)
)
)
)