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.

HTTPRequest-Knoten

Über den HTTPRequest-Knoten ist eine Interaktion mit einem Web-Service möglich.

Dieses Thema ist in folgende Abschnitte eingeteilt:

Zweck

Der HTTPRequest-Knoten interagiert mit einem Web-Service. Dabei wird die gesamte Eingabenachricht oder ein Teil davon als Anforderung verwendet, die an den betreffenden Service gesendet wird. Sie können den Knoten auch so konfigurieren, dass aus den Inhalten der Eingabenachricht plus den Inhalten der Web-Service-Antwort eine Ausgabenachricht erstellt wird, bevor die Nachricht an nachfolgende Knoten im Nachrichtenfluss weitergegeben wird.

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 Knoten empfängt die Antwort vom Web-Service und analysiert diese zur Aufnahme in die Ausgabebaumstruktur. Falls gemäß der Konfiguration HTTP-Header erforderlich sind, werden diese vom Knoten generiert.

Dieser Knoten kann in einem Nachrichtenfluss verwendet werden, der einen HTTPInput- oder HTTPReply-Knoten enthält oder auch nicht enthält.

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

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

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

Symbol für HTTPRequest-Knoten

HTTPRequest-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 und zu dem dieser anschließend eine Antwort zurücksendet, wobei es sich oft 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. Sie kann in den Parametern des HTTPRequest-Knotens als Feld in der Nachricht selbst oder als Feld in der lokalen Umgebung festgelegt werden. Bei den an den Web-Service zu sendenden Daten kann es sich um die gesamte Nachrichtenbaumstruktur oder einen Teil davon handeln. Dies ist in den Eigenschaften des HTTPRequest-Knotens angegeben.

Die Daten müssen sich in den meisten Anforderungen im Format CCSID 1208 befinden. Die Antwort kann die Eingabenachricht ersetzen oder in die Nachrichtenbaumstruktur eingefügt werden. Die Einfügestelle ist in den Parametern des HTTPRequest-Knotens festgelegt. Die Domäne der Antwort ist XMLNS. Ist die Anforderung erfolgreich, wird HTTPReply an den Anfang und die Antwort an die festgelegte Stelle der Nachrichtenbaumstruktur eingefügt; die Anforderung wird an das Ausgabeterminal weitergegeben. Kann der HTTPRequest-Knoten die Anforderung nicht ausgeben, wird eine Ausnahmeliste in den Baum eingefügt und dieser an das Fehlerterminal weitergegeben.

Wenn die Anforderung vom HTTPRequest-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 weitergegeben. Der Parameter für den Speicherort der Fehlernachricht auf dem HTTPRequest-Knoten gibt an, an welcher Stelle im Baum die Antwort abgelegt wird. Beispiel: OutputRoot.XMLNS.error. 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.

Sie können ein Zeitlimitintervall festlegen. Wenn für die Anforderung mehr Zeit als angegeben benötigt wird, wird sie mit einer entsprechenden Nachricht an das Fehlerterminal weitergegeben. Für jede vom HTTPRequest-Knoten verarbeitete Anforderung wird eine Verbindung hergestellt, die beim Erhalt der Antwort wieder beendet wird. Wurde ein Zeitlimitintervall festgelegt, wird das Socket nach diesem Intervall 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.

Sie können mit dem HTTP-Proxy eine Anforderung über eine temporäre Site weiterleiten. Mit der Ausführung von Tools als Proxy können Sie die Anforderung und Antwort anzeigen und so die Fehler in Ihren Nachrichtenflüsse 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 ausgeführt wird, wird die Anforderung an den fernen Proxy-Rechner und nicht an den Rechner, vom dem die Anforderung ursprünglich ausgegeben wurde, weitergeleitet.

HTTPRequest-Knoten in einem Nachrichtenfluss verwenden

Der HTTPRequest-Knoten kann in jedem Nachrichtenfluss verwendet werden, in dem eine HTTP-Anforderung gesendet werden muss. Das häufigste Beispiel ist ein Nachrichtenfluss, der einen Web-Service aufruft.

