Lesen Sie die folgenden Informationen, wenn Sie
HTTP-Nachrichtenflüsse für die Interaktion mit HTTP-Anwendungen einschließlich Web-Services und RESTful-Services verwenden.
Zum besseren Verständnis
wird empfohlen, diese Informationen in Verbindung mit dem Abschnitt Web-Service-Szenarios zu lesen.
Sie müssen entscheiden, welches Empfangsprogramm von den HTTP-Knoten verwendet werden soll:
- Das Broker-Empfangsprogramm (httplistener-Komponente) verfügt über einen HTTPConnector zur Verarbeitung von HTTP-Nachrichten sowie über einen HTTPSConnector zur Verarbeitung von HTTPS-Nachrichten (HTTP over SSL). Jeder Connector verfügt über seinen eigenen zugeordneten Port.
Standardmäßig verwenden alle HTTPInput- und HTTPReply-Knoten das brokerweite Empfangsprogramm, das über eine WebSphere MQ-Warteschlange eine Schnittstelle zu den HTTP-Knoten bildet.
- Ein eingebettetes Empfangsprogramm ist Teil jeder einzelnen Ausführungsgruppe. Das eingebettete Empfangsprogramm verfügt über einen HTTPConnector und einen HTTPSConnector; jeder Connector weist wiederum einen eigenen zugeordneten Port auf.
Sie können eine oder mehrere Ausführungsgruppen konfigurieren, sodass alle HTTPInput- und HTTPReply-Knoten, die Sie in dieser Ausführungsgruppe implementieren, das eingebettete Empfangsprogramm verwenden.
Im Abschnitt
HTTP-Empfangsprogramme werden die Vorteile der einzelnen Empfangsprogramme erläutert.
ProxyConnectHeaders sind nur für HTTPS (SSL)-Verbindungen vorgesehen; diese Header funktionieren bei HTTP-Verbindungen nicht.
- Sichere Verbindungen mit HTTPS verwenden
- Informationen zur Einrichtung von HTTPS-Verbindungen finden Sie unter
SSL-Authentifizierung implementieren.
- Asynchrone HTTP-Anforderung/Antwort verwenden
- Wenn Sie eine HTTP-Anforderung stellen und die Antwort asynchron empfangen möchten, verwenden
Sie in Ihrem Nachrichtenfluss die Knoten
HTTPAsyncRequest und
HTTPAsyncResponse. Der
HTTPAsyncRequest-Knoten verarbeitet die nächste
Nachricht, ohne auf die Antwort zu warten, die vom
HTTPAsyncResponse-Knoten in einem anderen Thread und in
einer neuen Transaktion empfangen wird. Dies bedeutet, dass viel mehr Anforderungen mit weniger
Threads verarbeitet werden können.
Der Abschnitt Asynchrone HTTP-Anforderung/Antwort verwenden enthält weitere Informationen hierzu.
- Festlegen des HTTP-Statuscodes für eine Antwort
- Der Standardwert für den HTTP-Statuscode lautet 200, was
Erfolg bedeutet.
Wenn ein anderer Statuscode zurückgegeben werden soll, führen Sie eine der
folgenden Aktionen aus:
- Legen Sie den gewünschten Statuscode im Feld 'Destination.HTTP.ReplyStatusCode' in der Baumstruktur für die lokale Umgebung (Korrelationsname 'OutputLocalEnvironment') fest.
Dieses Feld
überschreibt einen im Header 'HTTPResponseHeader' festgelegten Statuscode. Dies ist die bevorzugte
Aktion, weil sie die größte Flexibilität bietet.
- Legen Sie den gewünschten Statuscode im Feld 'X-Original-HTTP-Status-Code' im Header 'HTTPReplyHeader'
fest.
- Legen Sie den gewünschten Statuscode im Feld 'X-Original-HTTP-Status-Code' im Header 'HTTPResponseHeader' fest. Diese Option ist nützlich, wenn Sie einen HTTPRequest-Knoten vor dem HTTPReply-Knoten im Nachrichtenfluss einfügen, denn dann wird der Header 'HTTPResponseHeader' automatisch erstellt. In diesem Szenario wurde der Header 'HTTPResponseHeader' in der
logischen Baumstruktur, welche die HTTP-Header in der Antwort von einem anderen Web-Service
wiedergibt, erstellt. Wenn Sie die Eigenschaft
HTTP-Standard-Header auf Basis der Antwort generieren im HTTPReply-Knoten ausgewählt haben, werden Werte für den Antwortheader als Standardwerte
festgelegt, wenn die Antwortnachricht erstellt wird.
- 'LocalEnvironment.Destination.HTTP.RequestIdentifier' verwenden
- Wenn der HTTPInput-Knoten eine Eingabeanforderungsnachricht empfängt, setzt er das
Feld 'Destination.HTTP.RequestIdentifier' der lokalen Umgebung auf einen eindeutigen Wert, der den
Web-Service-Client, von dem die Anforderung gesendet wurde, identifiziert. Sie können auf diesen
Wert verweisen und ihn bei Bedarf in einem anderen Verzeichnis speichern.
Wenn Sie
beispielsweise ein Nachrichtenflusspaar entwerfen, das mit einer bestehenden
WebSphere MQ-Anwendung interagiert (wie in
Broker ruft bestehenden Web-Service auf beschrieben), können Sie den Bezeichnerwert im
Anforderungsnachrichtenfluss speichern und ihn im Antwortnachrichtenfluss wiederherstellen, um
sicherzustellen, dass die Antwort an den richtigen Client gesendet wird. In diesem Fall dürfen Sie
die Daten nicht ändern und müssen die Daten als BLOB erhalten.
Der HTTPReply-Knoten
extrahiert den Bezeichnerwert aus der Baumstruktur für die lokale Umgebung und erstellt die Antwort, damit sie an den festgelegten Client gesendet wird. Wenn Sie jedoch einen HTTPReply-Knoten in einem
Nachrichtenfluss einsetzen, der keinen HTTPInput-Knoten enthält, und dieses Feld gelöscht oder falsch festgelegt wurde, wird die Nachricht BIP3143S ausgegeben.
Wenn Sie einen
Nachrichtenfluss entwerfen, der sowohl einen HTTPInput- als auch einen HTTPReply-Knoten enthält, wird
der Bezeichnerwert in der lokalen Umgebung vom HTTPInput-Knoten festgelegt, vom HTTPReply-Knoten jedoch nicht verwendet. Falls Ihr Nachrichtenfluss beide HTTP-Knoten und einen Compute-Knoten im selben Datenfluss enthält, müssen Sie daher die Baumstruktur für die lokale Umgebung nicht einfügen, wenn Sie angeben, welche Komponenten der Nachrichtenbaumstruktur vom Compute-Knoten aus der Eingabe- in die
Ausgabenachricht kopiert werden (Eigenschaft Rechenmodus).
- URL für HTTP-Anforderung dynamisch einstellen
- Sie können die Eigenschaft Default Web service URL
(URL für Standard-Web-Service) im
HTTPRequest- oder
HTTPAsyncRequest-Knoten angeben, um die Ziel-URL
für eine Web-Service-Anforderung festzulegen. Sie können einen
Compute-Knoten vor dem
HTTPRequest- oder
HTTPAsyncRequest-Knoten im Nachrichtenfluss
konfigurieren, um den in der Eigenschaft angegebenen Wert zu überschreiben.
Schreiben Sie einen
ESQL-Code, der eine URL-Zeichenfolge in 'LocalEnvironment.Destination.HTTP.RequestURL' speichert.
Der Knoten ruft die URL-Zeichenfolge ab und verwendet sie statt des Werts der
Knoteneigenschaft.
Sie können den
Anforderungs-URL zwar auch im Spezialheader 'X-Original-HTTP-URL' im Abschnitt 'HTTPRequestHeader'
der Anforderungsnachricht in einem Compute-Knoten festlegen (wodurch alle anderen Einstellungen
überschrieben werden). Den Inhalt der lokalen Umgebung zu diesem Zweck zu verwenden, bietet jedoch eine größere Flexibilität.
- Eigenschaft HTTP-Standard-Header auf Basis der
Antwort generieren für den HTTPReply-Knoten festlegen
- Wenn Sie HTTP-Standard-Header auf
Basis der Antwort generieren in den Eigenschaften des HTTPReply-Knotens auswählen,
fügt der Knoten eine Mindestanzahl von Headern in die Antwort ein, die an den Web-Service-Client
gesendet wird.
Wenn Sie Header explizit festlegen möchten, müssen Sie sie in einem HTTPReplyHeader erstellen.
Beispiel: Ein
Compute-Knoten gibt eine Nachricht in der XMLNSC-Domäne weiter und ändert den Inhaltstyp (Content-Type) wie folgt:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
Legen Sie den Inhaltstyp nicht über die
Eigenschaft 'ContentType' fest, es sei denn, Sie arbeiten in der MIME-Domäne. Die Eigenschaft
'ContentType' dient speziell zum Einrichten des Inhaltstypwerts (Content-Type) in MIME.
Die ganze Reihe der in dieser Antwort verwendeten HTTP-Header wird erstellt, indem die Header mit dem in den folgenden Schritten definierten Algorithmus ausgewählt werden:
- Wählen Sie einen oder mehrere Header in einem HTTPReplyHeader aus.
- Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie ihn, indem Sie einen beliebigen Wert in der Eigenschaft 'ContentType' auswählen.
- Wählen Sie einen oder mehrere Header in einem HTTPResponseHeader aus (ein HTTPResponseHeader wird bei der Rücklieferung von einem HTTPRequest-Knoten weitergegeben).
- Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie einen mit dem
Standardwert text/xml; charset=CCSID des Nachrichtenhauptteils.
- Erstellen oder überschreiben Sie den Content-Length-Header.
Achtung: Der HTTPReply-Knoten schreibt den Header 'Content-Length' (Inhaltslänge) immer neu, auch wenn HTTP-Standard-Header auf Basis von Eingabe
oder Antwort generieren nicht ausgewählt ist. Dadurch wird die Richtigkeit des Inhalts sichergestellt.
Wenn in der vom HTTPReply-Knoten empfangenen Nachricht ein Abschnitt 'HTTPReplyHeader'
enthalten war und eine Verbindung mit dem Ausgabeterminal des HTTPReply-Knotens besteht, wird der
Abschnitt 'HTTPReplyHeader' mit allen geänderten oder hinzugefügten Werten aktualisiert.
- Eigenschaft HTTP-Standard-Header auf Basis der Eingabe
generieren für den
HTTPRequest- oder
HTTPAsyncRequest-Knoten festlegen
- Wenn Sie HTTP-Standard-Header auf Basis der Eingabe
generieren in den Eigenschaften des
HTTPRequest- oder
HTTPAsyncRequest-Knotens auswählen, fügt der Knoten
eine Mindestanzahl von Headern in die Anforderung ein, die an den Server gesendet wird.
Um Header explizit festzulegen, müssen Sie sie in einem HTTPRequestHeader
erstellen. Beispiel: Ein
Compute-Knoten, der eine Nachricht in der XMLNSC-Domäne weitergibt, kann den Inhaltstyp (Content-Type) wie folgt ändern:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
Legen Sie den Inhaltstyp nicht über die
Eigenschaft 'ContentType' fest, es sei denn, Sie arbeiten in der MIME-Domäne. Die Eigenschaft
'ContentType' dient speziell zum Einrichten des Inhaltstypwerts (Content-Type) in MIME.
Die ganze Reihe der in dieser Anforderung verwendeten HTTP-Header wird erstellt, indem die Header mit dem in den folgenden Schritten definierten Algorithmus ausgewählt werden:
- Richten Sie den Header 'Host' entweder auf Basis der Anforderungs-URL oder des Abschnitts
'HTTPRequestHeader' der eingehenden Nachricht ein.
- Wählen Sie einen oder mehrere Header in einem HTTPRequestHeader aus.
- Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie ihn, indem Sie einen beliebigen Wert in der Eigenschaft 'ContentType' auswählen.
- Wählen Sie einen oder mehrere Header in einem HTTPInputHeader aus (ein HTTPInputHeader wird automatisch von einem HTTPInput-Knoten erstellt).
- Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie einen mit dem
Standardwert text/xml; charset=CCSID des Nachrichtenhauptteils.
- Wenn bislang noch kein SOAPAction-Header definiert wurde, erstellen Sie einen mit dem
Standardwert ''.
- Erstellen oder überschreiben Sie den Content-Length-Header.
Achtung: Der HTTPRequest- oder
HTTPAsyncRequest-Knoten schreibt den Header
'Content-Length' (Inhaltslänge) immer neu, auch wenn
HTTP-Standard-Header auf Basis von Eingabe oder Anforderung
generieren nicht aktiviert ist. Dadurch wird die Richtigkeit des Inhalts sichergestellt.
Wenn die empfangene Nachricht den Header 'HTTPRequestHeader' enthält,
wird der Header 'HTTPRequestHeader' mit allen geänderten oder hinzugefügten Werten aktualisiert.