Über den HTTPRequest-Knoten ist eine Interaktion mit einem Web-Service möglich.
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:
Der HTTPRequest-Knoten befindet sich im HTTP-Fach der Palette und wird im WebSphere Message Broker Toolkit durch folgendes Symbol dargestellt:
Die URL weist folgendes Format auf: http://<Adresse>[:<Port>]/<Funktion>. Beispiel: http://localhost:7080/request. 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.
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 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.
Der Knoten interagiert über TCP/IP direkt mit einem externen Service; so dass 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 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.
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.
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 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:
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.
Sie können bei Bedarf auch einen benutzerdefinierten Parser angeben.
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).
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.
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. 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.
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).
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.
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.
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.
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. 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).
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:
|
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. |
Eigenschaft | O | K | Standardwert | Beschreibung |
---|---|---|---|---|
Ereignisse | Nein | Nein | Ohne | Auf dieser Registerkarte werden Ereignisse angezeigt, die Sie für den Knoten
definiert haben. Standardmäßig sind für keinen Knoten in einem Nachrichtenfluss
Überwachungsereignisse definiert. Über Hinzufügen,
Bearbeiten und Löschen können Sie
Überwachungsereignisse für den Knoten erstellen, ändern oder löschen (Details siehe
Überwachungsereignisquellen mithilfe von Überwachungseigenschaften konfigurieren). Sie können hier angezeigte Ereignisse aktivieren oder inaktivieren, indem Sie das Kontrollkästchen Aktiviert aktivieren oder inaktivieren. |
Einstellung | Beschreibung |
---|---|
RequestURL | Überschreibt die Eigenschaft Web-Service-URL auf dem Knoten. Beispiel:
|
Timeout | Überschreibt die Eigenschaft Zeitlimit für Anforderung (Sek) auf dem Knoten. Beispiel:
|
TimeoutMillis | Überschreibt die Eigenschaft Zeitlimit für Anforderung (Sek) auf dem Knoten. Beispiel:
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:
|
RequestLine.RequestURI | Überschreibt RequestURI, den Pfad hinter URL und Port. Beispiel:
|
RequestLine.HTTPVersion | Überschreibt die Eigenschaft HTTP-Version auf dem Knoten. Beispiel:
|
KeepAlive | Überschreibt die Eigenschaft HTTP/1.1
Keepalive-Paket aktivieren auf dem Knoten. Beispiel:
|
RequestLine.Method | Überschreibt die Eigenschaft HTTP-Methode auf dem Knoten. Beispiel:
|
SSLProtocol | Überschreibt das SSL-Protokoll.
Beispiel:
Folgende Werte sind gültig: SSL, SSLv3 und TLS. |
SSLCiphers | Überschreibt die Eigenschaft Erlaubte SSL-Verschlüsselungen auf dem Knoten. Beispiel:
|
ProxyConnectHeaders | Gibt zusätzliche Header
an, die verwendet werden, wenn es sich bei der abgehenden Anforderung um eine SSL-Verbindung über
einen Proxy handelt. Diese zusätzlichen Header werden mit der einleitenden CONNECT-Anforderung an
den Proxy gesendet. Sie können beispielsweise Proxy-Authentifizierungsdaten an einen Proxy-Server
senden, wenn Sie SSL verwenden. Es können mehrere Header gesendet werden, die jedoch alle durch
einen Rücklauf und einen Zeilenvorschub (ASCII 0x0D 0x0A) in Übereinstimmung mit RFC2616 getrennt
sein müssen; Beispiel:
Diese Einstellung wird nur verwendet, wenn es
sich bei der Anforderung um eine SSL-Anforderung über einen Proxy-Server handelt. Um
Proxy-Authentifizierungsdaten für eine Nicht-SSL-Anforderung zu senden, müssen Sie die einzelnen
Header im Ordner 'HTTPRequestHeader' angeben, so wie im folgenden Beispiel gezeigt:
|
UseFolderMode | Legt einen Wert für UseFolderMode fest. Dies wird zur Bitstromgenerierung verwendet; bei bestimmten Parsern ändert dies den Ausgabebitstrom. Beispiel:
|
QueryString | Ermöglicht die Einstellung der Parameter für abgehende Abfragezeichenfolgen. Jeder Parameter muss separat definiert werden. Beispiel:
Dieser ESQL-Code verschlüsselt die folgende Abfragezeichenfolge (gemäßhttp://tools.ietf.org/html/rfc3986) für die abgehende Anforderung:
Wenn die Ziel-URL bereits Abfrageparameter enthält, werden die hier angegebenen Parameter an die
vorhandene Liste angefügt. |
QueryStringCCSID | Gibt an, dass die Abfragezeichenfolgeparameter vor der Codierung in einen
anderen Zeichensatz als den Standardzeichensatz UTF-8 konvertiert werden müssen. Alle
Abfragezeichenfolgeparameter werden zuerst in die angegebene ID des codierten Zeichensatzes
konvertiert, bevor die Ergebniszeichenfolge gemäß
RFC3986 codiert wird.
Beispiel:
Der
oben gezeigte ESQL-Code bewirkt, dass alle QueryString-Parameter vor ihrer Codierung in die
Codepage 943 konvertiert werden. Hinweis: Alle Abfragezeichenfolgeparameter müssen die Daten in
Unicode enthalten. |
Compression | Überschreibt die Eigenschaft Use compression (Komprimierung verwenden) des Knotens. Beispiel:
Zur Festlegung einer Mindestgröße (in Byte), ab der komprimiert wird, verwenden Sie folgende Überschreibung:
|
WrittenDestination = (
HTTP = (
RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
Compression = (
OriginalSize = 53 (INTEGER)
CompressedSize = 71 (INTEGER)
)
)
)