Weitere Informationen zu Web-Services finden Sie im Abschnitt Web-Service-Nachrichten verarbeiten.

Fehler behandeln

Der Knoten interagiert über TCP/IP direkt mit einem externen Service; so dass es zu folgenden Fehlerarten kommen kann:

  • Fehler, die von TCP/IP generiert werden, z. B. 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.

  • 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. Wenn Sie diesen Knoten nicht für die Handhabung von Umadressierungen konfiguriert haben, werden Nachrichten mit einem Umadressierungscode (3xx) ebenfalls auf diese Art behandelt.

HTTP-Antwortcodes

Der HTTPRequest-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 Einstellungen auf den verschiedenen Registerkarten des Knotens bestimmen das Format der generierten Ausgabenachricht; die Antwort wird an das Ausgabeterminal des Knotens weitergeleitet.

Die Statuscodes der Serie 300 werden zur Umadressierung verwendet. Wenn die Eigenschaft HTTP(S)-Umadressierung folgen ausgewählt ist, sendet der Knoten die Anforderung erneut an die neue Zieladresse, die in der empfangenen Antwort angegeben ist. Wenn die Eigenschaft Der HTTP(s)-Umleitung folgen nicht ausgewählt wurde, werden die Codes als Fehler behandelt (wie im Abschnitt HTTPRequest-Knoten zur Ausgabe einer Anforderung an einen Web-Service verwenden beschrieben). Weitere Informationen zu HTTP-Rückkehrcodes finden Sie unter HTTP-Antwortcodes.

Bei den Statuscodes der Serie 400 und 500 handelt es sich um Fehler, die so behandelt werden, wie es im Abschnitt HTTPRequest-Knoten zur Ausgabe einer Anforderung an einen Web-Service verwenden beschrieben wird. Weitere Informationen zu HTTP-Rückkehrcodes finden Sie unter HTTP-Antwortcodes.

Header bearbeiten

Bei Auswahl von Eingabenachricht durch Antwort des Web-Service ersetzen oder Eingabe mit Fehler ersetzen wird der Header der Eingabenachricht (d. h. der Header, der zu der Nachricht gehört, wenn sie beim Eingangsterminal des HTTPRequest-Knotens ankommt) nicht mit der Nachricht weitergegeben, die den HTTPRequest-Knoten verlässt. Wenn jedoch eine der Eigenschaften ausgewählt wird, mit der eine Position in der Nachrichtenbaumstruktur angegeben wird, werden die Eingabenachrichtenheader weitergegeben.

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

Wenn Sie die Eingabenachricht durch eine Antwort ersetzen, können Sie die MQMD der Eingabenachricht vor dem HTTPRequest-Knoten in die Umgebungsbaumstruktur und anschließend nach dem HTTPRequest-Knoten zurück in die Nachrichtenbaumstruktur kopieren. Wenn Sie eine Position für die Antwort angeben, um vorhandene Eingabenachrichtenheader zu verwalten, müssen Sie den HTTP-Antwortheader verschieben oder entfernen, damit der MQMD-Header der erste Header ist.

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;

Den HTTPRequest-Knoten konfigurieren

Nachdem Sie eine Instanz des HTTPRequest-Knotens in einen Nachrichtenfluss eingereiht haben, können Sie ihn konfigurieren (siehe Nachrichtenflussknoten konfigurieren). Die Eigenschaften des Knotens werden in der Ansicht 'Eigenschaften' angezeigt.

Alle verbindlichen Eigenschaften, für die Sie einen Wert eingeben müssen, sind mit einem Sternchen gekennzeichnet.

