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.

HTTPInput-Knoten

Verwenden Sie den HTTPInput-Knoten, um eine HTTP-Nachricht von einem HTTP-Client für die Verarbeitung durch einen Nachrichtenfluss zu empfangen.

Dieses Thema ist in folgende Abschnitte eingeteilt:

Zweck

Wenn Sie den HTTPInput-Knoten mit den HTTPReply- und HTTPRequest-Knoten verwenden, kann der Broker als Zwischenstation für Web-Services fungieren und Web-Service-Anforderungen können auf dieselbe Weise umgewandelt und weitergeleitet werden wie andere von WebSphere Message Broker unterstützte Nachrichtenformate.

Web-Service-Anforderungen können im HTTP-Standardformat (1.0 oder 1.1) oder im HTTP over SSL-Format (HTTPS) empfangen werden. Weitere Informationen zu Web-Services finden Sie im Abschnitt Web-Service-Nachrichten verarbeiten.

Der HTTPInput-Knoten unterstützt HTTP POST und HTTP GET. Weitere Informationen zum Aktivieren von HTTP GET finden Sie unter HTTPRequest-Knoten.

Wenn Ihre Nachrichtenflüsse SOAP-Nachrichten verarbeiten, bevorzugen Sie den SOAP-Knoten gegenüber dem HTTPInput-Knoten, um die erweiterten Funktionen einschließlich WS-Adressierung und WS-Sicherheit zu nutzen.

Der HTTPInput-Knoten bearbeitet Nachrichten in den folgenden Nachrichtendomänen:
  • MRM
  • XMLNSC
  • XMLNS
  • MIME
  • BLOB
  • XML (diese Domäne ist veraltet; verwenden Sie XMLNSC)
  • JSON
  • DFDL

HTTP-Nachrichten sind niemals permanent und haben keine bestimmte Reihenfolge.

HTTP-Nachrichten sind nicht transaktionsorientiert. Wenn der Nachrichtenfluss jedoch mit einer Datenbank oder einer anderen externen Ressource, z. B. einer WebSphere MQ-Warteschlange, interagiert, werden diese Interaktionen in einer Transaktion ausgeführt. Der HTTPInput-Knoten bietet eine COMMIT-Operation (Festschreiben) oder ROLLBACK-Operation (Zurücksetzen) an. Dies ist abhängig davon, wie der Nachrichtenfluss beendet wurde und wie er für die Fehlerbehandlung konfiguriert ist (z. B. wie die Fehlerterminals verbunden sind). Wenn der Nachrichtenfluss von diesem Knoten zurückgesetzt 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 HTTPInput-Knoten beginnt, können Sie einen beliebigen unterstützten Sendeknoten (einschließlich benutzerdefinierter Sendeknoten) verwenden. 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 für die Verbindung mit dem Broker verwenden. Sie können den Nachrichtenfluss so konfigurieren, dass der Broker auf Anforderung alle erforderlichen Konvertierungen bereitstellt.

Wenn Sie einen Nachrichtenfluss erstellen, der als untergeordneter Nachrichtenfluss eingesetzt werden soll, können Sie keinen Standardempfangsknoten verwenden. Sie müssen einen Empfangs als ersten Knoten verwenden, um ein Eingangsterminal für den untergeordneten Nachrichtenfluss zu erstellen.

Der HTTPInput-Knoten befindet sich im HTTP-Fach der Palette und wird im WebSphere Message Broker Toolkit durch folgendes Symbol dargestellt:

Symbol für HTTPInput-Knoten

Diesen Knoten in einem Nachrichtenfluss verwenden

Wenn Sie den HTTPInput-Knoten in einen Nachrichtenfluss einfügen, müssen Sie entweder einen HTTPReply-Knoten in demselben Fluss einfügen oder die Nachricht an einen anderen Fluss übergeben, der einen HTTPReply-Knoten enthält (beispielsweise über einen MQOutput-Knoten an einen zweiten Fluss, der mit einem MQInput-Knoten beginnt). Im zweiten Fall werden die Anforderung vom und die Antwort an den Client von der Anforderungs-ID koordiniert, die vom HTTPInput-Knoten in der lokalen Umgebung gespeichert wird.

