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.

SOAPAsyncRequest-Knoten

Mit dem SOAPAsyncRequest-Knoten können Sie in Verbindung mit dem SOAPAsyncResponse-Knoten ein Nachrichtenflusspaar erstellen, das einen Web-Service asynchron aufruft.

Zweck

Der SOAPAsyncRequest-Knoten kann HTTP- oder JMS-Transport verwenden. Er ist über eine eindeutige Kennung und optional über WS-Addressing zur Korrelierung der Antwortnachrichten mit der ursprünglichen Anforderung mit einem SOAPAsyncResponse-Knoten zu einem Paar verknüpft. SOAPAsyncRequest- und SOAPAsyncResponse-Knoten können nicht für unidirektionale Operationen verwendet werden.

Der SOAPAsyncRequest-Knoten sendet eine Web-Service-Anforderung, wartet jedoch nicht auf den Empfang der entsprechenden Web-Service-Antwort. Aufgrund dieser asynchronen Funktionalität können mehrere abgehende Anforderungen nahezu zeitgleich ausgeführt werden, da die abgehenden Anforderungen nicht auf eine Antwort warten müssen. Die Web-Service-Antwort wird von dem SOAPAsyncResponse-Knoten empfangen, der sich auch in einem separaten Nachrichtenfluss befinden kann. Die Knoten werden als Paar verwendet und stellen eine Korrelation zwischen den Antworten und den ursprünglichen Anforderungen her.

Der SOAPAsyncRequest-Knoten unterstützt bei Verwendung des HTTP-Transports zwei Methoden von asynchronen Anforderungen:
  1. Die Antwort wird über WS-Addressing an den paarigen SOAPAsyncResponse-Knoten geleitet. Der SOAPAsyncRequest-Knoten wartet vor der Fortsetzung des Nachrichtenflusses auf die HTTP 202-Bestätigung. Erhält der SOAPAsyncRequest-Knoten diese Bestätigung nicht, blockiert er den Nachrichtenfluss. Der Back-End-Server stellt eine neue HTTP-Verbindung her, um dem SOAPAsyncResponse-Knoten zu antworten. Dies ist das Standardverhalten.
  2. Es wird eine asynchrone HTTP-Anforderung/Antwort verwendet. Wenn die SOAPAsyncRequest-Eigenschaft Asynchrone HTTP-Anforderung/Antwort verwenden ausgewählt ist, übergibt der SOAPAsyncRequest-Knoten das HTTP-Socket an den paarigen SOAPAsyncResponse-Knoten, damit der Back-End-Server über dasselbe Socket antworten kann. Ist diese Option ausgewählt, werden WS-Addressing-Header gesendet, die jedoch nicht vom Back-End-Server verstanden werden müssen. Die WS-Addressing-Header sind nicht als 'mustUnderstand' markiert und der replyTo-Header ist auf 'anonymous' gesetzt. Der Knoten verwendet deshalb asynchrone HTTP-Socketbehandlung statt WS-Addressing, um HTTP-Anforderungen zu stellen und eine asynchrone Antwort zu empfangen.
Der Abschnitt Asynchrones Verhalten für den SOAPAsyncRequest-Knoten auswählen enthält weitere Informationen hierzu.
In dem Diagramm ist die Beziehung zwischen den SOAPAsyncRequest- und SOAPAsyncResponse-Knoten dargestellt. Eine Beschreibung hierzu finden Sie im Text.

Der SOAPAsyncRequest-Knoten ist die erste Hälfte des asynchronen Anforderungs- und Antwortknotenpaars. Der SOAPAsyncRequest-Knoten ruft einen fernen SOAP-basierten Web-Service auf. Die Anforderung wird vom SOAPAsyncRequest-Knoten gesendet, der SOAPAsyncRequest-Knoten ist nicht der Empfänger der Antwort. Die Antwort wird von einem SOAPAsyncResponse-Knoten empfangen, der auf einem anderen Thread aktiv ist. Der SOAPAsyncResponse-Knoten befindet sich in der Regel am Anfang eines anderen Nachrichtenflusses. Dieser Nachrichtenfluss muss allerdings der gleichen Ausführungsgruppe angehören wie der SOAPAsyncRequest-Knoten.

Der SOAPAsyncRequest-Knoten ist, ähnlich wie der SOAPRequest-Knoten, WSDL-gesteuert.

Der SOAPAsyncRequest-Knoten ist im Ablagefach Web-Services der Palette enthalten und wird im WebSphere Message Broker Toolkit durch folgendes Symbol dargestellt:

In der Abbildung wird ein Symbol für den Knoten 'SOAPAsyncRequest' gezeigt.

Verwendung dieses Knotens in einem Nachrichtenfluss

Ein SOAPAsyncRequest-Knoten ist mit einem SOAPAsyncResponse-Knoten zu einem Paar verknüpft, wobei die Korrelierung der Anforderungs- und Antwortnachrichten über eine eindeutige Kennung erfolgt.

Das folgende Beispiel veranschaulicht die Verwendung der asynchronen SOAP-Knoten für den Aufruf eines Web-Services. Der Web-Service simuliert einen Bestellservice und der Client zeigt, wie vorhandene WebSphere MQ-Schnittstellen erweitert werden, damit sie Web-Service-Anforderungen ausgeben können.

Informationen zu Beispielen können nur bei Verwendung des in das WebSphere Message Broker Toolkit integrierten bzw. online verfügbaren Information Center angezeigt werden. Muster können nur ausgeführt werden, wenn das im WebSphere Message Broker Toolkit integrierte Information Center verwendet wird.

WSDL mit dem SOAPAsyncRequest-Knoten verwenden

Einem SOAPAsyncRequest-Knoten muss eine WSDL-Datei zugeordnet sein, sofern er nicht im Gateway-Modus betrieben wird. Weitere Informationen zum Gateway-Modus finden Sie im Abschnitt Gateway-Betriebsmodus für SOAP-Knoten.

