Mit dem SOAPAsyncRequest-Knoten können Sie in Verbindung mit dem SOAPAsyncResponse-Knoten ein Nachrichtenflusspaar erstellen, das einen Web-Service asynchron aufruft.
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 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:
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.
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.
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 WS-I BP 1.1: SOAP/JMS als Transport-URI zulassen auf. und heben Sie die Auswahl des Kontrollkästchens
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.
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.
|
|
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 WS-I BP 1.1: SOAP/JMS als Transport-URI zulassen auf. und heben Sie die Auswahl des Kontrollkästchens 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:
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:
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:
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:
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:
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:
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:
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:
|
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. |
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.
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
)
)
)
)
)
WrittenDestination = (
SOAP = (
Request = (
WSA = (
To = 'URI'
ReplyTo = 'http://server:7800/reply'
MessageID = 'id'
Action = 'doAllTheStuff'
)
Transport = (
JMS = (
Destination = 'jms:jndi:B2BQUEUEIN'
)
)
)
)
)