Dieses Kapitel enthält folgende Abschnitte:
Mit Hilfe des HTTPEmpfangsknotens können Sie Webdienstanforderungen zur Verarbeitung durch einen Nachrichtenfluss empfangen. Bei der Verwendung des HTTPEmpfangsknotens mit dem HTTPAntwort- und HTTPAnforderungsknoten kann der Broker als Zwischenstation für Web-Services fungieren, und Web-Service-Anforderungen können auf die gleiche Weise umgewandelt und weitergeleitet werden wie andere Nachrichtenformate, die von WebSphere Message Broker unterstützt werden. Web-Serviceanfragen können im HTTP-Standardformat (1.0 oder 1.1) und im HTTP over SSL- (HTTPS-)Format empfangen werden. Sie können die Eigenschaft HTTPS verwenden so festlegen, dass Sie die Verarbeitung von HTTP- oder HTTPS-Anfragen auswählen können.
Wenn Sie den HTTPEmpfangsknoten in einen Nachrichtenfluss einfügen, müssen Sie entweder einen HTTPAntwortknoten (HTTPReply) in demselben Fluss einfügen oder die Nachricht an einen anderen Fluss übergeben, der einen HTTPAntwortknoten enthält (beispielsweise über einen MQSendeknoten an einen zweiten Fluss, der mit einem MQEmpfangsknoten beginnt). Im letzteren Fall werden die Anforderung des Clients und die Antwort an ihn über die Anforderungskennung koordiniert, die in der lokalen Umgebung gespeichert ist (siehe Beschreibung unten).
Der HTTPEmpfangsknoten bearbeitet Nachrichten in den folgenden Nachrichtendomänen:
Sobald der HTTPEmpfangsknoten eine Nachricht von einem Webdienstclient erhält, ruft er die geeigneten Parser zur Interpretation der Header und des Nachrichtenhauptteils sowie zur Erstellung der Nachrichtenbaumstruktur auf, die intern vom Nachrichtenfluss verwendet wird. Der Knoten erstellt eine eindeutige Kennung für die Eingabenachricht und speichert diese unter LocalEnvironment.Destination.HTTP.RequestIdentifer als binären Bereich mit 24 Bytes in der Baumstruktur 'LocalEnvironment'. Dieser Wert wird vom HTTPAntwortknoten verwendet und darf auf keine Weise geändert werden.
HTTP-Nachrichten sind immer nicht permanent, und sie haben keine bestimmte Reihenfolge.
HTTP-Nachrichten sind nicht transaktionsorientiert. Wenn der Nachrichtenfluss jedoch mit einer Datenbank oder einer anderen externen Ressource wie beispielsweise einer WebSphere MQ-Warteschlange interagiert, werden diese Interaktionen transaktionsorientiert ausgeführt. Der HTTPEmpfangsknoten bietet eine COMMIT-Operation (Festschreiben) oder ROLLBACK-Operation ausführen (Zurücksetzen) an. Dies ist abhängig davon, wie der Nachrichtenfluss beendet wurde, und wie er für die Fehlerbehandlung konfiguriert ist (beispielsweise wie die Fehlerterminals verbunden sind). Wenn der Nachrichtenfluss von diesem Knoten zurückgegeben wird, wird eine Fehlernachricht generiert und an den Client ausgegeben. Das Format des Fehlers wird in der Eigenschaft 'Falsches Format' definiert.
Falls in diesem Nachrichtenfluss eine Ausnahmebedingung eintritt und diese nicht abgefangen, sondern an diesen Knoten zurückgegeben wird, erstellt der Knoten eine Fehlerantwort an den Client. Dieser Fehler wird von der Ausnahmebedingung abgeleitet, und das Format des Fehlers wird durch die Eigenschaft 'Falsches Format' definiert.
Wenn Sie einen Sendeknoten in einen Nachrichtenfluss einschließen, der mit einem HTTPEmpfangsknoten beginnt, können Sie einen beliebigen unterstützten Sendeknoten (einschließlich benutzerdefinierter Sendeknoten) verwenden. Sie können einen Nachrichtenfluss erstellen, der Nachrichten von Webdienstclients empfängt und Nachrichten für Clients generiert, die alle unterstützten Transportprotokolle verwenden, um eine Verbindung zum Broker herzustellen, da Sie den Nachrichtenfluss so konfigurieren können, dass der Broker auf Anforderung alle erforderlichen Konvertierungen bereitstellt.
Wenn Sie einen Nachrichtenfluss erstellen, der als untergeordneter Fluss verwendet werden soll, können Sie keinen Standardempfangsknoten verwenden. Sie müssen eine Instanz des Empfangsknotens als ersten Knoten verwenden, um ein Eingangsterminal für den untergeordneten Fluss zu erstellen.
Empfängt Ihr Nachrichtenfluss keine Web-Service-Anforderungen, können Sie einen der unterstützten Empfangsknoten verwenden.
Der HTTPEmpfangsknoten wird in Workbench durch folgendes Symbol dargestellt:
Der HTTPEmpfangsknoten kann in jedem Nachrichtenfluss verwendet werden, der HTTP- oder HTTPS-Nachrichten annehmen muss. Das häufigste Beispiel hierfür ist ein Nachrichtenfluss, durch den ein Web-Service implementiert wird. Weitere Informationen zu Web-Serviceanwendungen finden sie unter Web-Service-Anwendungen.
Wenn Sie eine Instanz des HTTPEmpfangsknotens in einen Nachrichtenfluss eingereiht haben, können Sie ihn konfigurieren. Klicken Sie mit der rechten Maustaste in der Editoransicht auf den Knoten, und wählen Sie die Option Eigenschaften aus. Daraufhin werden im Eigenschaftendialog die grundlegenden Eigenschaften des Knotens angezeigt.
Alle verbindlichen Eigenschaften, für die Sie einen Wert eingeben müssen (d. h. Eigenschaften ohne definierten Standardwert), sind dort mit einem Sternchen gekennzeichnet.
Konfigurieren Sie den HTTPEmpfangsknoten wie folgt:
Bei XML-, XMLNS-, XMLNSC-, JMS-, MIME- und BLOB-Parsern erfolgt im Feld Nachrichtengruppe keine Angabe.
Lassen Sie bei XML-, XMLNS-, XMLNSC-, JMS-, IDOC-, MIME- und BLOB-Parsern die Option Nachrichtenart leer.
Bei XML-, XMLNS-, XMLNSC, JMS, MIME- und BLOB-Parsern erfolgt im Feld Nachrichtenformat keine Angabe.
Sie finden detaillierte Informationen hierzu unter Nachrichten überprüfen und Eigenschaften der Gültigkeitsprüfung für Nachrichten in der MRM-Domäne.
Klicken Sie auf Abbrechen, um das Dialogfeld zu schließen und alle Änderungen zu verwerfen, die Sie an den Eigenschaften vorgenommen haben.
Der HTTPEmpfangsknoten leitet jede Nachricht, die er erfolgreich abruft, an das Ausgangsterminal weiter. Schlägt die Nachrichtenauswertung fehl, wird die Nachricht an das Fehlerterminal weitergeleitet. Sie können Knoten mit diesem Terminal verbinden, um diesen Zustand zu beheben. Wenn Sie keine Verbindung zum Fehlerterminal hergestellt haben, wird die Nachricht gelöscht, die maximale Wartezeit für den Client läuft ab, und das TCP/IP-Empfangsprogramm meldet dem Client einen Fehler. Es gibt keine anderen Situationen, in denen die Nachricht an das Fehlerterminal weitergeleitet wird.
Wenn die Nachricht von diesem Knoten abgefangen wird, nachdem eine Ausnahmebedingung weiter vorne im Nachrichtenfluss ausgegeben wurde, wird die Nachricht an das Catch-Terminal weitergeleitet. Wenn Sie keine Verbindung zum Catch-Terminal hergestellt haben, wird die Nachricht gelöscht, die maximale Wartezeit für den Client läuft ab, und das TCP/IP-Empfangsprogramm meldet dem Client einen Fehler.
In der nachfolgenden Tabelle werden die Terminals des HTTPEmpfangsknotens beschrieben.
Terminal | Beschreibung |
---|---|
Fehlerterminal | Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn ein Fehler auftritt. |
Ausgangsterminal | Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn sie erfolgreich abgerufen wurde. |
Catch-Terminal | Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn nachgeschaltet eine Ausnahmebedingung ausgegeben und von diesem Knoten abgefangen wurde. |
In der nachfolgenden Tabelle werden die Knoteneigenschaften beschrieben. Die Spalte M zeigt an, ob die Eigenschaft obligatorisch ist (markiert mit einem Sternchen im Eigenschaftendialog, ob Sie einen Wert eingeben müssen, wenn kein Standardwert definiert ist). Die Spalte C zeigt an, ob die Eigenschaft konfigurierbar ist (Sie können den Wert ändern, wenn Sie der BAR-Datei den Nachrichtenfluss hinzufügen, um ihn einzusetzen).
In der nachfolgenden Tabelle werden die grundlegenden Eigenschaften des HTTPEmpfangsknotens beschrieben.
Eigenschaft | M | C | Standard | Beschreibung |
---|---|---|---|---|
URL-Selektor | Ja | Ja | Standort, von dem Web-Service-Anforderungen abgerufen werden. Wenn die gewünschte URL http://<Hostname>[:<Port>]/[<Pfad>] ist, müssen Sie entweder /<Pfad> oder /<Pfadfragment>/* angeben; dabei ist * ein Platzhalterzeichen, das für jedes Zeichen stehen kann. | |
Maximale Wartezeit für Client | Ja | Nein | 180 | Gibt an, wie lange (in Sekunden) das Empfangsprogramm wartet, bevor es eine Fehlernachricht an den Client sendet. Der gültige Bereich liegt zwischen Null (unendliche Wartezeit) und (231)-1. |
Falsches Format | Nein | Ja | SOAP 1.1 | Der Eigenschaftswert kann SOAP 1.1, SOAP 1.2 oder HTML sein. Durch diese Eigenschaft wird das Format von beliebigen HTTP-Fehlern definiert, die an den Client zurückgegeben werden. |
HTTPS verwenden | Nein | Ja | Nein | Gibt an, ob der Knoten sicheres HTTP akzeptiert. |
In der nachfolgenden Tabelle werden die Standardeigenschaften des HTTPEmpfangsknotens beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung |
---|---|---|---|---|
Nachrichtendomäne | Nein | Nein | Die Domäne, die für die Syntaxanalyse der ankommenden Nachricht verwendet wird. | |
Nachrichtengruppe | Nein | Nein | Der Name oder die ID der Nachrichtengruppe, in der die ankommende Nachricht definiert ist. | |
Nachrichtenart | Nein | Nein | Der Name der ankommenden Nachricht. | |
Nachrichtenformat | Nein | Nein | Der Name des physischen Formats der ankommenden Nachricht. |
In der nachfolgenden Tabelle werden die Auswertungseigenschaften des HTTPEmpfangsknotens beschrieben.
Der Abschnitt Eigenschaften der Gültigkeitsprüfung für Nachrichten in der MRM-Domäne enthält eine ausführliche Beschreibung der Eigenschaften.
Eigenschaft | M | C | Standard | Beschreibung |
---|---|---|---|---|
Auswerten | Nein | Ja | Keine | Gibt an, ob eine Auswertung stattfindet. Gültige Werte sind Keine, Inhalt und Wert und Inhalt. |
Aktion bei Fehler | Nein | Nein | Ausnahme | Gibt an, welche Maßnahme beim Auftreten eines Auswertungsfehlers ergriffen wird. 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 (ausgewähltes Markierungsfeld) besteht darin, dass in der Auswertung von Inhalt und Wert auch Basisprüfungen der Wertvorgaben ausgeführt werden. |
Korrektur | Nein | Nein | Keine | Diese Eigenschaft kann nicht bearbeitet werden. |
In der nachfolgenden Tabelle werden die Eigenschaften der allgemeinen Nachrichtenoptionen des HTTPEmpfangsknotens beschrieben.
Eigenschaft | M | C | Standard | Beschreibung |
---|---|---|---|---|
Zeitpunkt für Syntaxanalyse | Nein | Nein | Bei Bedarf | Durch diese Eigenschaft wird gesteuert, zu welchem Zeitpunkt eine Eingabenachricht syntaktisch analysiert wird.
Gültige Werte sind Bei Bedarf, Sofort und Vollständig. Der Abschnitt Bedarfsgerechte Syntaxanalyse enthält eine ausführliche Beschreibung dieser Eigenschaft. |
MQRFH2C Compact Parser für MQRFH2-Domäne verwenden | Nein | Nein | Gelöscht | Durch diese Eigenschaft wird gesteuert, ob der MQRFH2C Compact Parser anstelle des MQRFH2-Parsers für MQRFH2-Header verwendet wird. |
In der nachfolgenden Tabelle werden die Eigenschaften der XMLNSC-Parseroptionen für den HTTPEmpfangsknoten beschrieben.
Eigenschaft | M | C | Standard | Beschreibung |
---|---|---|---|---|
XMLNSC Compact Parser für XMLNS-Domäne verwenden | Nein | Nein | Gelöscht | ![]() ![]() |
Residenter Modus für gemischten Inhalt | Nein | Nein | Keine | Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser beim Feststellen von gemischtem Text in einer Eingabenachricht Elemente in der Nachrichtenbaumstruktur erstellt. Gültige Werte sind Keine und Alle. Durch die Auswahl von Alle werden Elemente für gemischte Texte erstellt. Durch die Auswahl von Keine werden gemischte Texte ignoriert und keine Elemente erstellt. |
Residenter Modus für Kommentare | Nein | Nein | Keine | Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser beim Feststellen von Kommentaren in einer Eingabenachricht Elemente in der Nachrichtenbaumstruktur erstellt. Gültige Werte sind Keine und Alle. Durch die Auswahl von Alle werden Elemente für Kommentare erstellt. Durch die Auswahl von Keine werden Kommentare ignoriert und keine Elemente erstellt. |
Residenter Modus für Verarbeitungsanweisungen | Nein | Nein | Keine | Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser beim Feststellen von Verarbeitungsanweisungen in einer Eingabenachricht Elemente in der Nachrichtenbaumstruktur erstellt. Gültige Werte sind Keine und Alle. Durch die Auswahl von Alle werden Elemente für Verarbeitungsanweisungen erstellt. Durch die Auswahl von Keine werden Verarbeitungsanweisungen ignoriert und keine Elemente erstellt. |
In der nachfolgenden Tabelle werden die Beschreibungseigenschaften des HTTPEmpfangsknotens beschrieben.
Eigenschaft | M | C | Standard | Beschreibung |
---|---|---|---|---|
Kurzbeschreibung | Nein | Nein | Kurze Beschreibung des Knotens | |
Ausführliche Beschreibung | Nein | Nein | Text, der den Zweck des Knotens im Nachrichtenfluss beschreibt |