Es ist nicht möglich, für die Beantwortung einer von einem HTTPInput-Knoten empfangenen Web-Service-Anforderung einen SOAPReply-Knoten zu verwenden. Beim Versuch einer Antwort wird vom Broker eine Ausnahmebedingung generiert.

Wenn der HTTPInput-Knoten eine Nachricht von einem Web-Service-Client empfängt, startet er die entsprechenden Parser, um die Header und den Hauptteil der Nachricht zu interpretieren und die Nachrichtenbaumstruktur zu erstellen, die intern vom Nachrichtenfluss verwendet wird. Der Knoten erstellt eine eindeutige Kennung für die Eingabenachricht und speichert diese unter LocalEnvironment.Destination.HTTP.RequestIdentifier als binäres Array mit 24 Bytes in der Baumstruktur der lokalen Umgebung. Dieser Wert wird vom HTTPReply-Knoten verwendet und darf daher nicht geändert werden.

Standardmäßig werden HTTP- und HTTPS-Nachrichten vom brokerweiten Empfangsprogramm verarbeitet, das gestartet wird, wenn ein Nachrichtenfluss, der einen HTTP-Knoten enthält, gestartet wird. Alle eingehenden und ausgehenden HTTP-Nachrichten werden durch dieses Empfangsprogramm geleitet, und zwar für alle HTTP-Knoten, die in allen Nachrichtenflüssen in allen Ausführungsgruppen auf dem Broker implementiert werden.

Sie können eine Ausführungsgruppe so konfigurieren, dass sie mithilfe ihres eingebetteten Empfangsprogramms die HTTP-Knoten in allen Nachrichtenflüssen verarbeitet, die für diese Ausführungsgruppe implementiert sind. Das eingebettete Empfangsprogramm kommuniziert direkt mit dem Client und den Knoten.

Wenn Sie die Ausführungsgruppe für die Verwendung ihres integrierten Empfangsprogramms für HTTP-Knoten konfigurieren, müssen Sie den Nachrichtenfluss, der den HTTPReply-Knoten enthält, in derselben Ausführungsgruppe implementieren. Wenn Ihr Broker für den Start des brokerweiten Empfangsprogramms zur Unterstützung von HTTP-Knoten konfiguriert ist, müssen Sie den Antwortnachrichtenfluss auf demselben Broker implementieren, die Ausführungsgruppe ist jedoch nicht wichtig.

Weitere Informationen zur Verwendung des eingebetteten Empfangsprogramms finden Sie unter HTTP-Empfangsprogramme.

Wenn ein Client eine mit gzip oder komprimieren komprimierte Anforderung an den HTTPInput-Knoten sendet, kann diese über die Option zur Dekomprimierung der Eingabenachricht (Decompress input message) extrahiert werden. Diese Dekomprimierung erfolgt nur, wenn in der Konfiguration der Ausführungsgruppe festgelegt ist, dass HTTP-Knoten das integrierte HTTP-Empfangsprogramm der Ausführungsgruppe und nicht das brokerweite HTTP-Empfangsprogramm verwenden sollen.

HTTPInput- und HTTPReply-Knoten als Web-Server verwenden

Ein Broker kann mehrere HTTPInput-Knoten unterstützen. Geben Sie bei der Konfiguration des HTTPInput-Knotens die Anforderungen, für die der Knoten empfangsbereit ist, in Form eines URL-Pfades ohne Host- und Portdetails an.

Wenn der Broker beispielsweise an der Adresse http://localhost:7080 empfangsbereit ist und die Anforderung http://localhost:7080/Joe/Mary empfängt, entfernt das Empfangsprogramm die HTTP-Adresse und lässt nur die Anforderung selbst (Joe/Mary) stehen. Anschließend gleicht das Empfangsprogramm diese Anforderung mit den Informationen in der URL-Eigenschaft des oder der HTTPInput-Knoten(s) ab.