Konfigurieren Sie den HTTPRequest-Knoten:

  1. Optional: Geben Sie auf der Registerkarte Beschreibung eine Kurzbeschreibung, eine ausführliche Beschreibung oder beides ein. Sie können den Knoten dort auch umbenennen.
  2. Auf der Registerkarte Grundeinstellungen:
    1. Der HTTPRequest-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 zu verwenden, müssen Sie vor dem HTTPRequest-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.

      Wenn eine URL mit http:// beginnt, sendet der Anforderungsknoten eine HTTP-Anforderung an die angegebene URL. Wenn die URL mit https:// beginnt, sendet der Anforderungsknoten eine HTTPS-Anforderung (HTTP over SSL) an die angegebene URL. Dabei werden die Parameter verwendet, die auf der SSL-Registerkarte des Knotens angegeben sind.

    2. Definieren Sie den Wert für die Eigenschaft Zeitlimit für Anforderung (Sekunden). Mit diesem Wert wird angegeben, wie viele Sekunden der Knoten auf eine Antwort des Web-Service wartet. Wird innerhalb dieser Zeitspanne eine Antwort empfangen, wird sie über das Ausgabeterminal an den übrigen Nachrichtenfluss weitergegeben. Andernfalls wird die Eingabenachricht über das Fehlerterminal weitergegeben, falls es angeschlossen ist. Wenn das Fehlerterminal nicht angeschlossen ist und nicht rechtzeitig eine Antwort eingeht, wird eine Ausnahmebedingung generiert.
  3. Auf der Registerkarte HTTP-Einstellungen:
    1. Geben Sie in HTTP(S)-Proxyadresse die Adresse des Proxy-Servers an, an den Anforderungen gesendet werden.
    2. Wählen Sie Der HTTP(S)-Umleitung folgen aus und geben Sie an, wie der Knoten Web-Service-Antworten handhaben soll, die einen HTTP-Statuscode zwischen 300 und 399 enthalten:
      • Wenn Sie das Kontrollkästchen aktivieren, folgt der Knoten der in der Antwort angegebenen Umleitung und gibt die Web-Service-Anforderung an die neue URL (im Nachrichteninhalt angegeben) aus.
      • Wenn Sie das Kontrollkästchen inaktivieren, folgt der Knoten nicht der angegebenen Umadressierung. Die Antwortnachricht wird an das Fehlerterminal weitergegeben.
    3. Wählen Sie für die Eigenschaft HTTP-Version eine der Optionen aus. Gültige Werte sind 1.0 und 1.1.

      Wenn Sie für die Eigenschaft HTTP-Version den Wert 1.1 auswählen, können Sie auch HTTP/1.1 Keepalive-Paket aktivieren wählen.

    4. Wählen Sie für die Eigenschaft HTTP-Methode eine der Optionen aus. Folgende Werte sind gültig: POST, GET, PUT, DELETE und HEAD.
    5. Wählen Sie eine der Optionen für die Eigenschaft Komprimierung verwenden aus und geben Sie damit an, wie die Inhalte der HTTP-Anforderung komprimiert werden sollen. Zur Auswahl stehen die Optionen gzip, zlib (komprimieren), komprimieren oder Keine. Der Wert zlib (komprimieren) steht für eine Kombination aus RFC 1950 und RFC 1951, der Wert komprimieren nur für RFC 1951. Der Standardwert lautet Keine, der Inhalt der Anforderung wird also nicht komprimiert.
  4. Wenn Sie HTTPS-Anforderungen (HTTP over SSL) verwenden möchten, legen Sie auf der Registerkarte SSL die Werte für HTTPS-Anforderungen fest:
    1. Wählen Sie die Protokoll-Eigenschaft aus, die Sie für die Anforderung verwenden möchten. 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.
    2. Legen Sie die Eigenschaft Erlaubte SSL-Verschlüsselungen fest. 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.
    3. Mit der Eigenschaft SSLKeyAlias legen Sie den SSL-Authentifizierungsaliasnamen für die Clientseite einer HTTP-Verbindung fest. Der Server überprüft eine Zugriffssteuerungsliste nach diesem clientseitigen Schlüssel. Der Schlüsselaliasname, der den Schlüssel im Broker- oder Ausführungsgruppenschlüsselspeicher identifiziert, der für die SSL-Verbindung verwendet werden soll. Legen Sie diese optionale Eigenschaft fest, wenn Ihr Schlüsselspeicher mehrere Schlüssel enthält. Der Standardwert "" (oder 'none') bedeutet, dass kein SSL-Schlüsselaliasname verwendet wird. Alle anderen Zeichenfolgewerte identifizieren den Aliasnamen .
  5. Legen Sie auf der Registerkarte Syntaxanalyse der Antwortnachricht Werte für die Eigenschaften zur Beschreibung der Nachrichtendomäne, der Nachrichtengruppe, des Nachrichtentyps und des Nachrichtenformats fest, anhand deren der Knoten feststellt, wie die vom Web-Service zurückgegebene Antwortnachricht analysiert werden soll. Wenn der Web-Service eine Fehlernachricht zurückgibt, werden die Werte dieser Eigenschaften ignoriert und die Nachricht wird vom BLOB-Parser syntaktisch analysiert.
    1. Wählen Sie aus der Liste unter Nachrichtendomäne den Namen des von Ihnen verwendeten Parsers aus. Wenn das Feld leer ist, ist der Standardwert BLOB. Folgende Optionen stehen zur Auswahl:
      • DFDL
      • XMLNSC
      • JSON
      • BLOB
      • MIME
      • MRM
      • XMLNS

      Sie können bei Bedarf auch einen benutzerdefinierten Parser angeben.

    2. Wenn Sie den DFDL-, den MRM- oder den XMLNSC-Parser im Prüfungsmodus verwenden, wählen Sie das relevante Nachrichtenmodell aus der Liste aus. Diese Liste wird mit den verfügbaren Nachrichtengruppen gefüllt, wenn Sie MRM oder XMLNSC als Nachrichtendomäne auswählen, bzw. mit den verfügbaren DFDL-Schemadateien, wenn Sie DFDL als Nachrichtendomäne auswählen.
    3. Wenn Sie den DFDL- oder den MRM-Parser verwenden, wählen Sie die korrekte Nachricht aus der Liste Nachricht aus. Diese Liste wird mit den im ausgewählten Nachrichtenmodell definierten Nachrichten gefüllt.
    4. Wenn Sie den MRM-Parser verwenden, wählen Sie das Format der Nachricht aus der Liste Physisches Format aus. Diese Liste enthält alle für dieses Nachrichtenmodell definierten physischen Formate.
  6. Auf der untergeordneten Registerkarte Parser-Optionen:
    1. Die Option Zeitpunkt für Syntaxanalyse ist standardmäßig auf Bei Bedarf gesetzt. Dies führt dazu, dass die Syntaxanalyse der Nachricht verzögert wird. Der Abschnitt Bedarfsgerechte Syntaxanalyse enthält Informationen zur sofortigen Analyse von Nachrichten.
    2. Wenn Sie den XMLNSC-Parser verwenden, legen Sie die Werte für die Eigenschaften fest, die bestimmen, wie der XMLNSC-Parser vorgeht. Weitere Informationen hierzu finden Sie im Abschnitt Nachrichten in der XMLNSC-Domäne bearbeiten.
  7. Legen Sie auf der Registerkarte Fehlerbehandlung Werte für die Eigenschaften fest, die bestimmen, wie eine vom Web-Service zurückgegebene Fehlernachricht behandelt wird:
    1. Behalten Sie die Auswahl Eingabe mit Fehler ersetzen (Standardeinstellung) bei, wenn die gesamte Fehlernachricht des Web-Service als Ausgabenachricht weitergegeben werden soll.

      Soll die Fehlernachricht des Web-Service zusammen mit Teilen des Inhalts der Eingabenachricht in die Ausgabenachricht aufgenommen werden, wählen Sie Eingabe mit Fehler ersetzen ab und definieren Sie die Eigenschaft Speicherposition der Fehlernachricht. Wenn Sie diese Eigenschaft abwählen, kopiert der Knoten die Eingabenachricht in die Ausgabenachricht und schreibt die Fehlernachricht des Web-Service über den Inhalt der Ausgabenachricht an der angegebenen Adresse (die Eingabenachricht selbst wird nicht geändert).

    2. Geben Sie im Feld Speicherposition der Fehlernachricht die Startadresse (innerhalb der Baumstruktur der Ausgabenachricht) ein, an der die syntaktisch analysierten Elemente aus dem Bitstrom der Fehlernachricht des Web-Service gespeichert werden. Diese Eigenschaft ist nur erforderlich, wenn Sie das Kontrollkästchen Eingabe mit Fehler ersetzen inaktiviert haben.

      Sie können jeden gültigen ESQL-Feldverweis eingeben, darunter auch Ausdrücke innerhalb des Verweises sowie neue Feldverweise (zum Erstellen eines Knotens in der Nachrichtenbaumstruktur für die Antwort). Geben Sie beispielsweise Folgendes ein:

      OutputRoot.XMLNSC.ABC.DEF
      Oder:
      Environment.WSError

      Wenn Sie Eingabe mit Fehler ersetzen auswählen, wird diese Eigenschaft ignoriert.

  8. Definieren Sie auf der Registerkarte Erweitert Werte für die erweiterten Eigenschaften, welche die Struktur und den Inhalt der Web-Service-Anforderung und -Antwort beschreiben:
    1. Geben Sie den Inhalt der an den Web-Service zu sendenden Anforderungsnachricht an:
      • Wenn der gesamte Hauptteil der Eingabenachricht in die Anforderungsnachricht aufgenommen werden soll, lassen Sie Gesamte Eingabenachricht als Anforderung verwenden aktiviert (dies entspricht der Standardeinstellung).

        Wenn die Anforderungsnachricht eine Untergruppe der Eingabenachricht enthalten soll, inaktivieren Sie dieses Kontrollkästchen, und geben Sie die Eigenschaft Nachrichtenposition in Baumstruktur anfordern an.

      • Geben Sie im Feld Nachrichtenposition in Baumstruktur anfordern die Startadresse an, aus der der Inhalt der Nachrichtenbaumstruktur der Eingabe in die Anforderungsnachricht kopiert wird. Diese Eigenschaft ist nur erforderlich, wenn Sie das Kontrollkästchen Gesamte Eingabenachricht als Anforderung verwenden inaktiviert haben. Der Knoten erstellt eine Anforderungsnachricht und kopiert die angegebenen Teile der Eingabenachricht (die Eingabenachricht selbst bleibt unverändert).

        Sie können alle gültigen ESQL-Feldverweise eingeben. Dazu gehören auch Ausdrücke innerhalb des Verweises. Geben Sie beispielsweise Folgendes ein:

        InputRoot.XMLNSC.ABC

        Wenn Sie Gesamte Eingabenachricht als Anforderung verwenden aktiviert haben, wird diese Eigenschaft ignoriert.

      Bei der Syntaxanalyse des entsprechenden Inhalts der Nachrichtenbaumstruktur zur Erstellung eines Bitstroms werden die Nachrichteneigenschaften (Nachrichtendomäne, Nachrichtengruppe, Nachrichtentyp und Nachrichtenformat) verwendet, die dem Hauptteil der Eingabenachricht zugeordnet und im Ordner 'Eigenschaften' gespeichert sind.

    2. Geben Sie den Inhalt der Ausgabenachricht an, die an den nächsten Knoten im Nachrichtenfluss weitergegeben wird:
      • Behalten Sie die Auswahl Eingabenachricht durch Antwort des Web-Service ersetzen (Standardeinstellung) bei, wenn die gesamte Antwortnachricht des Web-Service als Ausgabenachricht weitergegeben werden soll.

        Soll die Antwortnachricht des Web-Service zusammen mit Teilen des Inhalts der Eingabenachricht in die Ausgabenachricht aufgenommen werden, wählen Sie Eingabenachricht durch Antwort des Web-Service ersetzen ab und definieren Sie die Eigenschaft Position der Antwortnachricht in Baumstruktur. Wenn Sie diese Eigenschaft abwählen, kopiert der Knoten die Eingabenachricht in die Ausgabenachricht und schreibt die Antwortnachricht des Web-Service über den Inhalt der Ausgabenachricht an der angegebenen Adresse (die Eingabenachricht selbst wird nicht geändert).

      • Geben Sie im Feld Position der Antwortnachricht in Baumstruktur die Startadresse (innerhalb der Baumstruktur der Ausgabenachricht) ein, an der die syntaktisch analysierten Elemente aus dem Bitstrom der Antwortnachricht des Web-Service gespeichert werden. Diese Eigenschaft ist nur erforderlich, wenn Sie Eingabenachricht durch Antwort des Web-Service ersetzen inaktiviert haben.

        Sie können jeden gültigen ESQL-Feldverweis eingeben, darunter auch Ausdrücke innerhalb des Verweises sowie neue Feldverweise (zum Erstellen eines Knotens in der Nachrichtenbaumstruktur für die Antwort). Geben Sie beispielsweise Folgendes ein:

        OutputRoot.XMLNSC.ABC.DEF
        Oder:
        Environment.WSReply

        Wenn Sie Eingabenachricht durch Antwort des Web-Service ersetzen aktiviert haben, wird diese Eigenschaft ignoriert.

      Bei der Syntaxanalyse des Antwortbitstroms zur Erstellung von Inhalten der Nachrichtenbaumstruktur werden die Nachrichteneigenschaften (Nachrichtendomäne, Nachrichtengruppe, Nachrichtentyp und Nachrichtenformat) verwendet, die Sie in den Eigenschaften unter 'Syntaxanalyse für Antwortnachricht' des Knoten angegeben haben.

    3. Wenn der Knoten einen HTTPRequestHeader für die Anforderungsnachricht generieren soll, lassen Sie HTTP-Standard-Header auf Basis der Eingabe generieren aktiviert (dies entspricht der Standardeinstellung).

      Wenn der Knoten keinen HTTPRequestHeader für die Anforderungsnachricht generieren soll, inaktivieren Sie HTTP-Standard-Header auf Basis der Eingabe generieren. 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 HTTPRequest-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 HTTPRequest-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 HTTPRequest-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 HTTPRequest-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 HTTPRequest-Knoten die Web-Service-Header (mit Ausnahme von 'Host') aus dem HTTPInputHeader (sofern dieser in der Eingabenachricht enthalten ist). Der HTTPRequest-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 HTTPRequest-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.
    4. Wählen Sie die Eigenschaft Accept compressed responses by default (Standardmäßig komprimierte Antworten akzeptieren) aus und geben Sie damit an, ob die Anforderung komprimierte Antworten akzeptiert. Wenn Sie diese Option auswählen, kann die Anforderung Antworten empfangen, bei denen für 'Content-Encoding' die Option gzip oder deflate (komprimieren) angegeben ist. Beim Empfang einer solchen Antwort wird der Inhalt entschlüsselt und der Content-Encoding-Header entfernt. Wenn der Anforderungsheader noch keinen Accept-Encoding-Header enthält, wird der Accept-Encoding-Header durch Auswahl dieser Option auf "gzip, deflate" (gzip, komprimiert) gesetzt.
  9. Legen Sie auf der Registerkarte Auswertung die Auswertungseigenschaften fest, wenn der Parser den Hauptteil von Antwortnachrichten anhand der Nachrichtengruppe überprüfen soll. (Wenn eine Nachricht an das Fehlerterminal (Failure) des Knotens übergeben wird, wird sie nicht ausgewertet.) Diese Eigenschaften führen nicht dazu, dass die Eingabenachricht ausgewertet wird. Falls diese Auswertung erforderlich ist, wird davon ausgegangen, dass die Auswertung bereits durch den Empfangsknoten oder einen vorhergehenden Auswertungsknoten ausgeführt wurde.

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