Wenn Sie im WSDL-Modus für das Feld Name der WSDL-Datei eine WSDL-Datei auswählen, wird die ausgewählte WSDL überprüft, um sicherzustellen, dass sie WS-I-konform ist. Wenn die WSDL eine SOAP/JMS-Transport-URI verwendet, ist sie nicht WS-I-konform, es wird jedoch standardmäßig kein Fehler angezeigt. Wenn Sie eine strenge WS-I-Prüfung aktivieren möchten und eine Warnung angezeigt werden soll, wenn ein SOAP/JMS-Transport verwendet wird, klicken Sie auf Fenster > Einstellungen > Brokerentwicklung > Nachrichtengruppen > Auswertung und heben Sie die Auswahl des Kontrollkästchens WS-I BP 1.1: SOAP/JMS als Transport-URI zulassen auf.

Nach Auswahl einer gültigen WSDL-Datei wird das Nachrichtengruppenprojekt, zu dem die WSDL-Datei gehört, dem entsprechenden Nachrichtenflussprojekt als Projekt, auf das verwiesen wird, hinzugefügt, sofern der Verweis noch nicht vorhanden ist. Bei einer ungültigen WSDL-Datei oder Eingabe eines falschen Dateinamens wird in der Eigenschaftenanzeige eine Fehlernachricht angezeigt und die WSDL-Eigenschaften bleiben leer.

Wenn der Knoten durch Übergabe einer WSDL-Datei aus einer Nachrichtengruppe an den Nachrichtenflusseditor erstellt wurde, wird diese Eigenschaft auf den Namen der WSDL-Datei voreingestellt. Wenn der Name der WSDL-Datei nicht voreingestellt ist, können Sie diese Eigenschaft auf eine der folgenden Arten festlegen.

  • Wenn Ihnen implementierbare WSDL-Dateien zur Verfügung stehen, können Sie eine dieser Dateien über die Schaltfläche Durchsuchen auswählen.
  • Wenn Ihnen zwar WSDL-Definitionen, jedoch keine Nachrichtengruppe zur Verfügung stehen, können Sie wie folgt eine Nachrichtengruppe erstellen:
    1. Klicken Sie auf Durchsuchen, um das Fenster WSDL-Auswahl zu öffnen.
    2. Klicken Sie auf Importieren/Neu erstellen, um den Assistenten WSDL-Datei importieren aufzurufen.
    3. Geben Sie den Namen und den Projektnamen der Nachrichtengruppe ein. Klicken Sie auf Weiter.
    4. Wählen Sie eine der folgenden Optionen aus:
      • Wenn die WSDL-Datei im Arbeitsbereich vorhanden ist, wählen Sie Ressourcen aus dem Arbeitsbereich verwenden und danach die WSDL-Datei aus.
      • Wenn die WSDL-Datei im lokalen Dateisystem abgelegt ist, wählen Sie Externe Ressourcen verwenden und danach die WSDL-Datei aus. Klicken Sie auf Weiter.
    5. Wählen Sie die zu importierenden WSDL-Bindungen aus. Beim Import ausgegebene Warnungen und Fehlernachrichten werden im Assistentenbanner angezeigt.
    6. Klicken Sie auf Finish (Fertigstellen). Ein neues Nachrichtengruppenprojekt wird erstellt. Dieses enthält bereits eine Nachrichtengruppe mit Nachrichtendefinitionen. Die WSDL-Definitionen werden dem Ordner mit den implementierbaren WSDL-Dateien hinzugefügt.
    7. Nun können Sie die WSDL-Datei im Fenster WSDL-Auswahl auswählen. Klicken Sie auf OK.
  • Wenn Ihnen eine Nachrichtengruppe zur Verfügung steht, jedoch keine WSDL-Definition, müssen Sie eine WSDL-Definition generieren. Weitere Informationen hierzu finden Sie unter Nachrichtengruppen: WSDL-Definition aus einer Nachrichtengruppe generieren.
  • Ziehen Sie eine WSDL-Datei aus einer Nachrichtengruppe per Drag-and-Drop auf den Knoten.
  • Geben Sie einen Dateinamen relativ zu dem Nachrichtengruppenprojekt ein, in dem sich die implementierbare WSDL-Datei befindet.
Beim Speichern der Nachrichtenflussdatei wird geprüft, ob in der Nachrichtengruppe der Name der WSDL-Datei angegeben ist. Ist dies nicht der Fall, wird ein Fehler generiert. Es ist dann nicht möglich, der Brokerarchivdatei (BAR-Datei) einen Nachrichtenfluss mit diesem SOAPAsyncRequest-Knoten hinzuzufügen.

Terminals und Eigenschaften

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

Terminal Beschreibung
Eingangsterminal (In) Das Eingabeterminal, das eine SOAP-Anforderungsnachricht zur Verteilung an das Ziel durch den Knoten annimmt.
Fehlerterminal (Failure) Das Ausgabeterminal, an das die Nachricht weitergeleitet wird, wenn bei der Verteilung der SOAP-Anforderungsnachricht an das Ziel ein Fehler erkannt wird (z. B. bei der Gültigkeitsprüfung einer Nachricht).
Ausgang Das Ausgabeterminal, an das die Nachricht weitergeleitet wird, wenn sie erfolgreich an das Ziel verteilt wurde und falls in diesem Nachrichtenfluss eine weitere Verarbeitung erforderlich ist. Die Nachricht, die das Ausgangsterminal verlässt, ist identisch mit der Nachricht, die am Eingabeterminal ankommt.

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 für die Implementierung zur BAR-Datei hinzugefügt wird).

Einige Eigenschaften des SOAPAsyncRequest-Knotens werden anfänglich durch Eigenschaften der importierten WSDL festgelegt. Diese Eigenschaften werden je nach URI-Format des address-Elements der WSDL auf verschiedene Weisen syntaktisch analysiert. Ausführliche Informationen hierzu finden Sie unter WSDL-URI-Formate für JMS.

In der folgenden Tabelle werden die Beschreibungseigenschaften des SOAPAsyncRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung
Knotenname Nein Nein Knotentyp Der Name des Knotens.
Kurzbeschreibung Nein Nein Ohne Kurze Beschreibung des Knotens.
Langbeschreibung Nein Nein Ohne Text, der den Zweck des Knotens im Nachrichtenfluss beschreibt.

In der folgenden Tabelle werden die grundlegenden Eigenschaften des SOAPAsyncRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Eindeutige ID Ja Nein   Diese Eigenschaft ist die eindeutige Kennung, durch die einSOAPAsyncRequest- und ein SOAPAsyncResponse-Knoten verknüpft werden.