Dieser Abgleich beginnt mit den spezifischsten Daten und endet mit den generischsten Daten. Sie können für weniger spezifische Übereinstimmungen ein Platzhalterzeichen (einen Stern) verwenden. Wenn Sie beispielsweise einen HTTPInput-Knoten für die Annahme von Anforderungen konfiguriert haben, die /Joe/Mary entsprechen, empfängt dieser Knoten die Nachricht. Wenn die Anforderung jedoch http://localhost:7080/Joe/Sally lautet, gibt es für diesen Knoten keine Übereinstimmung. Die Übereinstimmung kann bei einem Knoten vorliegen, der eine allgemeinere URL wie beispielsweise einen der folgenden Werte aufweist:

/Joe/*
/*

Wenn die Anforderung mit keiner URL-Eigenschaft übereinstimmt und kein Empfangsknoten mit /* festgelegt wurde, wird vom HTTPInput-Knoten eine Antwort an den Sender geschickt.

Sie können eine URL der Form /* verwenden, um alle Anforderungen abzufangen, die nicht mit den URLs in den HTTPInput-Knoten übereinstimmen. Dies ermöglicht Ihnen, eine Antwort zu senden und andere geeignete Maßnahmen zu ergreifen.

In diesem Beispiel wird der Port 7080 verwendet, welcher den HTTP-Standardport für das brokerweite Empfangsprogramm darstellt. Die Standardportnummern für das eingebettete Ausführungsgruppen-Empfangsprogramm lauten 7800 bei HTTP und 7843 bei HTTPS. Sie können diese Portnummer und Portbereiche, die von den Ausführungsgruppen-Empfangsprogrammen verwendet werden, mit dem Befehl mqsichangeproperties ändern.

Wenn Sie SOAP-Knoten und HTTP-Knoten in Nachrichtenflüssen auf einem einzelnen Broker verwenden, können Sie festlegen, ob die Verarbeitung von HTTP-Nachrichten über das Empfangsprogramm des Brokers oder über die eingebetteten Empfangsprogramme der Ausführungsgruppen erfolgt. Wenn ein Empfangsprogramm in Ihrer Konfiguration Nachrichten empfängt, die sowohl von SOAPInput- als auch von HTTPInput-Knoten abgerufen werden könnten, müssen die URL-Spezifikationen in diesen Knoten genau überprüft werden. Wenn beide URL-Spezifikationen einer eingehenden Nachricht entsprechen, besteht die Gefahr, dass der falsche Knotentyp die Nachricht erhält und die Verarbeitung fehlschlägt oder zu unerwarteten Ergebnissen führt. Diese Situation entsteht, wenn Sie identische Werte für die Eigenschaften Pfadsuffix für URL des HTTPInput-Knotens und des SOAPInput-Knotens angeben. Dies ist im Übrigen auch der Fall, wenn Sie in einer der beiden Spezifikationen Platzhalterzeichen verwenden und eine eingehende Nachricht dadurch beiden Eigenschaften entspricht.

Wenn Sie das Brokerempfangsprogramm für den HTTP- und HTTPS-Datenverkehr nutzen möchten, prüfen Sie, ob die Brokereigenschaften der Empfangsprogrammports für HTTP und HTTPS geeignet sind. Der Standardport für HTTP lautet 7080; der Standardport für HTTPS lautet 7083.

Wenn Sie das Ausführungsgruppen-Empfangsprogramm nutzen möchten, müssen Sie die Ausführungsgruppe mit dem Befehl mqsichangeproperties so konfigurieren, dass das Empfangsprogramm für HTTP- und HTTPS-Nachrichten aktiviert ist. Der Standardport für HTTP lautet 7800; der Standardport für HTTPS lautet 7843. Sie können diese Portnummer und die Bereiche, aus denen die Ports zugeordnet werden, mit dem Befehl mqsichangeproperties ändern.

Falls Sie Traceinformationen zur HTTP-Nachrichtenverarbeitung sammeln möchten, lesen Sie den Abschnitt Probleme bei der Verwendung von HTTP- und SOAP-Knoten beheben.

Verbindungen zu Terminals herstellen

Der HTTPInput-Knoten leitet jede Nachricht, die er erfolgreich empfängt, an das Ausgangsterminal weiter. Schlägt die Nachrichtenvalidierung fehl, wird die Nachricht an das Fehlerterminal weitergeleitet. Mit diesem Terminal können Sie zur Bearbeitung dieser Situation Knoten verbinden. Wenn keine Verbindung zum Fehlerterminal besteht, wird die Nachricht gelöscht, die maximale Wartezeit für den Client läuft ab und dem Client wird ein Fehler gemeldet. 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 ausgelöst wurde, wird die Nachricht an das Catch-Terminal weitergeleitet. Wenn keine Verbindung zum Catch-Terminal besteht, wird die Nachricht gelöscht, die maximale Wartezeit für den Client läuft ab und dem Client wird ein Fehler gemeldet.

Wenn die maximale Wartezeit für den Client abläuft, gibt das Empfangsprogramm standardmäßig eine Fehlernachricht an den Client zurück mit der Information, dass das Zeitlimit überschritten wurde. Wenn eine Verbindung zum HTTPTimeout-Terminal besteht und die Ausführungsgruppe so konfiguriert ist, dass die HTTP-Knoten das eingebettete Empfangsprogramm verwenden, wird diese Fehlernachricht zur Zeitlimitüberschreitung an das Timeout-Terminal weitergegeben. In diesem Szenario wartet das Empfangsprogramm erneut, und zwar in dem Intervall, das durch die Eigenschaft maximale Wartezeit für den Client (in Sekunden) definiert ist, bzw. für 10 Sekunden (je nachdem, welches das kürzere Zeitintervall ist):
  • Wird vor Ablauf dieses zweiten Intervalls eine Antwort empfangen, wird diese vom Empfangsprogramm an den Client weitergeleitet.
  • Geht vor Ablauf des zweiten Intervalls keine Antwort ein, sendet das Empfangsprogramm an den Client eine Fehlernachricht mit der Mitteilung, dass das Zeitlimit abgelaufen ist.
Da das Empfangsprogramm nur für einen kurzen Zeitraum nach Weitergabe der Nachricht durch das HTTPTimeout-Terminal wartet, müssen Sie sicherstellen, dass die Folge der Knoten, die Sie mit dem HTTPTimeout-Terminal verbinden, einen HTTPReply-Knoten umfasst, der vor Ablauf dieses Intervalls eine Antwort sendet.

Terminals und Eigenschaften

Nachdem Sie eine Instanz des HTTPInput-Knotens in einen Nachrichtenfluss eingereiht haben, können Sie den Knoten konfigurieren (siehe Nachrichtenflussknoten konfigurieren). Die Eigenschaften des Knotens werden in der Ansicht 'Eigenschaften' angezeigt.

In der folgenden Tabelle werden die Terminals des HTTPInput-Knotens beschrieben.

Terminal Beschreibung
Fehlerterminal (Failure) Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn ein Fehler auftritt.
Ausgang Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn sie erfolgreich abgerufen wurde.
HTTPTimeout Das Ausgabeterminal, an das eine Fehlernachricht zur Zeitlimitüberschreitung weitergeleitet wird, wenn der HTTPReply-Knoten, der mit dem Ausgangsterminal verbunden ist, nicht innerhalb des Zeitintervalls reagiert, das durch die Eigenschaft Maximale Wartezeit für Client festgelegt ist. Dieses Terminal wird nur verwendet, wenn in der Konfiguration der Ausführungsgruppe festgelegt ist, dass HTTP-Knoten das in die Ausführungsgruppe integrierte Empfangsprogramm verwenden sollen.
Catch-Terminal Das Ausgabeterminal, an das die Nachricht geleitet wird, wenn nachgeschaltet eine Ausnahmebedingung ausgegeben und von diesem Knoten abgefangen wurde.

In den folgenden Tabellen werden die Knoteneigenschaften beschrieben. Die Spalte O zeigt an, ob die Eigenschaft obligatorisch ist (markiert mit einem Sternchen, 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 HTTPInput-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung
Knotenname Nein Nein Knotentyp, z. B. HTTPInput 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 HTTPInput-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Pfadsuffix für URL Ja Ja   Diese Eigenschaft gibt an, aus welchem Verzeichnis Web-Service-Anforderungen abgerufen werden. Geben Sie nicht die vollständige URL ein. 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. URLSpecifier
HTTPS verwenden Nein Ja Nicht ausgewählt Diese Eigenschaft gibt an, ob der Knoten sicheres HTTP akzeptiert. Wenn der Knoten sicheres HTTP akzeptieren soll, aktivieren Sie das Kontrollkästchen. useHTTPS

In der folgenden Tabelle werden die erweiterten Eigenschaften des HTTPInput-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Zieladressenliste festlegen Nein Nein Ausgewählt Gibt an, ob die Methode 'Bindungsname' zur Zieladressenliste für die Weiterleitung an Zieladressen hinzugefügt werden soll. Wird dieses Kontrollkästchen aktiviert, wird die Methode 'Bindungsname' hinzugefügt, so dass Sie einen RouteToLabel-Knoten nach dem HTTPInput-Knoten im Nachrichtenfluss verwenden können.  
Zieladressenpräfix Nein Nein Ohne Das Präfix, das bei der Weiterleitung an Zieladressen zum Methodennamen hinzugefügt wird. Fügen Sie ein Zieladressenpräfix hinzu, um Konflikte zwischen den jeweiligen Kennsatzknoten zu vermeiden, wenn Sie mehrere WebSphere Message Broker-Empfangsknoten in denselben Nachrichtenfluss aufnehmen. Das Kennsatzpräfix wird standardmäßig nicht eingefügt; der Methodenname und die Kennsatzbezeichnung sind also identisch.  
Abfragezeichenfolge syntaktisch analysieren Nein Nein False Wenn diese Eigenschaft gesetzt ist, wird jede Abfragezeichenfolge, die einer ankommenden Nachricht beigefügt ist, syntaktisch analysiert und entschlüsselt (gemäß http://tools.ietf.org/html/rfc3986). Dabei wird sie in Übereinstimmung mit den Namen und Werten in der Abfragezeichenfolge als Serie von Namen- und Wertelementen in folgenden Ordner der lokalen Umgebung eingefügt:

LocalEnvironment.HTTP.Input.QueryString

Beispiel: Bei der Abfragezeichenfolge:

?myParam1=my%22Value%221&myParam2=my%22Value%222

werden die folgenden Elemente im Ordner 'QueryString' der lokalen Umgebung eingefügt:

myParam1 mit dem Wert my"Value"1
myParam2 mit dem Wert my"Value"2

Wenn für QueryString ein Zeichensatz verwendet wird, der nicht UTF-8 entspricht, können Sie mit der Umgebungsvariablen MQSI_HTTP_QUERY_STRING_CCSID die ID des codierten Zeichensatzes (CCSID) für QueryString angeben. Beispiel: Wenn in Ihrem HTTPRequest-Knoten QueryStringCCSID auf 943 eingestellt ist, können Sie MQSI_HTTP_QUERY_STRING_CCSID auf 943 setzen, damit die Parameter für Abfragezeichenfolgen in die Codepage 943 konvertiert werden.

 
Decompress input message (Eingabenachricht dekomprimieren) Nein Ja Nicht ausgewählt

Über diese Eigenschaft wird angegeben, ob eine eingehende HTTP-Anforderung dekomprimiert wird oder nicht. Diese Eigenschaft wird nur verwendet, wenn in der Konfiguration der Ausführungsgruppe festgelegt ist, dass HTTP-Knoten das integrierte HTTP-Empfangsprogramm der Ausführungsgruppe verwenden sollen.

Wenn diese Option ausgewählt ist und im Feld 'Content-Encoding' im HTTP-Header "gzip" oder "deflate" (komprimieren) angegeben ist, wird die Eingabenachricht dekomprimiert und an das Ausgangsterminal weitergegeben, das Feld 'Content-Encoding' wird entfernt.

decompressInputMessage

In der folgenden Tabelle werden die Eigenschaften von 'Syntaxanalyse der Eingabenachricht' des HTTPInput-Knotens beschrieben.

In der folgenden Tabelle werden die Eigenschaften der Parser-Optionen für den HTTPInput-Knoten 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.
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.

Diese Eigenschaft ist standardmäßig auf Bei Bedarf gesetzt, d. h., die Syntaxanalyse der Nachricht wird verschoben. Der Abschnitt Bedarfsgerechte Syntaxanalyse enthält Informationen zur sofortigen Analyse von Nachrichten.

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 genommen 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 definieren, werden die Nachrichtendaten in Knoten, die mit dem Ausgabeterminal verbunden sind, unter XMLNSC angezeigt, wenn es sich beim MQRFH2-Eingabeheader oder bei der Eigenschaft Nachrichtendomäne unter 'Syntaxanalyse der Eingabenachricht' 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 Eingabenachricht 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 Eingabenachricht 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 Diese Eigenschaft steuert, ob der XMLNSC-Parser Elemente in der Nachrichtenbaumstruktur erstellt, wenn er Verarbeitungsanweisungen in einer Eingabenachricht feststellt. 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 Über diese Eigenschaft wird eine Liste von Elementen in der Eingabenachricht angegeben, 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 Auswerten auf Keine gesetzt ist); Einträge, die in Nicht transparente Elemente angegeben sind, werden ignoriert, wenn die Gültigkeitsprüfung aktiviert ist.

In der folgenden Tabelle werden die Fehlerhandhabungseigenschaften des HTTPInput-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Maximale Client-Wartezeit(Sekunden) Ja Ja 180 Die Zeitdauer in Sekunden, die das TCP/IP-Empfangsprogramm, welches die Eingabenachricht vom Web-Service-Client empfangen hat, auf eine Antwort des HTTPReply-Knotens im Nachrichtenfluss wartet. Der gültige Zeitraum ist null (d. h. eine kurze Wartezeit) bis (231)-1. Wenn innerhalb dieser Zeit eine Antwort eingeht, übergibt das Empfangsprogramm die Antwort an den Client. Wenn innerhalb dieser Zeit keine Antwort eingeht, wird eine Fehlernachricht erzeugt mit der Information, dass das Zeitlimit überschritten wurde. Diese Fehlernachricht wird entweder vom Empfangsprogramm gesendet oder von der Verarbeitung durch das Timeout-Terminal.

Weitere Informationen zum HTTPTimeout-Terminal finden Sie unter Verbindungen zu Terminals herstellen und Terminals und Eigenschaften.

 
Fehlerformat Nein Ja SOAP 1.1 Das Format von beliebigen HTTP-Fehlern, die an den Client zurückgegeben werden. Gültige Werte sind SOAP 1.1, SOAP 1.2 und HTML. faultFormat

In der folgenden Tabelle werden die Auswertungseigenschaften des HTTPInput-Knotens beschrieben. Wenn eine Nachricht an das Fehlerterminal des Knotens weitergegeben wird, wird sie nicht ausgewertet. Sie finden weitere Informationen hierzu in den Abschnitten Nachrichten überprüfen und 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 Keiner, Inhalt und Wert und Inhalt. 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.  

In der folgenden Tabelle werden die Eigenschaften für die Sicherheit des HTTPInput-Knotens beschrieben. Geben Sie Werte für die Eigenschaften an, die die Extraktion einer Identität aus einer Nachricht steuern, wenn dem Knoten ein Sicherheitsprofil zugeordnet ist. Weitere Informationen zu diesen Eigenschaften finden Sie in den Abschnitten Identität, Extraktion eines Identitäts- oder Sicherheitstokens konfigurieren, Übersicht über Nachrichtenflusssicherheit und Nachrichtenflusssicherheit einrichten.

Eigenschaft O K Standardwert Beschreibung
Identitätstokentyp Nein Nein Ohne Diese Eigenschaft gibt den Typ des Identitätstokens an, das in der ankommenden Nachricht vorhanden ist. Gültige Werte sind:
  • Transportstandard
  • Benutzername
  • Benutzername + Kennwort
  • SAML-Zusicherung
  • X.509-Zertifikat
Wird diese Eigenschaft nicht angegeben, wird die Identität aus den Basic-Auth-Transport-Headern abgerufen und der Typ wird auf Benutzername + Kennwort gesetzt.
Position des Identitätstokens Nein Nein Ohne Diese Eigenschaft gibt an, wo in der Nachricht sich die Identität befindet. Die Position wird als ESQL-Feldreferenz, als XPath-Ausdruck oder als Zeichenfolgeliteral angegeben. Zeichenfolgeliterale müssen in einfache Anführungszeichen gesetzt werden und dürfen keinen Punkt (.) enthalten. Wenn diese Eigenschaft nicht angegeben wird, wird die ID aus den Transportheadern 'Authorization' abgerufen.
Position des Identitätskennworts Nein Nein Ohne Diese Eigenschaft gibt an, wo in der Nachricht sich das Kennwort befindet. Die Position wird als ESQL-Feldreferenz, als XPath-Ausdruck oder als Zeichenfolgeliteral angegeben. Zeichenfolgeliterale müssen in einfache Anführungszeichen gesetzt werden und dürfen keinen Punkt (.) enthalten. Wenn Sie einen Wert für diese Eigenschaft angeben, wird die ID aus den Transportheadern 'Authorization' abgerufen. Diese Eigenschaft kann nur festgelegt werden, wenn Identitätstyp auf Benutzername + Kennwort gesetzt ist.
Identität-issuedBy-Position Nein Nein Ohne Diese Eigenschaft gibt eine Zeichenfolge oder einen Pfadausdruck an und beschreibt den Aussteller der Identität.

Die Position wird als ESQL-Feldreferenz, XPath-Ausdruck oder Zeichenfolgeliteral angegeben. Zeichenfolgeliterale müssen in einfache Anführungszeichen gesetzt werden und dürfen keinen Punkt (.) enthalten. Der Wert gibt den Aussteller an, der an einen WS-Trust v1.3 STS-Provider übergeben wird.

Wird für diese Eigenschaft kein Wert angegeben, ist der Standardwert der Name des Benutzeragenten oder (falls dieser Name nicht festgelegt wird) die Zeichenfolge HTTP.

Sicherheitsausnahmen als normale Ausnahmen behandeln Nein Nein False (falsch) Diese Eigenschaft gibt an, ob Sicherheitsausnahmen (wie z. B. "Zugriff verweigert") als normale Ausnahmebedingungen behandelt und zum Fehlerterminal weitergeleitet werden sollen (sofern verbunden). Standardmäßig ist diese Option inaktiviert; dadurch wird sichergestellt, dass die Nachricht bei Sicherheitsausnahmen zurückgesetzt wird, selbst wenn das Fehlerterminal verbunden ist.
Die Überwachungseigenschaften des Knotens werden in der folgenden Tabelle beschrieben.
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.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

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

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:19:52


ReferenzthemaReferenzthema | Version 8.0.0.5 | ac04565_