Ausgabeterminals mit einem anderen Knoten verbinden

Schließen Sie das Ausgabe- oder Fehlerterminal dieses Knotens an einen anderen Knoten dieses Nachrichtenflusses an, um die Nachricht weiterzuverarbeiten, Fehler zu beheben oder die Nachricht an eine weitere Zieladresse zu senden. Wenn Sie das Fehlerterminal (Error) nicht anschließen, wird die Nachricht verworfen. Wenn Sie das Fehlerterminal (Failure) nicht anschließen, stellt der Broker eine standardmäßige Fehlerverarbeitung bereit (Informationen hierzu finden Sie unter Fehler in Nachrichtenflüssen behandeln).

Terminals und Eigenschaften

In der folgenden Tabelle werden die HTTPRequest-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.
Ausgabeterminal (Out) 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, weitergegeben werden (dies beinhaltet auch Umadressierungscodes (3xx)), wenn die Eigenschaft Der HTTP(s)-Umleitung folgen nicht festgelegt 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 HTTPRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung
Knotenname Nein Nein Knotentyp, z. B. HTTPRequest 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 HTTPRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
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.
URLSpecifier
Zeitlimit für Anforderung (Sekunden) Ja Ja 120 Gibt an, wie viele Sekunden der Knoten auf eine Antwort des Web-Service wartet. Der gültige Bereich liegt zwischen 1 und (231)-1. Werte, die eine unbegrenzte Wartedauer angeben, sind nicht zulässig. Das Zeitlimit kann unter Umständen eine Sekunde länger dauern als der angegebene Wert. timeoutForServer

