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.

HTTPAsyncRequest-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.

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:

Symbol für HTTPRequest-Knoten

HTTPAsyncRequest-Knoten zur Ausgabe einer Anforderung an einen Web-Service verwenden

Eine HTTP-Anforderung besteht aus zwei Teilen:
  1. Der URL eines Service.
  2. Einem Datenstrom, der vom fernen Server verarbeitet wird, um eine Antwort zurückzusenden, bei der es sich häufig um eine SOAP-Nachricht oder eine andere Web-Service-Nachricht in XML handelt.

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.

Zeitlimits

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.

HTTPAsyncRequest-Knoten in einem Nachrichtenfluss verwenden

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.

Fehler behandeln

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.

Terminals und Eigenschaften

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:
  • http://Hostname muss angegeben werden.
  • Der Standardwert für Port ist 80. Wenn Sie einen Wert angeben, muss er vor der Portnummer einen ':' enthalten.
  • Der Standardwert für Pfad ist '/'. Wenn Sie einen Wert angeben, müssen Sie vor dem Pfad einen Schrägstrich (/) eingeben.

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):

  1. X-Original-HTTP-URL im HTTPRequest-Header in der Eingabenachricht
  2. LocalEnvironment.Destination.HTTP.RequestURL in der Eingabenachricht
  3. Die Eigenschaft URL des Web-Service

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:
  • SSL. Diese Option ist die Standardeinstellung. Bei dieser Option wird zunächst versucht, über das SSLv3-Protokoll eine Verbindung herzustellen, beim Handshake darf jedoch auf das SSLv2-Protokoll zurückgegriffen werden, wenn der zugrundeliegende JSSE-Provider das SSLv2-Protokoll unterstützt.
  • SSLv3. Bei dieser Option wird nur versucht, die Verbindung über das SSLv3-Protokoll herzustellen. Es ist nicht möglich, auf SSLv2 zurückzugreifen.
  • TLS. Bei dieser Option wird nur versucht, die Verbindung über das TLS-Protokoll herzustellen. Es ist nicht möglich, auf SSLv3 oder SSLv2 zurückzugreifen.
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 HTTP-Standard-Header auf Basis der Eingabe generieren ausgewählt haben und die Eingabenachricht einen HTTPRequestHeader umfasst, extrahiert der HTTPAsyncRequest-Knoten Web-Service-Header aus dem Eingabe-HTTPRequestHeader und fügt alle eindeutigen Web-Service-Header (außer 'Host', siehe nachfolgende Tabelle) aus einem HTTPInputHeader hinzu, falls in der Eingabenachricht ein solcher Header enthalten ist. (Ein HTTPInputHeader ist möglicherweise vorhanden, wenn der HTTPInput-Knoten eine Eingabenachricht von einem Web-Service empfangen hat.)

    Vom HTTPAsyncRequest-Knoten werden außerdem die in der folgenden Tabelle aufgeführten Web-Service-Header mit Standardwerten hinzugefügt, sofern diese nicht im HTTPRequestHeader oder im HTTPInputHeader vorhanden sind.

    Header Standardwert
    SOAPAction "" (leere Zeichenfolge)
    Content-Type text/xml; charset=CCSID des Nachrichtenhauptteils

    Wenn sich die Eingabenachricht nicht in der JSON-Domäne befindet, bei der der Standard wie folgt lautet:

    application/json; charset=CCSID des Nachrichtenhauptteils

    Host Der Hostname, an den die Anforderung gesendet werden soll.

    Der HTTPAsyncRequest-Knoten fügt ebenfalls den optionalen Header 'Content-Length' mit dem korrekt errechneten Wert hinzu, selbst wenn dieser Wert nicht im HTTPRequest- oder HTTPInput-Header vorhanden ist.

  • Wenn Sie die Option HTTP-Standard-Header auf Basis der Eingabe generieren ausgewählt haben und die Eingabenachricht keinen HTTPRequestHeader umfasst, extrahiert der HTTPAsyncRequest-Knoten die Web-Service-Header (mit Ausnahme von 'Host') aus dem HTTPInputHeader (sofern dieser in der Eingabenachricht enthalten ist). Der HTTPAsyncRequest-Knoten fügt die erforderlichen Web-Service-Header mit Standardwerten hinzu, sofern diese Werte nicht im HTTPInputHeader vorhanden sind.
  • Wenn Sie die Option HTTP-Standard-Header auf Basis der Eingabe generieren abgewählt haben und die Eingabenachricht einen HTTPRequestHeader umfasst, extrahiert der Knoten alle Web-Service-Header aus dem Eingabe-HTTPRequestHeader. Vom Knoten wird weder geprüft, ob in der Eingabenachricht ein HTTPInputHeader vorhanden ist, noch werden die erforderlichen Web-Service-Header hinzugefügt, wenn sie nicht vom HTTPRequestHeader bereitgestellt werden.
  • Wenn Sie die Option HTTP-Standard-Header auf Basis der Eingabe generieren abgewählt haben und die Eingabenachricht keinen HTTPRequestHeader umfasst, werden keine Web-Service-Header generiert. Vom HTTPAsyncRequest-Knoten wird weder geprüft, ob in der Eingabenachricht ein HTTPInputHeader vorhanden ist, noch werden die erforderlichen Web-Service-Header hinzugefügt. Die Anforderungsnachricht wird ohne HTTPRequestHeader an den Web-Service weitergegeben. Dies führt in der Regel dazu, dass vom Web-Service ein Fehler generiert wird, es sei denn, der Web-Service ist für die Bearbeitung der Nachrichteninhalte konfiguriert.
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:
  • Wenn für Komprimierung verwenden nicht der Standardwert Keine angegeben ist, wird der HTTP-Header 'Content-Encoding' mit diesem Wert belegt und der Bitstrom wird komprimiert. Ist der Header 'Content-Encoding' bereits in einem bestehenden HTTP-Header vorhanden, wird dieses Feld mit dem Wert der Eigenschaft Komprimierung verwenden aktualisiert. Beginnt der vorhandene Header 'Content-Encoding' bereits mit der angegebenen Komprimierungsfunktion, erfolgt keine weitere Komprimierung. Startet der Header 'Content-Encoding' mit deflate (komprimieren), findet keine Komprimierung statt, dabei spielt es keine Rolle, ob ZLIB (komprimieren) oder komprimieren ausgewählt ist.
  • Wenn Sie Komprimierte Antworten akzeptieren ausgewählt haben, wird das Feld 'Accept-Encoding' ausgefüllt. Ist dieses Feld bereits in einem bestehenden HTTP-Header vorhanden, wird die Eigenschaft auf dem Knoten mit dem vorhandenen Wert überschrieben. Allerdings werden empfangene komprimierte Antworten nicht dekomprimiert.
 
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
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

