Tipps zur Fehlerbehebung beim Web-Service-Gateway
Dieser Artikel enthält spezifische Tipps für die Fehlerbehebung beim Web-Service-Gateway.
Verwenden Sie zum Identifizieren und Beheben von Problemen, die sich auf das Web-Service-Gateway
beziehen,
die Trace- und Protokollierungsfunktionen von WebSphere Application Server gemäß der Beschreibung im Artikel
Komponententrace (CTRACE) konfigurieren.
Wenn Sie den Trace für das Gateway aktivieren möchten, setzen Sie die Tracezeichenfolge des Anwendungsservers auf com.ibm.ws.sib.webservices.*=all=enabled. Wenn ein Fehler auftritt, den Sie für einen Gateway-Fehler halten, können Sie in der Administrationskonsole von WebSphere Application Server WebSphere Application Server und in der Datei SystemOut.log des Anwendungsservers prüfen, ob Fehlernachrichten vorhanden sind.Sie können auch den Debug-Trace des Anwendungsservers aktivieren, um einen ausführlichen Ausnahmespeicherauszug zu erhalten.
Das Web-Service-Gateway wird als Verwaltungsschicht über SIB-fähige Web-Services implementiert. Deshalb sind die meisten bekannten Probleme, die bei der Verwendung des Gateways auftreten, eigentlich Probleme, die sich auf busfähige Web-Services beziehen. Diese Probleme sind im Artikel Tipps zur Fehlerbehebung in busfähigen Web-Services beschrieben.
Systemnachrichten von WebSphere Application Server werden von vielen Quellen, einschließlich Komponenten und Anwendungen des Anwendungsservers, protokolliert. Nachrichten, die von Komponenten des Anwendungsservers sowie zugeordneten IBM Produkten protokolliert werden, beginnen mit einer eindeutigen Nachrichten-ID, die die Komponente oder Anwendung anzeigt, welche die Nachricht ausgegeben hat. Das Präfix für Web-Service-Gateways ist CWWSG und das Präfix für die busfähige Web-Services ist CWSWS.
Der Artikel Referenz zur Fehlerbehebung: Nachrichten enthält Informationen zu den Nachrichten der Gateways und busfähigen Web-Services, indexiert nach Nachrichtenpräfix. Zu jeder Nachricht werden eine Erläuterung des Problems und Einzelheiten zu den Aktionen bereitgestellt, die Sie ausführen können, um das Problem zu beheben.
- Wenn Sie Nachrichten direkt an ein Busziel übergeben, interagiert die RPC-codierte Web-Service-Standardnachricht (Zeichenfolgebereich) mit einigen Ziel-Service-Providern nicht ordnungsgemäß.
- Eine Web-Service-Nachricht vom Typ SOAP over JMS wird von Web-Service-Gateway als JmsBytesMessage und nicht als JmsTextMessage gesendet.
- Wenn Sie einen Gateway-Service erstellen, wird die zugehörige WSDL-Beschreibung erst dann im SDO-Repository erstellt, wenn Sie versuchen, über einen Web-Browser auf die WSDL-Datei des Gateway-Service zuzugreifen.
- Sie migrieren ein Gateway von WebSphere Application Server Version 5.1 auf eine höhere Version.
- Sie legen fest, dass an Stelle des Gateway-Service ein Web-Service-Client aus der WSDL für den Zielservice generiert werden soll.
- Sie migrieren ein Gateway, das Filter enthält, von WebSphere Application Server Version 5.1 auf eine höhere Version und Ihre Filter funktionieren nicht mehr.
- Sie migrieren ein Gateway, das Filter aus WebSphere Application Server Version 5.1 enthält, auf Version 7.0 oder höher und es werden Ziele mit auf "StorageQueue" endenden Namen erstellt.
- Sie haben eine Clientanwendung, die in WebSphere Application Server Version 5.1 funktioniert, aber in höheren Versionen treten Probleme aufgrund nicht korrekt formatierter Anforderungen oder Antworten auf.
- Ein JAX-RPC-Client, der in WebSphere Application Server Version 5.1 ausgeführt wird, verwendet SOAP over JMS, um einen Web-Service aufzurufen, der in einem Anwendungsserver der Version 5.1 ausgeführt wird
- Die Gateway-Anzeigen in der Administrationskonsole sind in WebSphere Application Server Network Deployment nur verfügbar
Wenn Sie Nachrichten direkt an ein Busziel übergeben, interagiert die RPC-codierte Web-Service-Standardnachricht (Zeichenfolgebereich) mit einigen Ziel-Service-Providern nicht ordnungsgemäß.
- Die generierte RPC-codierte Web-Service-Standardnachricht (Zeichenfolgebereich) interagiert mit einigen Ziel-Service-Providern nicht ordnungsgemäß.
- Die erzeugte Zeichenfolgenachricht entspricht der entsprechenden JAX-RPC-Standardnachricht, die erfolgreich verwendet werden kann, nicht exakt.
- Nachricht des Service Integration Bus:
<partname env:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/ xsi:type='ns1:ArrayOf_xsd_string'> <item xsi:type='xsd:anySimpleType'>namevalue</item> </partname>
- JAX-RPC-Clientnachricht:
<partname xsi:type="soapenc:Array" soapenc:arrayType="xsd:string[1]"> <item>namevalue</item> </partname>
- Starten Sie die Administrationskonsole.
- Navigieren Sie zu und klicken Sie anschließend auf Neu.
- Erstellen Sie die folgende angepasste JVM-Eigenschaft.
Bei den angezeigten Werten muss die Groß-/Kleinschreibung muss beachtet werden.
- Name: com.ibm.websphere.sib.webservices.useTypeSoapArray
- Wert: true
- Starten Sie den Anwendungsserver erneut.
Eine Web-Service-Nachricht vom Typ SOAP over JMS wird von Web-Service-Gateway als JmsBytesMessage und nicht als JmsTextMessage gesendet.
Standardmäßig wird eine Web-Service-Nachricht vom Typ "SOAP over JMS" in WebSphere Application Server Version 6 oder höher vom Web-Service-Gateway als JmsBytesMessage gesendet, während das Web-Service-Gateway die Nachricht in WebSphere Application Server Version 5.1 als JmsTextMessage sendet.
- Starten Sie die Administrationskonsole.
- Navigieren Sie zu und klicken Sie anschließend auf Neu.
- Erstellen Sie die folgende angepasste JVM-Eigenschaft.
Bei den angezeigten Werten muss die Groß-/Kleinschreibung muss beachtet werden.
- Name: com.ibm.ws.sib.webservices.useSOAPJMSTextMessages
- Wert: true
- Starten Sie den Anwendungsserver erneut.
Wenn Sie einen Gateway-Service erstellen, wird die zugehörige WSDL-Beschreibung erst dann im SDO-Repository erstellt, wenn Sie versuchen, über einen Web-Browser auf die WSDL-Datei des Gateway-Service zuzugreifen.
Jeder Gateway-Service hat einen zugeordneten Service für eingehende Daten. Die WSDL-Datei des Gateway-Service ist diesem Service für eingehende Daten zugeordnet und sollte nur benötigt werden, wenn die Nachricht von einem Service für eingehende Daten stammt. Deshalb wird die WSDL-Beschreibung erst dann im SDO-Repository erstellt, wenn sie von eine Service für eingehende Daten oder über einen Web-Browser aufgerufen wird.
Wenn Ihre Anwendungen Nachrichten aus anderen Quellen als dem Service für eingehende Daten bereitstellen (z. B. bei der Verwendung von Mediationshandlern für die Bearbeitung von SDO-Nachrichten an einen oder von einem Gateway-Service), müssen die Anwendungen entweder die dem Zielservice (für abgehende Daten) zugeordnete WSDL oder eine andere kompatible WSDL verwenden.
Sie migrieren ein Gateway von WebSphere Application Server Version 5.1 auf eine höhere Version.
Wenn das Gateway der Version 5 eine WSDL für einen Gateway-Service generiert, enthält der generierte Namespace den Servicenamen. Beispiel: namespace="http://griddev:9080/wsgw#ihrService". In höheren Versionen enthält die für einen Gateway-Service generierte WSDL jedoch keinen Servicenamen. Beispiel: namespace="http://griddev:9080/wsgw".
Wenn Sie als WSDL-Bindungs- und -Codierungsstil "document-literal" verwenden, funktionieren Ihre Clients trotzdem mit dem migrierten Gateway, weil der Stil "document-literal" das Attribut namespace nicht verwendet. Wenn Sie jedoch die WSDL des Gateway-Service der Version 5.1 verwendet haben, um Ihre Web-Service-Clients zu generieren, und Ihre WSDL-Bindung und die Codierungsdarstellung nicht "document-literal" ist, müssen Sie nach der Migration die Client-Stubs mit der WSDL des neuen Gateway-Service erneut generieren.
Sie legen fest, dass an Stelle des Gateway-Service ein Web-Service-Client aus der WSDL für den Zielservice generiert werden soll.
Das Generieren eines Web-Service-Client aus der WSDL für den Zielservice hat den Vorteil, dass Sie auswählen können, ob Sie den Zielservice direkt oder über den Gateway aufrufen, indem Sie lediglich den URL in den generierten Stubs ändern. Sie können diesen Ansatz in dieser Version des Gateway aktivieren, indem Sie in der Administrationskonsole die angepasste Eigenschaft com.ibm.websphere.wsgw.mapSoapBodyNamespace für jeden Service für eingehende Daten, der dem Gateway-Service zugeordnet ist, auf false setzen.
- Wenn Sie die die Flexibilität der Umleitung von Nachrichten durch Änderung des URL in den generierten Stubs weiterhin nutzen möchten, setzen Sie die angepasste Eigenschaft com.ibm.websphere.wsgw.mapSoapBodyNamespace auf false.
- Wenn Sie diese Flexibilität nicht mehr benötigen, generieren Sie die Client-Stubs mit der WSDL des Gateway-Service der höheren Version erneut.
Sie migrieren ein Gateway, das Filter enthält, von WebSphere Application Server Version 5.1 auf eine höhere Version und Ihre Filter funktionieren nicht mehr.
Die Verwendung von Filtern ist seit Version 5.1.1 veraltet, und die Unterstützung für Filter wurde in Version 7 nicht weiter bereitgestellt. Die Rolle, die die Filter früher hatten, wird jetzt von JAX-RPC-Handlern und SIB-Mediations übernommen. Wenn Sie ein Web-Service-Gateway migrieren, das einen Routing-Filter enthält, können Sie die Filterfunktionen neu erstellen.
Sie migrieren ein Gateway, das Filter aus WebSphere Application Server Version 5.1 enthält, auf Version 7.0 oder höher und es werden Ziele mit auf "StorageQueue" endenden Namen erstellt.
Diese zusätzlichen Ziele sind für die Unterstützung vorhandener Gateway-Filter der Version 5.1 in einer Umgebung der Version 6 erforderlich. Gateway-Filter werden nicht mehr unterstützt und deshalb sind diese "StorageQueue"-Ziele in Version 7.0 oder höher nicht mehr erforderlich. Sie werden jedoch nicht automatisch entfernt, wenn Sie eine Migration auf Version 7.0 oder höher durchführen oder wenn Sie die Gateway-Instanz löschen.
- Wenn Sie den Parameter -Q (Name der Korrelationswarteschlange für gemeinsamen Filter) angegeben haben, wurde ein einzelnes Ziel vom Typ "Warteschlange" des angegebenen Namens erstellt (sofern sie noch nicht vorhanden war) und von allen Gateway-Services mit zugeordneten Filtern gemeinsam genutzt.
- Wenn Sie den Parameter -Q nicht angegeben haben, wurde für jeden Gateway-Service mit zugeordneten Filtern ein gesondertes Ziel vom Typ "Warteschlange" erstellt. Die Namen dieser Ziele sind vom Namen der zugehörigen Anforderungs- und Antwortzielen des Gateway-Service abgeleitet und enden mit StorageQueue.
Nachdem Sie die Gateway-Instanz gelöscht haben, geben Sie jedes zugeordnete StorageQueue-Ziel mit Namen an und löschen Sie, wie im Artikel Busziel ohne Topicbereich löschen beschrieben.
Sie haben eine Clientanwendung, die in WebSphere Application Server Version 5.1 funktioniert, aber in höheren Versionen treten Probleme aufgrund nicht korrekt formatierter Anforderungen oder Antworten auf.
Busfähige Web-Services prüfen die Gültigkeit von Web-Service-Nachrichten gründlicher, als es in WebSphere Application Server Version 5.1 der Fall ist. Deshalb werden einige Clientanwendungen, die nicht korrekt formatierte Anforderungen oder Antworten verwenden (in denen die Nachrichtenabschnitte falsch benannt sind) und in Version 5.1 funktionieren, in höheren Versionen als nicht korrekt formatiert eingestuft. Die Schritte, die zur Behebung dieses Problems ausgeführt werden müssen, sind im Artikel Duldung nicht korrekt formatierter SOAP-Nachrichten beschrieben.
Ein JAX-RPC-Client, der in WebSphere Application Server Version 5.1 ausgeführt wird, verwendet SOAP over JMS, um einen Web-Service aufzurufen, der in einem Anwendungsserver der Version 5.1 ausgeführt wird
Ein JAX-RPC-Client, der in WebSphere Application Server Version 5.1 ausgeführt wird, verwendet SOAP over JMS, um einen Web-Service aufzurufen, der in einem Anwendungsserver der Version 5.1 ausgeführt wirdFür die MQ-Series-Zielwarteschlange sind weder Benutzer-ID noch Kennwort erforderlich. Wenn Sie nach der Migration des Anwendungsservers auf eine höhere Version das Standard-Messaging verwenden möchten, schlagen Clientanforderungen fehl, weil die Basisauthentifizierung jetzt aktiviert ist.
SibMessage W [:] CWSIT0009W: Der Versuch eines Clients, eine Verbindung zum Bus <Busname>
herzustellen, ist im Bootstrap-Server mit dem Endpunkt <Endpunktname> fehlgeschlagen. Ursache: CWSIT0016E:
Die Benutzer-ID null konnte in Bus Ihr_Bus nicht authentifiziert werden.
Informationen zur Behebung dieses Problems finden Sie im folgenden Fehlerbehebungstipp zu den Serviceintegrationstechnologien: Anwendungsserver der Version 5.1 auf WebSphere Application Server Version 7.0 oder höher migrieren
Die Gateway-Anzeigen in der Administrationskonsole sind in WebSphere Application Server Network Deployment nur verfügbar
![[IBM i]](../images/iseries.gif)
![[IBM i]](../images/iseries.gif)
![[IBM i]](../images/iseries.gif)
- Mit Jython:
wsgwAttribs = [] wsgwAttribs.append(["name", wsgwName]) wsgwAttribs.append(["wsdlServiceNamespace", wsgwNamespace]) wsgw = AdminConfig.create("WSGWInstance", bus, wsgwAttribs ) wsgwWsdlAttribs = [] wsgwWsdlAttribs.append(["WSDLLocation", wsgwWsdlLocation]) AdminConfig.create("SIBWSWSDLLocation", wsgw, wsgwWsdlAttribs, "defaultProxyWSDLLocation" )
- Mit Jacl:
set wsgwAttribs {} lappend wsgwAttribs [list "Name" $wsgwName] lappend wsgwAttribs [list "Namespace_des_WSDL-Service" $wsgwNamespace] set wsgw [$AdminConfig create "WSGW-Instanz" $bus $wsgwAttribs] set wsgwWsdlAttribs {} lappend wsgwWsdlAttribs [list "WSDL-Position" $wsgwWsdlLocation] $AdminConfig create "SIBWSWSDLLocation" $wsgw $wsgwWsdlAttribs "defaultProxyWSDLLocation"