In der folgenden Tabelle werden die Eigenschaften für die HTTP-Einstellungen des HTTPRequest-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(S)-Umadressierung folgen Nein Nein Nicht ausgewählt Wenn Sie das Kontrollkästchen aktivieren, wird den Umadressierungen gefolgt. Wenn Sie dieses Kontrollkästchen inaktivieren, wird den Umadressierungen nicht gefolgt.  
HTTP-Version Nein Ja 1.0 HTTP-Version für Anforderungen. Gültige Werte sind 1.0 und 1.1. httpVersion
HTTP/1.1 Keepalive-Paket aktivieren Nein Ja Ausgewählt (bei HTTP-Version 1.1) HTTP/1.1 Keepalive verwenden enableKeepAlive
HTTP-Methode Nein Nein POST Die HTTP-Methode. Folgende Werte sind gültig: POST, GET, PUT, DELETE und HEAD. Standardmäßig verwendet der HTTPRequest-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.

requestCompressionType

Die SSL-Eigenschaften des HTTPRequest-Knotens werden in der folgenden Tabelle beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Protokoll Nein Ja SSL SSL-Protokoll bei der Erstellung einer HTTPS-Anforderung. protocol
Erlaubte SSL-Verschlüsselungen Nein Ja   Eine durch Kommas getrennte Liste von Verschlüsselungen, die bei der Erstellung einer SSL-Anforderung verwendet wird. Wenn der Standardwert eine leere Zeichenfolge ist, werden alle verfügbaren Verschlüsselungen verwendet. allowedCiphers
Hostnamenprüfung für SSL-Zertifikat aktivieren Nein Ja Nein 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-Authentifizierungsaliasnamen für die Clientseite einer HTTP-Verbindung fest. Bei der Standardeinstellung wird automatisch der erste geeignete Schlüssel ausgewählt. keyAlias