Beim HTTP-Transport wird diese Kennung als eindeutiges URL-Fragment zur Kennzeichnung eingehender Antwortnachrichten für den SOAPAsyncResponse-Knoten verwendet.

Beim JMS-Transport wird diese eindeutige Kennung nur verwendet, wenn die Eigenschaft Abruf nach Korrelations-ID aktiviert ist. Wenn die Eigenschaft Abruf nach Korrelations-ID trotz JMS-Transport inaktiviert ist, fungiert stattdessen die Warteschlange Zieladresse für Antworten als eindeutige Kennung; diese muss daher für dieses Knotenpaar eindeutig sein.

asyncResponseCorrelator
Betriebsmodus Ja Ja Einen bestimmten über eine WSDL-Schnittstelle definierten Web-Service aufrufen

Mit dieser Eigenschaft können Sie den Betriebsmodus des Knotens angegeben, der bestimmt, ob er im WSDL-Modus oder im Gateway-Modus agiert. Im WSDL-Modus führt der Knoten Operationen entsprechend der WSDL-Datei durch, mit der er konfiguriert ist. Mit dem Gateway-Modus können Sie Ihren Nachrichtenfluss jedoch so konfigurieren, dass er generische SOAP-Anforderungs-/Antwortnachrichten und unidirektionale Nachrichten verarbeitet oder als Fassade zwischen mehreren Web-Service-Clients und mehreren Back-End-Web-Service-Providern fungiert.

Einen bestimmten über eine WSDL-Schnittstelle definierten Web-Service aufrufen
Konfigurieren Sie den Knoten mit einer implementierbaren WSDL-Datei, indem Sie die Eigenschaft 'Name der WSDL-Datei' festlegen oder eine WSDL-Datei auf den Knoten ziehen. Dies ist die Standardoption.
Generischen Web-Service aufrufen
Konfigurieren Sie den Knoten so, dass der im Gateway-Modus agiert, ohne dass eine WSDL-Datei erforderlich ist. Eine ausführlichere Erläuterung des Gateway-Modus finden Sie im Abschnitt Gateway-Betriebsmodus für SOAP-Knoten.
 
Name der WSDL-Datei Ja Nein Ohne

Diese Eigenschaft gibt die Position der WSDL-Datei an, die zum Konfigurieren des Knotens verwendet werden soll. Geben Sie den vollständigen Pfad der WSDL-Datei ein oder klicken Sie auf Durchsuchen, um in Ihrem Arbeitsbereich nach der WSDL-Datei zu suchen.

Wenn Sie für die Eigenschaft Name der WSDL-Datei eine WSDL-Datei auswählen, wird die ausgewählte WSDL überprüft, um sicherzustellen, dass sie WS-I-konform ist. Wenn die WSDL eine SOAP/JMS-Bindung enthält, die nicht mit WS-I konform ist, wird standardmäßig kein Fehler angezeigt. Wenn Sie eine strenge WS-I-Prüfung aktivieren möchten und eine Warnung angezeigt werden soll, wenn ein SOAP/JMS-Transport verwendet wird, klicken Sie auf Fenster > Einstellungen > Brokerentwicklung > Nachrichtengruppen > Auswertung und heben Sie die Auswahl des Kontrollkästchens WS-I BP 1.1: SOAP/JMS als Transport-URI zulassen auf.

Zur Konfiguration der SOAP-Knoten können nur implementierbare WSDL-Dateien verwendet werden. Nach Auswahl einer gültigen WSDL-Datei wird das Nachrichtengruppenprojekt, zu dem die WSDL-Datei gehört, als referenziertes Projekt der entsprechenden Anwendung oder Bibliothek hinzugefügt, sofern der Verweis nicht vorhanden ist.

Bei einer ungültigen WSDL-Datei oder Eingabe eines falschen Dateinamens wird in der Eigenschaftenanzeige eine Fehlernachricht angezeigt und die WSDL-Eigenschaften bleiben leer.

Wenn der Knoten durch Übergabe einer WSDL-Datei aus einer Nachrichtengruppe an den Nachrichtenflusseditor erstellt wurde, wird diese Eigenschaft auf den Namen der WSDL-Datei voreingestellt.

Für diese Eigenschaft muss ein Zeichenfolgewert angegeben werden.

Folgende Situationen führen zu einer Fehlerbedingung:

WSDL-Eigenschaften werden inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

 
Porttyp Ja Nein Standardmäßig wird der erste in der WSDL-Datei gefundene Porttyp ausgewählt, dem eine HTTP- oder JMS-Bindung zugeordnet ist.

Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. In diesem Feld sind alle in der angegebenen WSDL-Datei definierten Porttypen aufgelistet. Standardmäßig wird der erste in der WSDL-Datei gefundene Porttyp ausgewählt, dem eine HTTP- bzw. JMS-Bindung zugeordnet ist.

Beim Speichern der Nachrichtenflussdatei wird geprüft, ob der ausgewählte Porttyp innerhalb des Inhalts der ausgewählten WSDL-Datei gültig ist. Ist dies nicht der Fall, wird ein Fehler generiert. Es ist dann nicht möglich, der Brokerarchivdatei (BAR-Datei) einen Nachrichtenfluss mit diesem SOAPAsyncRequest-Knoten hinzuzufügen.

Fehlerbedingungen:
  • Der ausgewählte Porttyp enthält nicht mindestens eine Operation.

WSDL-Eigenschaften werden inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

 
Importierte Bindung Ja Nein   Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. Im Feld Importierte Bindung werden alle dem ausgewählten Porttyp zugeordneten SOAP-Bindungen aufgeführt. Nur der HTTP- oder JMS-Transport wird unterstützt. Die Bindungen sind in derselben Reihenfolge aufgelistet, in der sie in der WSDL-Datei definiert sind. Standardmäßig wird die erste Bindung ausgewählt, die die jeweilige Operation implementiert und der ein Service-Port zugeordnet ist. Diese Eigenschaft wird bei jeder Änderung des Porttyp-Werts aktualisiert.
Fehlerbedingungen:
  • Dem Porttyp in der WSDL-Datei sind keine SOAP-Bindungen (mit HTTP- oder JMS-Transport) zugeordnet.
  • Die ausgewählte Bindung verfügt über keine Operationen.

WSDL-Eigenschaften werden inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

 
Bindungsoperation Ja Nein   Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge.