In der lokalen Umgebung können Sie festgelegte Werte auf die gleiche Weise wie bei anderen Elementen einer Nachricht dynamisch überschreiben. Die folgenden Werte können unter LocalEnvironment.Destination.HTTP festgelegt werden.
Einstellung Beschreibung
Compression Überschreibt die Eigenschaft Use compression (Komprimierung verwenden) des Knotens. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.Compression =
 'gzip';
Zur Festlegung einer Mindestgröße (in Byte), ab der komprimiert wird, verwenden Sie folgende Überschreibung:
SET OutputLocalEnvironment.Destination.HTTP.MinimumCompressionSize = 1048576;
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:
DECLARE CRLF CHAR CAST(X'0D0A' AS CHAR CCSID 1208);
SET OutputLocalEnvironment.Destination.HTTP.ProxyConnectHeaders =
'Proxy-Authorization: Basic Zm5lcmJsZTpwYXNzd29yZA==' || CRLF || 
'Proxy-Connection: Keep-Alive' || CRLF;
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:
SET OutputRoot.HTTPRequestHeader."Proxy-Authorization" = 'Basic Zm5lcmJsZTpwYXNzd29yZA==';
SET OutputRoot.HTTPRequestHeader."Proxy-Connection" = 'Keep-Alive';
ProxyURL Überschreibt die Eigenschaft HTTP(S)-Proxyadresse auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.ProxyURL = 'my.proxy';
QueryString Ermöglicht die Einstellung der Parameter für abgehende Abfragezeichenfolgen. Jeder Parameter muss separat definiert werden. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.QueryString.param1 = 'my"Value"1';
SET OutputLocalEnvironment.Destination.HTTP.QueryString.param2 = 'my"Value"2';
Dieser ESQL-Code verschlüsselt die folgende Abfragezeichenfolge (gemäßhttp://tools.ietf.org/html/rfc3986) für die abgehende Anforderung:
?param1=my%22Value%221&param2= my%22Value%222
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:
SET OutputLocalEnvironment.Destination.HTTP.QueryStringCCSID = 943;
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:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.RequestURI = '/abc/def';
RequestLine.HTTPVersion Überschreibt die Eigenschaft HTTP-Version auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.HTTPVersion = 'HTTP/1.1';
RequestLine.Method Überschreibt die Eigenschaft HTTP-Methode auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.Method = 'GET';
RequestURL Überschreibt die Eigenschaft Web-Service-URL auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.RequestURL = 'http://ibm.com/abc/';
SSLProtocol Überschreibt das SSL-Protokoll. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.SSLProtocol = 'TLS';

Folgende Werte sind gültig: SSL, SSLv3 und TLS.

SSLCiphers Überschreibt die Eigenschaft Erlaubte SSL-Verschlüsselungen auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.SSLCiphers =
 'SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA';
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.
SET OutputLocalEnvironment.Destination.HTTP.UserContext = x'aabbccddeeff11223344556677889900';
In UserContext gespeicherte Daten müssen im BLOB-Format sein.

Mit WrittenDestination-Daten arbeiten

Nachdem die Anforderung gestellt wurde, wird der Ordner 'WrittenDestination' in der lokalen Umgebung mit dem URI, an den die Anforderung gesendet wurde, sowie mit Komprimierungsdetails (falls verwendet) aktualisiert. Ein WrittenDestination-Eintrag für einen HTTPAsyncRequest-Knoten hat das folgende Format, wobei die WS-Adressierung nur vorhanden ist, wenn sie genutzt wird:
WrittenDestination = (
   HTTP  = (
      RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
      Compression   = (
        OriginalSize = 53 (INTEGER)
        CompressedSize = 71 (INTEGER)
      )
   )
)
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 | bc19308_