HTTPRequest-Knoten

Mit dem HTTPRequest-Knoten können Sie mit einem Web-Service interagieren.

Dieses Kapitel enthält folgende Abschnitte:

Zweck

Der HTTPRequest-Knoten interagiert mit einem Web-Service, wobei er als Anforderung, die an diesen Service gesendet wird, die gesamte oder einen Teil der Eingabenachricht verwendet. Sie können den Knoten auch so konfigurieren, dass er eine neue Ausgabenachricht auf Basis des Inhalts der Eingabenachricht sowie des Inhalts der Antwort des Web-Service erstellt, bevor die Nachricht an nachfolgende Knoten im Nachrichtenfluss weitergegeben wird.

Je nach Konfiguration erstellt dieser Knoten eine HTTP- bzw. eine HTTP over SSL-Anforderung (HTTPS) vom angegebenen Inhalt und sendet sie an den Web-Service. Der Knoten empfängt die Antwort vom Web-Service und analysiert die Antwort zur Aufnahme in die Baumstruktur der Ausgabe. Er generiert HTTP-Header, falls diese in Ihrer Konfiguration erforderlich sind.

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:

  • MRM
  • XML
  • XMLNS
  • XMLNSC
  • JMSMap
  • JMSStream
  • MIME
  • BLOB
  • IDOC

Der HTTPRequest-Knoten befindet sich im HTTP-Fach der Palette und wird in Workbench 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. Ein Datenstrom, der vom fernen Server verarbeitet wird. Dieser sendet dann eine Antwort zurück, die oft aus einem SOAP (Simple Object Access Protocol) oder einem anderen Web-Service in XML besteht.

Die URL hat das Format 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. Je nach Angabe in den Eigenschaften des HTTPRequest-Knotens können die an den Web-Service gesendeten Daten aus der kompletten Nachrichtenbaumstruktur oder auch nur aus einem Teil davon bestehen.

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.

Wird die Anforderung vom HTTPRequest-Knoten erfolgreich versendet, doch der Web-Service ist nicht erfolgreich, wird HTTPReply 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. Mithilfe eines Compute-Knotens müssen Sie diese Antwort möglicherweise in eine geeignete Codepage umwandeln, damit 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 nicht in einem Nachrichtenfluss verwendet werden, der eine HTTP-Anforderung senden muss. Das häufigste Beispiel hierfür ist ein Nachrichtenfluss, der einen Web-Service aufruft.

Weitere Informationen zu Web-Service-Anwendungen finden Sie unter Mit Web-Service-Anwendungen arbeiten.

Fehler behandeln

Der Knoten interagiert über TCP/IP direkt mit einem externen Service; sodass 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 'fortgesetzte' Antwort, löscht die aktuelle Antwort und wartet auf eine andere Antwort vom Web-Server.

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 Ausgangsterminal des Knotens weitergeleitet.

Die Statuscodes der Serie 300 werden zur Umadressierung verwendet. Wenn die Eigenschaft Der HTTP(S)-Umleitung folgen ausgewählt ist, sendet der Knoten die Anforderung nicht erneut an die neue Zieladresse, die in der erhaltenen 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 Header der Eingabenachricht weitergegeben.

Der erste Header in der Nachricht, der nach den Eigenschaften vom Knoten weitergegeben wird, ist der HTTPResponse-Header mit den Headern, die vom fernen Web-Service zurückgegeben werden. Dieser Vorgang wird unabhängig von den ausgewählten Optionen ausgeführt. 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 Knoteneigenschaften werden in der Eigenschaftenansicht angezeigt. Klicken Sie zum Anzeigen der Knoteneigenschaften im Dialogfeld 'Eigenschaften' doppelt auf den Knoten, oder klicken Sie mit der rechten Maustaste und dann im Kontextmenü auf Eigenschaften.