In der folgenden Tabelle werden die Eigenschaften von 'Syntaxanalyse der Antwortnachricht' des HTTPRequest-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 HTTPRequest-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.

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 Antwortnachrichtdaten 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 Erkennen 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 Erkennen 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 beim Erkennen von Verarbeitungsanweisungen in einer Antwortnachricht Elemente in der Nachrichtenbaumstruktur erstellt. 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.

Die Fehlerbehandlungseigenschaften des HTTPRequest-Knotens werden in der folgenden Tabelle beschrieben.

Eigenschaft O K Standardwert Beschreibung
Eingabe mit Fehler ersetzen Nein Nein Ausgewählt Wenn Sie dieses Kontrollkästchen aktivieren, wird der Inhalt der Eingabenachricht durch den Inhalt der Fehlernachricht ersetzt. Wenn Sie dieses Kontrollkästchen inaktivieren, müssen Sie die Option Speicherposition der Fehlernachricht angeben.
Speicherposition der Fehlernachricht Ja Nein OutputRoot Die Startadresse, unter der die syntaktisch analysierten Elemente aus dem Fehlerbitstrom des Web-Service gespeichert werden. Diese Eigenschaft hat das Format eines ESQL-Feldverweises.

In der folgenden Tabelle werden die erweiterten Eigenschaften des HTTPRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Gesamte Eingabenachricht als Anforderung verwenden Nein Nein Ausgewählt Wenn Sie dieses Kontrollkästchen markieren, muss der gesamte Hauptteil der Eingabenachricht an den Web-Service übergeben werden. Wenn Sie dieses Kontrollkästchen nicht aktivieren, müssen Sie die Option Nachrichtenposition in Baumstruktur anfordern auswählen.  
Nachrichtenposition in Baumstruktur anfordern Ja Nein InputRoot Die Startadresse, an welcher der Bitstrom für die Übergabe an den Web-Service erstellt wird. Diese Eigenschaft hat das Format eines ESQL-Feldverweises.  
Eingabenachricht durch Antwort des Web-Service ersetzen Nein Nein Ausgewählt Wenn Sie dieses Kontrollkästchen markieren, ersetzt die Antwortnachricht des Web-Service die Kopie der Eingabenachricht als Inhalt der erstellten Ausgabenachricht. Wenn Sie dieses Kontrollkästchen nicht aktivieren, müssen Sie die Option Position der Antwortnachricht in Baumstruktur auswählen.  
Position der Antwortnachricht in Baumstruktur anfordern Ja Nein OutputRoot Die Startadresse, unter der die syntaktisch analysierten Elemente aus dem Antwortbitstrom des Web-Service gespeichert werden. Diese Eigenschaft hat das Format eines ESQL-Feldverweises.  
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.  
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 Anforderungsknoten 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 Knoten dekomprimiert.

