Dieses Thema ist in folgende Abschnitte eingeteilt:
Verwenden Sie den HTTPEmpfangsknoten, um Web-Service-Anforderungen für die Verarbeitung durch einen Nachrichtenfluss zu 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 einen HTTPAntwortknoten in einem Nachrichtenfluss einschließen, müssen Sie entweder einen HTTPAntwortknoten in den gleichen Fluss einbeziehen oder die Nachricht an einen anderen Fluss übergeben, der einen HTTPAntwortknoten (z. B. über einen MQSendeknoten an einen zweiten Fluss, der mit einem MQEmpfangsknoten startet) enthält. Im zweiten Fall (der Anforderung von und Antwort an) werden die Clients von der Anforderungs-ID koordiniert, die in der lokalen Umgebung gespeichert ist (siehe Beschreibung unten).
Der HTTPEmpfangsknoten bearbeitet Nachrichten in den folgenden Nachrichtendomänen:
Wenn der HTTPEmpfangsknoten eine Nachricht von einem Web-Service-Client erhält, ruft er die entsprechenden Parser auf, um die Header und den Hauptteil der Nachricht zu interpretieren und die Nachrichtenbaumstruktur zu erzeugen, die intern vom Nachrichtenfluss verwendet wird. Der Knoten erzeugt eine eindeutige Kennung für die Eingabenachricht und speichert sie als binäre Gruppe von 24 Bytes in der Baumstruktur der lokalen Umgebung unter 'LocalEnvironment.Destination.HTTP.RequestIdentifer'. Dieser Wert wird vom HTTPAntwortknoten verwendet und darf nicht Weise geändert werden.
HTTP-Nachrichten sind immer nicht persistent und haben keine zugehörige Reihenfolge.
HTTP-Nachrichten sind nicht transaktionsorientiert. Falls der Nachrichtenfluss jedoch mit einer Datenbank oder einer anderen externen Ressource (wie z. B. einer WebSphere MQ-Warteschlange) interagiert, werden die Interaktionen transaktionsorientiert ausgeführt. Der HTTPEmpfangsknoten führt eine COMMIT- oder eine ROLLBACK-Operation aus, abhängig davon, wie der Nachrichtenfluss endet und wie er für die Fehlerbehandlung (z. B. wie Fehlerterminals verbunden sind) konfiguriert ist. 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 in einem Nachrichtenfluss, der mit einem HTTPEmpfangsknoten startet, einen Sendeknoten einschließen, kann dieser einer der unterstützten Sendeknoten sein (einschließlich benutzerdefinierter Sendeknoten). Sie können einen Nachrichtenfluss erstellen, der Nachrichten von Web-Service-Clients empfängt und Nachrichten für Clients generiert, die alle unterstützten Transportmethoden verwenden, um eine Verbindung mit dem Broker herzustellen, da Sie den Nachrichtenfluss so konfigurieren können, dass er den Broker auffordert, die erforderliche Konvertierung bereitzustellen.
Wenn Sie einen Nachrichtenfluss entsprechend erstellen, dass er einen untergeordneten Fluss verwendet, können Sie keinen Standardsendeknoten verwenden, sondern müssen eine Instanz des Empfangsknotens als ersten Knoten nehmen, 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 der Workbench durch das folgende 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 sie konfigurieren. Klicken Sie in der Editoransicht mit der rechten Maustaste auf den Knoten, und wählen Sie dann Eigenschaften. Es werden die Grundeigenschaften des Knotens im Eigenschaftendialog angezeigt.
Alle verbindlichen Eigenschaften, für die Sie einen Wert eingeben müssen (diejenigen, für die kein Standardwert definiert ist), sind im Eigenschaftendialog mit einem Stern markiert.
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 prüfen und Eigenschaften der Gültigkeitsprüfung für Nachrichten in der MRM-Domäne.
Klicken Sie auf Abbrechen, um den Dialog zu schließen und alle Änderungen zu verwerfen, die Sie an den Eigenschaften durchgeführt hatten.
Der HTTPEmpfangsknoten leitet jede Nachricht, die er erfolgreich abruft, an das Ausgangsterminal weiter. Falls die Nachrichtenauswertung fehlschlägt, wird die Nachricht an das Fehlerterminal weitergeleitet; Sie können Knoten mit diesem Terminal verbinden, um diese Bedingung zu handhaben. Falls Sie das Fehlerterminal nicht verbunden haben, wird die Nachricht verworfen, die Maximale Wartezeit für Client läuft ab, und das TCP/IP-Empfangsprogramm gibt einen Fehler an den Client zurück. Es gibt keine anderen Situationen, in denen die Nachricht an das Fehlerterminal weitergeleitet wird.
Wenn nach Ausgabe einer Ausnahmebedingung später im Fluss die Nachricht von diesem Knoten abgefangen wird, wird sie an das Abfangterminal weitergeleitet. Falls Sie das Abfangterminal nicht verbunden haben, wird die Nachricht verworfen, die Maximale Wartezeit für Client läuft ab, und das TCP/IP-Empfangsprogramm gibt einen Fehler an den Client zurück.
Die Terminals des HTTPEmpfangsknotens werden in der folgenden Tabelle beschrieben.
Terminal | Beschreibung |
---|---|
Fehlerterminal | Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn ein Fehler auftritt. |
Ausgabeterminal | Das Ausgabeterminal, an das die Nachricht weitergeleitet wird, wenn sie erfolgreich abgerufen wird. |
Abfangterminal | Das Ausgabeterminal, an das die Nachricht weitergeleitet wird, wenn eine Ausnahmebedingung ausgegeben und von diesem Knoten abgefangen wird. |
Die folgenden Tabellen beschreiben die Knoteneigenschaften; die Spalte mit der Überschrift 'O' gibt an, dass die Eigenschaft obligatorisch ist (beim Eigenschaftendialog mit einem Stern markiert, wenn Sie einen Wert eingeben müssen, falls kein Standardwert definiert ist); die Spalte mit der Überschrift 'K' gibt an, ob die Eigenschaft konfigurierbar ist (Sie können den Wert ändern, wenn Sie den Nachrichtenfluss der BAR-Datei hinzufügen, um sie einzusetzen).
Die Grundeigenschaften des HTTPEmpfangsknotens werden in der folgenden Tabelle beschrieben.
Eigenschaft | O | K | Standardwert | 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 | Wie lange das Empfangsprogramm wartet (in Sekunden), bevor eine Fehlernachricht an den Client gesendet wird. Der gültige Bereich geht von Null (d. h. eine unbestimmte Zeit) bis (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. |
Die Standardeigenschaften des HTTPEmpfangsknotens werden in der folgenden Tabelle 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 | O | K | Standardwert | Beschreibung |
---|---|---|---|---|
Auswerten | Nein | Ja | Keine | Durchführung einer Auswertung. Gültige Werte sind Keine, Inhalt und Wert und Inhalt. |
Aktion bei Fehler | Nein | Nein | Ausnahme | Aktion beim Fehlschlagen einer Gültigkeitsprüfung. 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 Kontrollkästchen) 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 | O | K | Standardwert | 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 | O | K | Standardwert | Beschreibung |
---|---|---|---|---|
XMLNSC Compact Parser für XMLNS-Domäne verwenden | Nein | Nein | Gelöscht | Durch diese Eigenschaft wird gesteuert, ob der XMLNSC-Parser beim Feststellen von Nachrichten in der XMLNS-Domäne zum Erstellen von Elementen in der Nachrichtenbaumstruktur verwendet wird. |
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. |
Die Beschreibungseigenschaften des HTTPEmpfangsknotens werden in der folgenden Tabelle beschrieben.
Eigenschaft | O | K | Standardwert | Beschreibung |
---|---|---|---|---|
Kurzbeschreibung | Nein | Nein | Eine Kurzbeschreibung des Knotens. | |
Ausführliche Beschreibung | Nein | Nein | Text, der den Zweck des Knotens im Nachrichtenfluss beschreibt. |