Das Feld Bindungsoperation enthält alle durch die ausgewählte Bindung definierten Operationen. Die erste Operation auf der Liste wird standardmäßig ausgewählt. Diese Eigenschaft wird bei jeder Änderung des Bindungswerts aktualisiert.

Beim Speichern der Nachrichtenflussdatei wird geprüft, ob die ausgewählte Bindungsoperation innerhalb des Inhalts der ausgewählten WSDL-Datei gültig ist. Ist dies nicht der Fall, wird ein Fehler generiert. Es ist dann nicht möglich, der Brokerarchivdatei (BAR-Datei) einen Nachrichtenfluss mit diesem SOAPAsyncRequest-Knoten hinzuzufügen.

WSDL-Eigenschaften werden inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

 
Service-Port Ja Nein   Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. Im Feld Service-Port werden alle Service-Ports aufgelistet, die auf die ausgewählte Bindung verweisen. Standardmäßig ist der erste Service-Port der Bindung ausgewählt. Diese Eigenschaft wird bei jeder Änderung des Bindungswerts aktualisiert.

Beim Speichern der Nachrichtenflussdatei wird geprüft, ob der ausgewählte Service-Port innerhalb des Inhalts der ausgewählten WSDL-Datei gültig ist. Ist dies nicht der Fall, wird ein Fehler generiert. Es ist dann nicht möglich, der Brokerarchivdatei (BAR-Datei) einen Nachrichtenfluss mit diesem SOAPAsyncRequest-Knoten hinzuzufügen.

Fehlerbedingungen:
  • Es gibt keine Ports, die auf die ausgewählte Bindung verweisen.

WSDL-Eigenschaften werden inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

 
Zielnamespace Nein Nein   Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. Im Feld Zielnamespace wird der Namespace der ausgewählten WSDL-Datei angezeigt.

WSDL-Eigenschaften werden inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

 
Transport Nein Nein HTTP Diese Eigenschaft wird bei Auswahl der Eigenschaft Importierte Bindung automatisch festgelegt. Der Wert dieser Eigenschaft gibt den von der ausgewählten WSDL-Bindung verwendeten Transport an; Beispiel: HTTP oder JMS.

Wenn Sie den Transport von JMS in HTTP ändern, wird ein Dialogfenster angezeigt, in dem Sie die JMS-spezifischen Eigenschaften zurücksetzen können. Sie müssen die JMS-Eigenschaften zurücksetzen, um den Nachrichtenfluss in einer Version der Laufzeitumgebung vor Fixpack V7.0.0.1 zu implementieren.

 

In der folgenden Tabelle werden die HTTP-Transporteigenschaften des SOAPAsyncRequest-Knotens beschrieben. Diese Einstellungen werden nur verwendet, wenn der Knoten den HTTP-Transport verwendet.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Web-Service-URL Ja Nein   Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. Diese Eigenschaft wird automatisch aus dem <soap:address>-Element des ausgewählten Service-Ports abgeleitet. Bei einer Änderung des ausgewählten Ports wird die Web-Service-URL entsprechend angepasst. Wenn Sie den Wert jedoch manuell überschreiben, bleibt der von Ihnen festgelegte Wert erhalten und die URL wird nicht mehr dem Service-Port angepasst.
Der Wert muss, wenn Sie ihn manuell angeben, folgendes Format haben: http://<Hostname>[:<Port>]/[<Pfad>]. Dabei gilt Folgendes:
  • http://<Hostname> muss angegeben werden.
  • Der Standardwert für <Port> ist '80'. Wenn Sie einen Wert angeben, müssen Sie vor der Portnummer einen Doppelpunkt (:) einfügen.
  • Der Standardwert für <Pfad> ist ein Schrägstrich (/). Wenn Sie einen Wert angeben, müssen Sie vor dem Pfad einen Schrägstrich (/) eingeben.

Sie finden ausführliche Informationen zur Überschreibung dieser Eigenschaft im Abschnitt Standard-URL für einen SOAPRequest-Knoten oder eine Anforderung des SOAPAsyncRequest-Knotens ändern.

webServiceURL
Anforderungszeitlimit (in Sekunden) Nein Ja 120 Bei diesem Eigenschaftentyp handelt es sich um eine ganze Zahl. Diese Eigenschaft enthält den Wert der Wartezeit, die verstreicht, bis der ferne Server mit einer Nachrichtenempfangsbestätigung antwortet.

Wenn Sie die Eigenschaft Use async socket (Asynchrones Socket verwenden) auswählen, verweist der Wert von Zeitlimit für Anforderung stattdessen auf den Wert der Wartezeit für den fernen Server, um eine Antwort an den SOAPAsyncResponse-Knoten zu senden.

Die Zeit in Sekunden, die der Knoten auf eine Antwort vom Web-Service wartet. Der gültige Bereich liegt zwischen 1 und (231)-1. Werte, die eine unbegrenzte Wartedauer angeben, sind nicht zulässig.

requestTimeout
HTTP(S)-Proxyadresse Nein Ja   Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. Die Adresse des Proxy-Server, an den Anforderungen gesendet werden. Dieser Wert muss das Format Hostname:Port haben. httpProxyLocation
SSL-Protokoll (bei Verwendung von SSL) Nein Ja TLS Bei diesem Eigenschaftentyp handelt es sich um eine Aufzählung. SSL-Protokoll bei der Erstellung einer HTTPS-Anforderung. Gültige Werte sind:
SSL
Bei dieser Option wird zuerst versucht, die Verbindung über das SSLv3-Protokoll herzustellen. Der Handshake kann jedoch auf das SSLv2-Protokoll zurückzugreifen, das von dem zugrunde liegenden JSSE-Provider unterstützt wird.
SSLv3
Bei dieser Option wird nur versucht, die Verbindung über das SSLv3-Protokoll herzustellen. Der Handshake kann nicht auf SSLv2 zurückgreifen.
TLS
Der Standardwert. Bei dieser Option wird nur versucht, die Verbindung über das TLS-Protokoll herzustellen. Der Handshake kann nicht auf SSLv3 oder SSLv2 zurückgreifen.

Beide Seiten einer SSL-Verbindung müssen dasselbe Protokoll verwenden. Der ferne Server muss das Protokoll akzeptieren können.