Umfasst die an den Anforderungsknoten weitergegebene Nachricht einen Accept-Encoding-Header, sollten alle komprimierten Antworten vom Nachrichtenfluss bzw. der Clientanwendung bearbeitet werden. Die Auswahl dieser Option hat somit in diesem Falle keine Auswirkungen.

acceptCompressedResponses

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

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

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Auswerten Nein Ja Ohne Durch diese Eigenschaft wird gesteuert, ob eine Auswertung stattfindet. Gültige Werte sind Keine, Inhalt und Wert, Inhalt und Übernehmen. validateMaster
Fehlerbehebungsmaßnahme Nein Nein Ausnahme Durch diese Eigenschaft wird gesteuert, was beim Fehlschlagen der Auswertung geschieht. Sie können diese Eigenschaft nur angeben, wenn Sie Auswerten auf Inhalt oder Inhalt und Wert gesetzt haben. 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

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
RequestURL Überschreibt die Eigenschaft Web-Service-URL auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.RequestURL = 'http://ibm.com/abc/';
Timeout Überschreibt die Eigenschaft Zeitlimit für Anforderung (Sek) auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.Timeout = 42;
TimeoutMillis Überschreibt die Eigenschaft Zeitlimit für Anforderung (Sek) auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.TimeoutMillis = 5000;
Diese Eigenschaft legt das Zeitlimit in Millisekunden fest. Der Wert von TimeoutMillis überschreibt den Wert für Timeout, falls beide Werte angegeben sind.
ProxyURL Überschreibt die Eigenschaft HTTP(S)-Proxyadresse auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.ProxyURL = 'my.proxy';
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';
KeepAlive Überschreibt die Eigenschaft HTTP/1.1 Keepalive-Paket aktivieren auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.KeepAlive = TRUE;
RequestLine.Method Überschreibt die Eigenschaft HTTP-Methode auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.Method = 'GET';
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';
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';
UseFolderMode Legt einen Wert für UseFolderMode fest. Dies wird zur Bitstromgenerierung verwendet; bei bestimmten Parsern ändert dies den Ausgabebitstrom. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.UseFolderMode = TRUE;
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.
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;

Mit WrittenDestination-Daten arbeiten

Nachdem die Anforderung gestellt wurde, wird der Ordner 'WrittenDestination' in der lokalen Umgebung mit der URI, an welche die Anforderung gesendet wurde, sowie mit Komprimierungsdetails (falls verwendet) aktualisiert. Ein Eintrag 'WrittenDestination' für einen HTTPRequest-Knoten weist folgendes Format auf, wobei der Begriff 'Compression' nur auftaucht, falls tatsächlich eine Komprimierung verwendet 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:19:53


ReferenzthemaReferenzthema | Version 8.0.0.5 | ac04595_