WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Mit HTTP-Nachrichtenflüssen arbeiten

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:
  1. Wählen Sie einen oder mehrere Header in einem HTTPReplyHeader aus.
  2. Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie ihn, indem Sie einen beliebigen Wert in der Eigenschaft 'ContentType' auswählen.
  3. Wählen Sie einen oder mehrere Header in einem HTTPResponseHeader aus (ein HTTPResponseHeader wird bei der Rücklieferung von einem HTTPRequest-Knoten weitergegeben).
  4. Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie einen mit dem Standardwert text/xml; charset=CCSID des Nachrichtenhauptteils.
  5. 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:
  1. Richten Sie den Header 'Host' entweder auf Basis der Anforderungs-URL oder des Abschnitts 'HTTPRequestHeader' der eingehenden Nachricht ein.
  2. Wählen Sie einen oder mehrere Header in einem HTTPRequestHeader aus.
  3. Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie ihn, indem Sie einen beliebigen Wert in der Eigenschaft 'ContentType' auswählen.
  4. Wählen Sie einen oder mehrere Header in einem HTTPInputHeader aus (ein HTTPInputHeader wird automatisch von einem HTTPInput-Knoten erstellt).
  5. Wenn bislang noch kein Content-Type-Header definiert wurde, erstellen Sie einen mit dem Standardwert text/xml; charset=CCSID des Nachrichtenhauptteils.
  6. Wenn bislang noch kein SOAPAction-Header definiert wurde, erstellen Sie einen mit dem Standardwert ''.
  7. 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.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:03


TaskthemaTaskthema | Version 8.0.0.5 | ac20450_