Mit dem HTTPRequest-Knoten können Sie mit einem Web-Service interagieren.
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:
Der HTTPRequest-Knoten befindet sich im HTTP-Fach der Palette und wird in Workbench durch folgendes Symbol dargestellt:
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.
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.
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.
Der Knoten interagiert über TCP/IP direkt mit einem externen Service; sodass es zu folgenden Fehlerarten kommen kann:
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.
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.
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.
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.
SET OutputRoot = InputRoot; SET OutputRoot.HTTPResponseHeader = NULL;
SET OutputRoot = InputRoot; DECLARE HTTPHeaderRef REFERENCE TO OutputRoot.HTTPResponseHeader; DETACH HTTPHeaderRef; ATTACH HTTPHeaderRef TO OutputRoot.MQMD AS NEXTSIBLING;
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:
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.
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.
Lassen Sie die Nachrichtengruppe bei den XML-, XMLNS-, XMLNSC-, JMS-, MIME- und BLOB-Parsern leer.
Lassen Sie das Feld Nachrichtentyp bei XML-, XMLNS-, XMLNSC-, JMS-, MIME-, BLOB- und IDOC-Parsern leer.
Lassen Sie das Nachrichtenformat bei den XML-, XMLNS-, XMLNSC-, JMS-, MIME- und BLOB-Parsern leer.
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).
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.DEFoder
Environment.WSError
Wenn Sie Eingabe mit Fehler ersetzen auswählen, wird diese Eigenschaft ignoriert.
Wenn die Anforderungsnachricht eine Untergruppe der Eingabenachricht enthalten soll, inaktivieren Sie dieses Kontrollkästchen, und geben Sie die Eigenschaft Nachrichtenposition in Baumstruktur anfordern an.
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.
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).
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.DEFoder
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.
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.
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.
Sie finden detaillierte Informationen hierzu unter Nachrichten überprüfen und Auswertungseigenschaften.
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).
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:
|
|
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 | ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
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. |
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 | ![]() 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; |
WrittenDestination = ( HTTP = ( RequestURL = 'http://server:port/folder/page' ) )