sslProtocol
Erlaubte SSL-Verschlüsselungen (bei Verwendung von SSL) Nein Ja Leer Bei diesem Eigenschaftentyp handelt es sich um eine Zeichenfolge. Eine durch Kommas getrennte Liste von Verschlüsselungen, die bei der Erstellung einer SSL-Anforderung verwendet wird. Diese Einstellung ermöglicht es Ihnen, einen einzelnen Chiffrierwert (z. B. SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) oder eine Liste von Chiffrierwerten anzugeben, die als die einzigen Chiffrierwerte für diese Verbindung verwendet werden. In dieser Liste von Chiffrierwerten muss dabei mindestens ein Chiffrierwert vorhanden sein, der vom fernen Server akzeptiert wird. Der Standardwert ist eine leere Zeichenfolge. Er erlaubt es dem Knoten, während des SSL-Verbindungs-Handshakes einen beliebigen oder alle verfügbaren Chiffrierwerte zu verwenden. Dadurch steht der größtmögliche Bereich für die Herstellung einer erfolgreichen SSL-Verbindung zur Verfügung. allowedSSLCiphers
Use compression (Komprimierung verwenden) Nein Nein Ohne Diese Eigenschaft bestimmt, ob der Inhalt der HTTP-Anforderung komprimiert wird. Gültige Werte sind "Keine", "gzip", "zlib (deflate)" (zlib (komprimiert)) und "deflate" (komprimiert). Wenn die Anforderung komprimiert wird, wird der Content-Encoding-Header gesetzt. Dieser weist darauf hin, dass der Inhalt komprimiert ist.

In "zlib (deflate)" (zlib (komprimiert)) sind RFC 1950 + RFC 1951 zusammengefasst.

"deflate" (komprimiert) umfasst nur RFC 1951.

requestCompressionType
Accept compressed responses by default (Standardmäßig komprimierte Antworten akzeptieren) Nein Ja Nicht ausgewählt Diese Eigenschaft bestimmt, ob auf die Anforderung komprimierte Antworten akzeptiert werden. Wenn diese Option ausgewählt ist, kann die Anforderung auch Antworten mit der Inhaltscodierung "gzip" oder "deflate" (komprimiert) empfangen. Beim Empfang einer solchen Antwort wird der Inhalt entschlüsselt und der Content-Encoding-Header entfernt.

Wenn der Anforderungsheader noch keinen Accept-Encoding-Header enthält, wird der Accept-Encoding-Header durch Auswahl dieser Option auf "gzip, deflate" (gzip, komprimiert) gesetzt.

acceptCompressedResponses
Enable SSL certificate hostname checking (Hostnamenprüfung für SSL-Zertifikat aktivieren) Nein Ja Nein Diese Eigenschaft gibt an, ob der Hostname des Servers, der die Anforderung empfängt, mit dem Hostnamen im SSL-Zertifikat übereinstimmen muss. hostnameChecking
Asynchrone HTTP-Anforderung/Antwort verwenden Nein Nein Nicht ausgewählt Die Festlegung dieser Eigenschaft bedeutet, das der SOAPAsyncRequest-Knoten das HTTP-Socket an den paarigen SOAPAsyncResponse-Knoten übergibt, damit der Back-End-Server über dasselbe Socket antworten kann.

Über diese Eigenschaft wird der Knoten so konfiguriert, dass er asynchrone HTTP-Anforderung/Antwort statt asynchrones WS-Addressing verwendet. Wenn Asynchrone HTTP-Anforderung/Antwort ausgewählt ist, sind die WS-Addressing-Header nicht als 'mustUnderstand' markiert und ist der replyTo-Header auf 'anonymous' gesetzt.

Wählen Sie diese Option aus, wenn der Back-End-Server keine abgehenden Anforderungen auf einer neuen Verbindung stellen kann.

Der Abschnitt Asynchrones Verhalten für den SOAPAsyncRequest-Knoten auswählen enthält weitere Informationen hierzu.

 
Schlüsselaliasname für die SSL-Clientauthentifizierung Nein Ja "" (leere Zeichenfolge) Diese Eigenschaft legt den SSL-Authentifizierungsalias für die Clientseite einer SOAPAsyncRequest-Verbindung fest. Bei der Standardeinstellung wird automatisch der erste geeignete Schlüssel ausgewählt. keyAlias

In der folgenden Tabelle werden die JMS-Transporteigenschaften des SOAPAsyncRequest-Knotens beschrieben. Diese Einstellungen werden nur verwendet, wenn der Knoten den JMS-Transport verwendet.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Zieladresse Ja Ja Ohne Das Ziel, an das der Knoten abgehende Nachrichten sendet. Wenn der SOAPAsyncRequest-Knoten zum Senden von Punkt-zu-Punkt-Nachrichten verwendet werden soll, geben Sie als JMS-Warteschlangenname den Namen der Zielwarteschlange ein, der in der JMS-Bindungsdatei aufgelistet ist.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob die URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM® Format definiert ist. Bei einer W3C-URI wird Ziel auf den Wert von destinationName der WSDL gesetzt, bei einer IBM URI auf den Wert von destination.

jmsDestination
Zieladresse für Antworten Ja Ja Ohne Der Name der JMS-Zieladresse, an die die empfangende Anwendung eine Antwortnachricht senden muss. Der JMS-Bestimmungsname muss der Domäne des vom empfangenden Client verwendeten JMS-Providers bekannt sein, damit eine Antwortnachricht an diese JMS-Zieladresse zurückgegeben werden kann.

Wenn die Option Abruf nach Korrelations-ID inaktiviert ist, kennzeichnet diese Warteschlange die für den verknüpften SOAPAsyncResponse-Knoten bestimmten Nachrichten eindeutig. Wenn die Option Abruf nach Korrelations-ID aktiviert ist, kann diese Warteschlange auch gemeinsam für mehrere Knoten verwendet werden.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob die URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM Format definiert ist. Bei einer W3C-URI wird Zieladresse für Antworten auf den Wert von replyToName der WSDL gesetzt, bei einer IBM URI auf den Wert von replyToName, replyTo, replyToDestination oder replyDestination (je nachdem, welcher Wert zuerst vorkommt). Wenn irgendwelche dieser anderen Eigenschaften vorhanden sind, werden sie in der Tabelle Benutzerparameter als Name-/Wert-Paar angezeigt.

