Tipps zur Fehlerbehebung beim Web-Service-Gateway

Dieser Artikel enthält spezifische Tipps für die Fehlerbehebung beim Web-Service-Gateway.

[z/OS]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.

Die folgenden Tipps unterstützen Sie bei der Behebung häufig auftretender Probleme:

Wenn Sie Nachrichten direkt an ein Busziel übergeben, interagiert die RPC-codierte Web-Service-Standardnachricht (Zeichenfolgebereich) mit einigen Ziel-Service-Providern nicht ordnungsgemäß.

Sie können Nachrichten direkt an ein Busziel übergeben, indem Sie den Bindungsnamespace und die Endpunktadresse des JAX-RPC-Clients überschreiben. Es gilt jedoch Folgendes:
  • 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.
Im Folgenden finden Sie Beispiele für die Unterschiede zwischen den beiden Nachrichten:
  • 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>
Wenn Sie das Standardverhalten zum Senden einer Nachricht (Zeichenfolgebereich), die mit dem JAX-RPC-Standard vollständig kompatibel ist, ändern möchten, setzen Sie die folgende angepasste JVM-Eigenschaft. Wenn Sie diese Eigenschaft setzen, wird das Standardverhalten für alle abgehenden JMS-Web-Service-Aufrufe des Busses geändert:
  1. Starten Sie die Administrationskonsole.
  2. Navigieren Sie zu Server -> Servertypen -> WebSphere-Anwendungsserver -> Servername -> [Serverinfrastruktur] Java- und Prozessverwaltung -> Prozessdefinition > [Weitere Eigenschaften] Java Virtual Machine -> [Weitere Eigenschaften] Angepasste Eigenschaften und klicken Sie anschließend auf Neu.
  3. 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
  4. 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.

Wenn Sie das Standardverhalten zum Senden einer kompatiblen JmsTextMessage ändern möchten, setzen Sie die folgende angepasste JVM-Eigenschaft. Wenn Sie diese Eigenschaft setzen, wird das Standardverhalten für alle abgehenden JMS-Web-Service-Aufrufe des Busses geändert:
  1. Starten Sie die Administrationskonsole.
  2. Navigieren Sie zu Server -> Servertypen -> WebSphere-Anwendungsserver -> Servername -> [Serverinfrastruktur] Java- und Prozessverwaltung -> Prozessdefinition > [Weitere Eigenschaften] Java Virtual Machine -> [Weitere Eigenschaften] Angepasste Eigenschaften und klicken Sie anschließend auf Neu.
  3. 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
  4. 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.

Anmerkung: Dieser Ansatz wird in WebSphere Application Server Version 5.1 standardmäßig nicht als möglicher Fehler ausgewiesen, sodass Sie dieses Problem unter Umständen erst erkennen, wenn Sie eine Gateway-Konfiguration von einem Anwendungsserver der Version 5.1 auf die Gateway-Funktionalität eines Anwendungsservers einer höheren Version migrieren. Nach der Migration haben Sie zwei Möglichkeiten:
  • 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.

Während der Migration auf Version 6 wurden diese zusätzlichen Ziele auf eine der folgenden beiden Arten erstellt:
  • 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.

Der Fehler wird als Protokollnachricht aufgezeichnet:
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

Wenn Sie mit einem eigenständigen Serverprofil von WebSphere Application Server Network Deployment arbeiten, sind die Anzeigen nicht verfügbar. Die wsadmin-Befehlsscripts, die eine äquivalente Funktionalität über das Tool wsadmin bereitstellen, sind jedoch für beide Profiltypen - eigenständige Profile und Deployment-Manager-Profile - verfügbar. Die Verwaltungsbefehle für das Gateway decken mit Ausnahme der Erstellung einer neuen Gateway-Instanz alle Hauptanforderungen ab. Für das Erstellen einer Gateway-Instanz und der zugehörigen Positionsinformationen für die Standard-Proxy-WSDL führen Sie den Scripting-Client wsadmin mit Jacl aus.
[IBM i]Anmerkung: [IBM i]Der Scripting-Client wsadmin wird über die Qshell ausgeführt. [IBM i]Weitere Informationen finden Sie unter Qshell für die Ausführung von WebSphere-Scripts mit wsadmin-Scripting konfigurieren.
Im Folgenden sehen Sie ein Beispielscript:
  • 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"
In diesem Beispiel steht bus bzw. $bus für die ID des Service Integration Bus, in dem die Gateway-Instanz erstellt wird. Weitere Informationen zum Objekt AdminConfig von WebSphere Application Server erhalten Sie, wenn Sie "AdminConfig.help()" in der wsadmin-Befehlszeile eingeben.

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwsg_prob0
Dateiname:rwsg_prob0.html