Alle obligatorischen Eigenschaften, für die Sie einen Wert eingeben müssen (d. h. Eigenschaften ohne definierten Standardwert), 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 bestimmt die URL für den Web-Service, an den er eine Anforderung sendet. Legen Sie eine der folgenden drei Optionen fest; der Knoten überprüft diese in der unten angegebenen Reihenfolge (d. h. die erste Option überschreibt die zweite, 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. Legen Sie den Wert der Eigenschaft Zeitlimit für Anforderung fest. Er gibt die Zeit in Sekunden an, die der Knoten auf eine Antwort vom 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. Aktivieren Sie HTTP(S)-Umadressierung folgen, um anzugeben, wie der Knoten Web-Service-Antworten handhabt, die einen HTTP-Statuscode zwischen 300 und 399 enthalten:
      • Wenn Sie das Kontrollkästchen aktivieren, folgt der Knoten der Umadressierung, die in der Antwort angegeben ist, und gibt die Web-Service-Anforderung erneut an die neue URL aus, die im Nachrichteninhalt steht.
      • 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. Beginn der ÄnderungWählen Sie für die Eigenschaft HTTP-Methode eine der Optionen aus. Folgende Werte sind gültig: POST, GET, PUT, DELETE und HEAD.Ende der Änderung
  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, damit das ausgewählte Protokoll vom fernen Server akzeptiert werden kann. Folgende Optionen stehen zur Verfügung:
      • SSL. Diese Option ist die Standardeinstellung. Bei dieser Option wird zuerst versucht, die Verbindung über das SSLv3-Protokoll herzustellen. Sie erlaubt dem Handshake jedoch, auf das SSLv2-Protokoll zurückzugreifen, das von dem zugrunde liegenden JSSE-Provider unterstützt wird.
      • SSLv3. Bei dieser Option wird nur versucht, die Verbindung über das SSLv3-Protokoll herzustellen. Das Zurückgreifen auf SSLv2 ist nicht zulässig.
      • TLS. Bei dieser Option wird nur versucht, die Verbindung über das TLS-Protokoll herzustellen. Das Zurückgreifen auf SSLv3 oder SSLv2 ist nicht zulässig.
    2. Legen Sie die Eigenschaft Erlaubte SSL-Verschlüsselungen fest. Mit dieser Einstellung 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.
  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, auf deren Basis der Knoten die Vorgehensweise bei der Syntaxanalyse der vom Web-Service zurückgegebenen Antwortnachricht bestimmt. Wenn der Web-Service eine Fehlernachricht ausgibt, 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. Folgende Optionen stehen zur Auswahl:
      • MRM
      • XML
      • XMLNS
      • XMLNSC
      • JMSMap
      • JMSStream
      • MIME
      • BLOB
      • IDOC
    2. Wenn Sie den MRM- oder IDOC-Parser verwenden, wählen Sie die relevante Nachrichtengruppe aus. Diese Liste wird mit den verfügbaren Nachrichtengruppen gefüllt, wenn Sie MRM oder IDOC als Nachrichtendomäne auswählen.

      Lassen Sie die Nachrichtengruppe bei den XML-, XMLNS-, XMLNSC-, JMS-, MIME- und BLOB-Parsern leer.

    3. Wenn Sie den MRM-Parser verwenden, wählen Sie aus der Liste unter Nachrichtentyp die korrekte Nachricht aus. Diese Liste wird mit Nachrichten aufgefüllt, die in der von Ihnen ausgewählten Nachrichtengruppe definiert sind.

      Lassen Sie das Feld Nachrichtentyp bei XML-, XMLNS-, XMLNSC-, JMS-, MIME-, BLOB- und IDOC-Parsern leer.

    4. Wenn Sie den Parser MRM oder IDOC verwenden, wählen Sie aus der Liste unter Nachrichtenformat das gewünschte Format aus. Diese Liste enthält alle physischen Formate, die Sie für diese Nachrichtengruppe definiert haben.

      Lassen Sie das Nachrichtenformat bei den XML-, XMLNS-, XMLNSC-, JMS-, MIME- und BLOB-Parsern leer.

  6. Auf der Registerkarte Parser-Optionen ist Zeitpunkt für Syntaxanalyse standardmäßig auf Bei Bedarf gesetzt. In diesem Fall wird die Auswertung verzögert, bis im Rahmen einer Teil-Syntaxanalyse eine Syntaxanalyse erfolgt. Wenn Sie den Wert für diese Option in Sofort ändern, wird die Teil-Syntaxanalyse außer Kraft gesetzt. In diesem Fall werden mit Ausnahme der komplexen Typen mit der Zusammensetzung 'Auswahl' oder 'Nachricht' alle Nachrichtenkomponenten syntaktisch analysiert und ausgewertet, die zu diesem Zeitpunkt nicht aufgelöst werden können. Wenn Sie diesen Wert in Vollständig ändern, wird die Teil-Syntaxanalyse außer Kraft gesetzt. In diesem Fall werden alle Nachrichtenkomponenten syntaktisch analysiert und ausgewertet; komplexe Typen mit der Zusammensetzung 'Auswahl' oder 'Nachricht', die zu diesem Zeitpunkt nicht aufgelöst werden können, verursachen einen Fehler bei der Gültigkeitsprüfung.
  7. Legen Sie auf der Registerkarte Fehlerbehandlung Werte für die Eigenschaften fest, die bestimmen, wie eine vom Web-Service zurückgegebene Fehlernachricht gehandhabt wird:
    1. Wenn die gesamte Fehlernachricht des Web-Service als Ausgabenachricht weitergegeben werden soll, lassen Sie das Kontrollkästchen Eingabe mit Fehler ersetzen aktiviert (dies entspricht der Standardeinstellung).

      Wenn die Fehlernachricht des Web-Service mit einem Teil des Eingabenachrichteninhalts in die Ausgabenachricht aufgenommen werden soll, inaktivieren Sie dieses Kontrollkästchen, und geben Sie die Eigenschaft Speicherposition der Fehlernachricht an. Wenn Sie diese Eigenschaft nicht angeben, kopiert der Knoten die Eingabenachricht in die Ausgabenachricht und schreibt die Fehlernachricht des Web-Service an der angegebenen Adresse über den Inhalt der Ausgabenachricht (die Eingabenachricht selbst wird nicht geändert).

    2. Geben Sie im Feld Speicherposition der Fehlernachricht die Startadresse (innerhalb der Nachrichtenbaumstruktur der Ausgabe) 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 alle gültigen ESQL-Feldverweise eingeben. Dazu gehören auch Ausdrücke innerhalb des Verweises sowie neue Feldverweise (zur Erstellung eines neuen 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. Legen Sie auf der Registerkarte Erweitert Werte für die erweiterten Eigenschaften fest, die die Struktur und den Inhalt der Anforderung und Antwort des Web-Service beschreiben:
    1. Geben Sie den Inhalt der Anforderungsnachricht an, die an den Web-Service gesendet wird:
      • 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 neue Anforderungsnachricht und kopiert die angegebenen Bereiche 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. Sie können beispielsweise Folgendes eingeben:

        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:
      • Wenn die gesamte Antwortnachricht des Web-Service als Ausgabenachricht weitergegeben werden soll, lassen Sie das Kontrollkästchen Eingabenachricht durch Antwort des Web-Service ersetzen aktiviert (dies entspricht der Standardeinstellung).

        Wenn die Antwortnachricht des Web-Service mit einem Teil des Eingabenachrichteninhalts in die Ausgabenachricht aufgenommen werden soll, inaktivieren Sie dieses Kontrollkästchen, und geben Sie die Eigenschaft Speicherposition der Antwortnachricht in Baumstruktur an. Wenn Sie diese Eigenschaft nicht angeben, kopiert der Knoten die Eingabenachricht in die Ausgabenachricht und schreibt die Antwortnachricht des Web-Service an der angegebenen Adresse über den Inhalt der Ausgabenachricht (die Eingabenachricht selbst wird nicht geändert).

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

        Sie können alle gültigen ESQL-Feldverweise eingeben. Dazu gehören auch Ausdrücke innerhalb des Verweises sowie neue Feldverweise (zur Erstellung eines neuen 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 HTTP-Standard-Header auf Basis der Eingabe generieren ausgewählt haben und die Eingabenachricht einen HTTPRequest-Header enthält, extrahiert der HTTPRequest-Knoten Web-Service-Header vom Eingabe-HTTPRequest-Header und fügt eindeutige Web-Service-Header hinzu, außer Hosts (s. Tabelle unten), die im HTTPInput-Header vorhanden sind, wenn einer in der Eingabenachricht vorliegt. (Ein HTTPInput-Header kann vorhanden sein, wenn die von einem Web-Service stammende Eingabenachricht vom HTTPInput-Knoten empfangen wurde.)

        Der HTTPRequest-Knoten fügt ebenfalls die Web-Service-Header hinzu, die in der folgenden Tabelle zu sehen sind; es werden dabei die Standardwerte verwendet, wenn diese nicht im HTTPRequest- oder HTTPInput-Header vorhanden sind.

        Header Standardwert
        SOAPAction "" (leere Zeichenfolge)
        Content-Type text/xml; charset=utf-8
        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 enthält, extrahiert der HTTPRequest-Knoten mit Ausnahme von 'Host' Web-Service-Header aus dem HTTPInputHeader (falls dieser in der Eingabenachricht existiert). Der HTTPRequest fügt die erforderlichen Web-Service-Header mit Standardwerten hinzu, wenn diese Werte nicht im HTTPInput-Header vorhanden sind.
      • Wenn Sie die Option HTTP-Standard-Header auf Basis der Eingabe generieren nicht ausgewählt haben und die Eingabenachricht einen HTTPRequestHeader enthält, extrahiert der Knoten alle Webdienst-Header, die im Eingabe-HTTPRequestHeader vorhanden sind. Der Knoten prüft weder, ob ein HTTPInputHeader in der Eingabenachricht vorhanden ist, noch fügt er die erforderlichen Web-Service-Header hinzu, wenn diese nicht vom Eingabe-HTTPRequestHeader übergeben werden.
      • Wenn Sie die Option HTTP-Standard-Header auf Basis der Eingabe generieren nicht ausgewählt haben und die Eingabenachricht keinen HTTPRequestHeader enthält, werden keine Webdienst-Header generiert. Der HTTPRequest-Knoten überprüft nicht das Vorhandensein eines HTTPInput-Headers in der Eingabenachricht und fügt keine erforderlichen Web-Service-Header hinzu. Die Anforderungsnachricht wird ohne HTTPRequestHeader an den Web-Service weitergegeben. Dies führt für gewöhnlich dazu, dass ein Fehler vom Web-Service generiert wird - es sei denn, der Web-Service wurde für die Handhabung von Nachrichteninhalten konfiguriert.
  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 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. Falls das Fehlerterminal nicht angeschlossen ist, wird die Nachricht verworfen. Wenn Sie das Fehlerterminal 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
Eingangsterminal Das Eingangsterminal, das eine Nachricht zur Verarbeitung durch einen Knoten annimmt
Fehlerterminal Das Ausgabeterminal, an das die Eingabenachricht geleitet wird, wenn während der Verarbeitung im Knoten ein Fehler auftritt.
Ausgabeterminal Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn sie auf eine erfolgreiche Ausführung der Web-Service-Anforderung hinweist in diesem Nachrichtenfluss eine weitere Verarbeitung erforderlich ist.
Error-Terminal 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
Ausführliche Beschreibung 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
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.
Zeitlimit für Anforderung (Sekunden) Ja Nein 120 Die Zeit in Sekunden, die der Knoten auf eine Antwort vom Web-Service wartet. Der gültige Bereich liegt zwischen 1 und (231)-1. Werte, die eine unbegrenzte Wartedauer angeben, sind nicht zulässig.

In der folgenden Tabelle werden die Eigenschaften für die HTTP-Einstellungen des HTTPRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung
HTTP(S)-Proxyadresse Nein Ja   Die Adresse des Proxy-Servers fest, an den Anforderungen gesendet werden. Dieser Wert muss das Format Hostname:Port haben.
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.
HTTP/1.1 Keepalive-Paket aktivieren Nein Ja Ausgewählt (bei HTTP-Version 1.1) HTTP/1.1 Keepalive verwenden
HTTP-Methode Beginn der ÄnderungNeinEnde der Änderung Beginn der ÄnderungNeinEnde der Änderung Beginn der ÄnderungPOSTEnde der Änderung Beginn der ÄnderungDie HTTP-Methode. Folgende Werte sind gültig: POST, GET, PUT, DELETE und HEAD. Beim Herstellen der Verbindung zum fernen Web-Server verwendet der HTTPRequest-Knoten standardmäßig die Methode HTTP POST. Mithilfe von HEAD wird häufig ermittelt, ob ein Service verfügbar ist, beispielsweise von einem Netzdispatcher, der herausfinden möchte, welche Server und verfügbar sind. Die richtigen Header (einschließlich content-length) werden zurückgesendet, enthalten jedoch keine Hauptteildaten. Ende der Änderung

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

Eigenschaft O K Standardwert Beschreibung
Protokoll Nein Ja SSL SSL-Protokoll bei der Erstellung einer HTTPS-Anforderung.
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.

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

Eigenschaft O K Standardwert Beschreibung
Nachrichtendomäne Nein Nein   Die Domäne, die für die Syntaxanalyse der aus dem Web-Service empfangenen Antwortnachricht verwendet wird.
Nachrichtengruppe Nein Nein   Der Name oder die ID der Nachrichtengruppe, in der die Antwortnachricht definiert ist.
Nachrichtentyp Nein Nein   Der Name der Antwortnachricht.
Nachrichtenformat Nein Nein   Der Name des physischen Formats der Antwortnachricht.

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.

XMLNSC-Kompaktparser für XMLNS-Domäne verwenden Nein Nein Nicht ausgewählt Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Kompaktparser für Nachrichten in der XMLNS-Domäne verwendet wird. Wenn Sie diese Eigenschaft festlegen, werden die Antwortnachrichtendaten unter XMLNSC in Knoten, die mit dem Ausgabeterminal verbunden sind, angezeigt, wenn XMLNS die Domäne des MQRFH2-Eingabeheaders oder der Eigenschaften von 'Syntaxanalyse der Antwortnachricht' ist.
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.

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, an 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
Gesamte Eingabenachricht als Anforderung verwenden Nein Nein Ausgewählt Wenn Sie dieses Kontrollkästchen aktivieren, wird der gesamte Hauptteil der Eingabenachricht an den Web-Service übergeben. 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 der 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 aktivieren, 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, an 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.

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
Auswerten Nein Ja Keiner Durch diese Eigenschaft wird gesteuert, ob eine Auswertung stattfindet. Gültige Werte sind Keine, Inhalt und Wert, Inhalt und Übernehmen.
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.
Alle Wertvorgaben einschließen Nein Nein Ausgewählt Diese Eigenschaft kann nicht bearbeitet werden. Die Standardaktion (aktiviertes Kontrollkästchen) besteht darin, dass in der Auswertung von Inhalt und Wert auch Basisprüfungen der Wertvorgaben ausgeführt werden.
Korrektur Nein Nein Keiner Diese Eigenschaft kann nicht bearbeitet werden.
Beginn der Änderung

Überschreibungen in 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;
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?x=y&g=h';
RequestLine.HTTPVersion Überschreibt die Eigenschaft HTTP-Version auf dem Knoten. Beispiel:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.HTTPVersion = 'HTTP/1.1';
KeepAlive Überschreibt die Eigenschaft Enable 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 Beginn der ÄnderungGibt 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';
Ende der Änderung
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;

Mit WrittenDestination-Daten arbeiten

Sobald die Anforderung gestellt wurde, wird der WrittenDestination-Ordner in der lokalen Umgebung (LocalEnvironment) mit der URI aktualisiert, an die die Anforderung gesendet wurde. Ein WrittenDestination-Eintrag für einen HTTPRequest-Knoten hat das folgende Format:
WrittenDestination = (
   HTTP  = (
      RequestURL = 'http://server:port/folder/page'
   )
)
Ende der Änderung
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:09

ac04595_