jmsReplyToDestination
Name des JMS-Providers Ja Nein WebSphere MQ Wählen Sie in der Liste den Namen eines JMS-Anbieters aus, oder geben Sie einen Namen ein. Der Name muss dem Namen eines konfigurierbaren Service entsprechen, der für den Broker, für den Sie den Nachrichtenfluss implementieren, definiert ist.

Wenn Sie in der Liste einen Namen auswählen, wird die Eigenschaft Ausgangskontextfactory automatisch mit der entsprechenden Java™-Klasse aktualisiert. Wenn Sie einen eigenen JMS-Providernamen eingeben, müssen Sie auch einen Wert für die Ausgangskontextfactory eingeben.

 
Ausgangskontextfactory Ja Ja com.sun.jndi.fscontext. RefFSContextFactory Der Ausgangspunkt für einen JNDI-Namespace.

Eine JMS-Anwendung verwendet den Ausgangskontext, um die Verbindungsfactory sowie Warteschlangen oder Themenobjekte für den JMS-Provider abzurufen und zu suchen. Wenn Sie in der Liste unter Name des JMS-Providers den Namen eines JMS-Providers auswählen, wird die Eigenschaft Ausgangskontextfactory automatisch mit der entsprechenden Java-Klasse aktualisiert. Wenn Sie einen eigenen JMS-Providernamen eingeben, müssen Sie auch einen Wert für die Ausgangskontextfactory eingeben. Der Standardwert lautet com.sun.jndi.fscontext.RefFSContextFactory. Mit diesem Wert wird die dateibasierte Ausgangskontextfactory für den JMS-Provider von WebSphere MQ definiert.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob die URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM Format definiert ist. Bei einer W3C-URI wird Ausgangskontextfactory auf den Wert von jndiInitialContextFactory der WSDL gesetzt, bei einer IBM URI auf den Wert von initialContextFactory.

initialContextFactory
Position der JNDI-URL-Bindungen Ja Ja   Der Systempfad oder die LDAP-Position für die Bindungsdatei. Die Bindungsdatei enthält Definitionen für die verwalteten JNDI-Objekte, die vom SOAPAsyncRequest-Knoten verwendet werden.

Wenn für die Ausgangskontextfactory der Wert com.ibm.mq.jms.Nojndi angegeben ist, ist diese Eigenschaft inaktiviert.

Bei der Eingabe eines Werts für die Eigenschaft Position der JNDI-URL-Bindungen sind folgende Anweisungen einzuhalten:
  • Erstellen Sie die Bindungsdatei vor der Implementierung eines Nachrichtenflusses, der einen SOAPAsyncRequest-Knoten enthält.
  • Geben Sie in diesem Feld nicht den Dateinamen der Bindungsdatei ein.
  • Wenn Sie eine LDAP-Adresse angegeben haben, für die eine Authentifizierung erforderlich ist, konfigurieren Sie den LDAP-Principal (Benutzer-ID) und die LDAP-Berechtigungsnachweise (Kennwort) separat. Diese Werte werden auf Brokerebene konfiguriert. Informationen zur Konfiguration dieser Werte finden Sie in den Abschnitten Befehl mqsicreatebroker und Befehl mqsichangebroker.
  • Der Zeichenfolgewert muss ein unterstütztes URL-Präfix einschließen, das einen im Klassenpfad verfügbaren URL-Handler enthält.

Informationen zum Erstellen der Bindungsdatei für verwaltete JNDI-Objekte finden Sie in der Dokumentation des JMS-Providers.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob die URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM Format definiert ist. Bei einer W3C-URI wird Position der JNDI-URL-Bindungen auf den Wert von jndiURL der WSDL gesetzt, bei einer IBM URI auf den Wert von jndiProviderURL.

locationJndiBindings
Verbindungsfactory-Name Ja Ja   Der Name der Verbindungsfactory, der vom SOAPAsyncRequest-Knoten für die Erstellung einer Verbindung zum JMS-Provider verwendet wird. Diese Eigenschaft wird ursprünglich durch die importierte WSDL konfiguriert. Dieser Name muss in der Bindungsdatei bereits vorhanden sein. Für Verbindungsfactory-Name muss ein JMS-QueueConnectionFactory-Name angegeben sein.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob die URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM Format definiert ist. Bei einem W3C-URI wird Verbindungsfactory-Name auf den Wert von jndiConnectionFactoryName der WSDL gesetzt, bei einem IBM URI auf den Wert von connectionFactory.

connectionFactoryName
Benutzerparameter Nein Nein   In der nachfolgenden Tabelle werden Benutzereigenschaften beschrieben, die in der Eigenschaft requestURI (Anforderungs-URI) der abgehenden Anforderungsnachricht gesendet werden. Die Eigenschaften sind Name/Wert-Paare, die in WSDL vorhanden sind, und nicht durch andere Eigenschaften des SOAPAsyncRequest-Knotens verwendet werden.  
JNDI-Parameter Nein Nein   Diese Tabelle ordnet JNDI-Kontextparameter ihrem Typ zu.

Diese Eigenschaften erhalten ihre Anfangswerte von den WSDL-Eigenschaften im W3C-Format, beginnend mit jndi-. JNDI-Parameter werden von WSDL im IBM Format nicht unterstützt, die betreffenden Eigenschaften können jedoch auf dem Knoten festgelegt werden.

 
Abruf nach Korrelations-ID Nein Ja Nicht ausgewählt Wenn diese Eigenschaft aktiviert ist, sendet der SOAPAsyncRequest-Knoten die Anforderungsnachricht mit der in der Eigenschaft Eindeutige ID angegebenen Korrelations-ID und der SOAPAsyncResponse-Knoten empfängt nur Antwortnachrichten, die diese Korrelations-ID enthalten. Bei dieser Einstellung kann die gleiche Zieladresse für Antworten-Warteschlange gemeinsam für mehrere SOAPAsyncRequest- und SOAPAsyncResponse-Knotenpaare verwendet werden, sofern diese Eigenschaft für alle betroffenen Knoten aktiviert ist.

Diese Zuordnung funktioniert allerdings nur bei Web-Service-Providern, die das Auslesen der Korrelations-ID aus der Anforderungsnachricht und deren Verwendung als Korrelations-ID in der Antwortnachricht unterstützen.

 
Rücksetzziel Nein Ja  

Wenn der Nachrichtenfluss Antwortnachrichten aufgrund von Fehlern nicht verarbeiten kann, sendet der SOAPAsyncResponse-Knoten die Antwortnachrichten an dieses Ziel. Die Nachricht wird dabei aus der Warteschlange 'Zieladresse für Antworten' entfernt.

Die Rücksetzeigenschaften werden vom SOAPAsyncRequest-Knoten festgelegt, werden jedoch nur von dem SOAPAsyncResponse-Knoten verwendet, mit dem er paarweise verbunden ist.

backoutDestination
Rücksetzschwellenwert Nein Ja 0

Dieser Wert legt fest, wann eine Nachricht in das Rücksetzziel gestellt wird. Wenn der Wert beispielsweise 3 lautet, versucht der JMS-Provider drei Mal, die Nachricht an die Eingabezieladresse zuzustellen. Nach dem dritten Zustellungsversuch wird die Nachricht nicht auf die Zieladresse für Antworten zurückgesetzt und wird an das Rücksetzziel gesendet.

Die Rücksetzeigenschaften werden vom SOAPAsyncRequest-Knoten festgelegt, werden jedoch nur von dem SOAPAsyncResponse-Knoten verwendet, mit dem er paarweise verbunden ist.

Weitere Informationen hierzu finden Sie unter Eigenschaft 'Rücksetzschwellenwert' konfigurieren.

 

In der folgenden Tabelle werden die Nachrichtenzustellungseigenschaften des SOAPAsyncRequest-Knotens beschrieben. Diese untergeordnete Registerkarte ist nur aktiviert, wenn die ausgewählte Bindung auf der Registerkarte 'Grundeinstellung' den JMS-Transport verwendet.

Eigenschaft O K Standardwert Beschreibung Eigenschaft des Befehls mqsiapplybaroverride
Zielservice Nein Nein Ohne Dieser Service wird vom SOAPAsyncRequest-Knoten beim Versenden der Serviceanforderung verwendet.

Diese Eigenschaft erhält ihren Anfangswert aus der WSDL-Eigenschaft targetService.

targetService
Zustellmodus Nein Ja Persistent Durch diese Eigenschaft wird der Permanenzmodus gesteuert, den ein JMS-Provider für eine Nachricht verwendet. Folgendes sind gültige Werte:
  • Permanent: Die Nachricht bleibt auch bei einem Systemausfall des JMS-Providers erhalten.
  • Nicht permanent: Die Nachricht geht bei einem Systemausfall des JMS-Providers verloren.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob der URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM Format definiert ist. Bei einer W3C-URI wird Zustellmodus auf den Wert von deliveryMode der WSDL gesetzt, bei einer IBM URI auf den Wert von deliveryMode oder persistence (je nachdem, welcher Wert zuerst vorkommt). Wenn beide Eigenschaften vorhanden sind, wird die zweite Eigenschaft in der Tabelle Benutzerparameter als Name-/Wert-Paar angezeigt.

deliveryMode
Nachrichtenpriorität Nein Ja 4

Diese Eigenschaft weist der Nachricht eine relative Bedeutung zu und kann von einem empfangenden Web-Service zur Nachrichtenauswahl verwendet werden.

Wählen Sie einen Wert zwischen 0 (niedrigste Priorität) und 9 (höchste Priorität) aus. Der Standardwert lautet 4, was einer mittleren Priorität entspricht. Bei Prioritäten im Bereich 0 - 4 handelt es sich um eine normale Zustellung. Bei Prioritäten im Bereich 5 - 9 erfolgt die Zustellung schneller.

Diese Eigenschaft übernimmt ihren Anfangswert aus einer WSDL-URI-Eigenschaft. Welcher Wert verwendet wird, ist abhängig davon, ob die URI im WSDL-Element address im W3C-Standardformat oder im proprietären IBM Format definiert ist. Bei einer W3C-URI wird Priorität auf den Wert von priority der WSDL gesetzt, bei einer IBM URI auf den Wert von priority oder Priority (je nachdem, welcher Wert zuerst vorkommt). Wenn beide Eigenschaften vorhanden sind, wird die zweite Eigenschaft in der Tabelle Benutzerparameter als Name-/Wert-Paar angezeigt.

messagePriority
Verfall der Nachricht (ms) Nein Ja 0 Diese Eigenschaft gibt (in Millisekunden) die Zeitdauer an, für die der JMS-Provider die JMS-Ausgabenachricht aufbewahrt. Mit dem Standardwert 0 wird angegeben, dass die Nachricht nicht ablaufen darf.

Diese Eigenschaft erhält ihren Anfangswert aus der WSDL-EigenschafttimeToLive.

messageExpiration
Nachrichtenart Nein Ja Byte Wählen Sie in der Liste einen Wert aus, um den Typ der JMS-Nachricht zu konfigurieren, der vom SOAPAsyncRequest-Knoten erstellt wird. Gültige Werte sind Text und Byte. messageType

In der folgenden Tabelle werden die Transaktionseigenschaften des SOAPAsyncRequest-Knotens beschrieben. Diese Einstellung gilt nicht, wenn der Knoten den HTTP-Transport verwendet.

Eigenschaft O K Standardwert Beschreibung
Transaktionsmodus Ja Nein Automatisch

Durch diese Eigenschaft wird gesteuert, ob die Nachricht unter einer JMS-Transaktion ausgegeben wird. Gültige Werte sind Ja, Nein und Automatisch.

Wählen Sie Nein aus, um die Nachricht mit einer nicht transaktionsorientierten JMS-Sitzung auszugeben.

Wählen Sie Ja aus, um die Nachricht mit einer transaktionsorientierten JMS-Sitzung zu auszugeben. Die JMS-Transaktion kann entweder lokal oder XA-koordiniert sein. Um eine XA-koordinierte Transaktion mit einer XA-JMS-Sitzung verwenden zu können, müssen Sie in den Eigenschaften der BAR-Datei auch die Nachrichtenflusseigenschaft Koordinierte Transaktion auswählen.

Wählen Sie Automatisch aus, wenn die Transaktionalität der Nachricht am Anfang des Nachrichtenflusses aus der Einstellung der Eigenschaft Transaktionsmodus des Empfangsknoten übernommen werden soll.

Weitere Informationen hierzu finden Sie unter Koordinierte JMS-Transaktionen konfigurieren.

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

SOAP-Header, die in der Liste must understand headers (Muss Header verstehen) enthalten sind, werden dem Nachrichtenfluss hinzugefügt und verursachen keinen SOAP-Fehler. Das Hinzufügen von Headern zur Liste must understand headers (Muss Header verstehen) ist somit ein wirkungsvolles Mittel, um durch SOAP-Header verursachte SOAP-Fehler zu verhindern.

Für WS-Addressing und WS-Sicherheit brauchen Sie der Liste must understand headers (Muss Header verstehen) keine Header hinzuzufügen, weil diese ohnehin erkannt werden, wenn Sie WS-Erweiterungen konfigurieren.

Die in diesem Knoten konfigurierte Eigenschaft must understand headers (Muss Header verstehen) wird auf den entsprechenden SOAPAsyncResponse-Knoten angewendet, wenn der SOAPAsyncResponse-Knoten die Antwort vom fernen Server empfängt.

Eigenschaft O K Standardwert Beschreibung
WSDL-definierte SOAP-Antwortheader Nein Nein   Die Tabelle WSDL-definierte SOAP-Antwortheader ist schreibgeschützt und wird auf der Grundlage der SOAP-Header ausgefüllt, die in dem Ausgabeteil der ausgewählten Operationen definiert sind. Standardmäßig ist die Auswahl der Kontrollkästchen in der zweiten Tabellenspalte für alle Einträge der Tabelle WSDL-definierte SOAP-Antwortheader zurückgenommen. Sie müssen die Kontrollkästchen der Header, die Sie der Liste must understand headers (Muss Header verstehen) hinzufügen möchten, also explizit aktivieren.

Wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert und keine WSDL-Datei erforderlich ist, wird diese Tabelle gelöscht. Die ursprünglichen Werte dieser Felder werden wiederhergestellt, wenn der Betriebsmodus des Knotens wieder in WSDL-Modus geändert wird.

Benutzerdefinierte SOAP-Antwortheader Nein Nein   Sie können benutzerdefinierte Header (Header, die nicht in der WSDL-Datei definiert sind) zur Tabelle Benutzerdefinierte SOAP-Header hinzufügen. In dieser Tabelle können Sie Zeilen hinzufügen, bearbeiten und löschen. In der zweiten Tabellenspalte muss das betreffende Kontrollkästchen markiert werden, damit der neu hinzugefügte angepasste Header tatsächlich der Liste must understand headers (Muss Header verstehen) hinzugefügt wird.

In der folgenden Tabelle werden die WS-Erweiterungseigenschaften des SOAPAsyncRequest-Knotens beschrieben.

Eigenschaft O K Standardwert Beschreibung  
WS-Adressierung verwenden Nein Nein Ausgewählt Diese Eigenschaft kann nicht bearbeitet werden. Mit dieser Eigenschaft geben Sie an, dass das WS-Addressing für den SOAPAsyncRequest-Knoten immer aktiviert ist.

Sie finden ausführliche Informationen zum WS-Addressing beim SOAPAsyncRequest-Knoten im Abschnitt WS-Adressierung mit den Knoten SOAPAsyncRequest und SOAPAsyncResponse.

 
MTOM ermöglichen Nein Ja Nein Über diese Eigenschaft wird gesteuert, ob MTOM für den Parser aktiviert ist. Gültige Werte sind Ja, Nein und Übernehmen.

Im Abschnitt SOAP MTOM in Verbindung mit den SOAPReply-, SOAPRequest- und SOAPAsyncRequest-Knoten verwenden finden Sie weitere Informationen zur Verwendung von SOAP MTOM mit den SOAPReply-, SOAPRequest- und SOAPAsyncRequest-Knoten. Weitere Informationen zu MTOM finden Sie unter SOAP MTOM.

Die MTOM-Unterstützung wird inaktiviert, wenn der Knoten so konfiguriert wird, dass er im Gateway-Modus agiert.

allowMTOM
WS-Security Nein Nein   Diese Tabelle enthält zwei Spalten:
  • Aliasname
  • XPath-Ausdruck
Sie können der Tabelle WS-Sicherheit XPath-Ausdrücke mit zugehörigen Alias-Werten hinzufügen. Der Aliasname ist in einem durch den Administrator erstellten Richtliniensatz aufgelöst. Der Richtliniensatz löst den Aliasnamen auf, um den Teil der Nachricht, auf den sich der XPath-Ausdruck bezieht, entweder zu verschlüsseln oder zu signieren. In dieser Tabelle können Sie die Optionen Hinzufügen, Bearbeiten und Löschen verwenden.
 
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.

LocalEnvironment-Überschreibungen

In der lokalen Umgebung können Sie festgelegte Werte auf die gleiche Weise wie bei anderen Elementen einer Nachricht dynamisch überschreiben. Eine vollständige Liste der Werte, die Sie in der lokalen Umgebung überschreiben können, finden Sie unter Überschreibungen in der lokalen Umgebung.

Mit WrittenDestination-Daten arbeiten

Sobald eine Anforderung gestellt ist, wird der WrittenDestination-Ordner in der lokalen Umgebung mit der WS-Addressing, den Komprimierungsdetails (falls verwendet) und den Transportdetails aktualisiert. Ein WrittenDestination-Eintrag für einen SOAPAsyncRequest-Knoten hat das folgende Format, wobei die WS-Addessing- und Komprimierungsdetails nur angegeben sind, wenn diese Funktionen genutzt werden:
WrittenDestination = (
   SOAP  = (
      Request = (
         WSA = (
            To = 'URI'
            ReplyTo = 'http://server:7800/reply'
            MessageID = 'id'
            Action = 'doAllTheStuff'
         )
         Transport = (
            HTTP = (
               WebServiceURL = 'http://server:8080/service'
               Compression   = (
                  OriginalSize   = 775
                  CompressedSize = 411
            )
         )
      )
   )
)
Im folgenden Beispiel wird der JMS-Transport verwendet:
WrittenDestination = (
   SOAP  = (
      Request = (
         WSA = (
            To = 'URI'
            ReplyTo = 'http://server:7800/reply'
            MessageID = 'id'
            Action = 'doAllTheStuff'
         )
         Transport = (
            JMS = (
               Destination = 'jms:jndi:B2BQUEUEIN'
            )
         )
      )
   )
)
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

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

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


ReferenzthemaReferenzthema | Version 8.0.0.5 | ac56200_