This topic provides hints to help you resolve problems you experience when using the Web services gateway.
Before you begin
For information on resolving WebSphere-level problems, see Diagnosing and fixing problems.
For current information available from IBM Support on known problems and their resolution, see the IBM Support page.
IBM Support has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, see the IBM Support "must gather" page.
If you report a gateway-related problem to IBM Service
and Support, include the gateway release and build information that is listed
under the About option of the Web
services gateway administrative user interface.
Why and when to perform this task
To help you identify and resolve gateway-related problems, use the WebSphere Application Server trace and logging facilities. To enable trace for the gateway, set the application server trace string to com.ibm.wsgw.*=all=enabled. If you encounter a problem that you think might be related to the gateway, you can check for error messages in the WebSphere Application Server administrative console, and in the application server stdout.log file. You can also enable the application server debug trace to provide a detailed exception dump.
The gateway administrative user interface uses cascading style sheets to lay out its pages, and Javascript to monitor progress and to advise you as you fill in each on-screen form. Your Web browser must therefore support Javascript and cascading style sheets, and it must be configured so that Javascript and style sheets are enabled. This configuration depends on which browser you use. For example for Netscape, you select Edit > Preferences, click Advanced in the Category pane, then confirm that the Enable Javascript and Enable style sheets check boxes are selected.
A list of the gateway run-time system messages, with details of what each message means, is provided in Web services gateway messages.
Here is a checklist of common problems:
When you complete the installation of an upgraded gateway, any previously configured gateway is replaced with an upgraded but empty gateway. To preserve an existing gateway configuration, you need to save the configuration before you upgrade the gateway, then restore the configuration after the upgrade is installed. For detailed instructions see Preserving an existing gateway configuration.
Check that your client is using the version of the soap.jar file that is supplied in the WebSphere Application Server /AppServer/lib/app directory. If you enable trace, you can look in the trace for the request <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
The gateway expects the 2001 version of the XML schema. Older versions of the soap.jar file (including 2.2) generate 1999 schema. If you have the soap.jar file that is supplied with WebSphere Application Server in the client class path, you can see 2001 schema in the request.
This mismatch can occur if you remove and reinstall the Apache SOAP channel applications. If this operation is necessary, then either verify that all corresponding channels configured with the Web services gateway are removed, or remove and reinstall the Web services gateway at the same time.
Note: The Web services gateway application (wsgw.ear) must be installed before the channel and filter applications. If the gateway application needs to be reinstalled, all channels and filters must be uninstalled first, then reinstalled after the gateway application.
If you receive a SOAP fault message with a faultstring that is just the value of one of the parameters of the invocation, that means the parameter value is not valid. For example if you have a service that expects an int parameter and you send it a message containing the value "1.1", then the fault message you receive contains 1.1 as the fault string:
<faultcode>SOAP-ENV:Client</faultcode> <faultstring>1.1</faultstring>
This message is consistent with Apache SOAP behavior, and is not correctable by the gateway.
If you receive a SOAP fault message containing an element that is not present in the WSDL for the target service, then the error message thrown can be difficult to identify. There are two possible scenarios:
[Attributes={}] [faultCode=SOAP-ENV:Server] [faultString=com.ibm.wsgw.WSGWException: WSGW0043E: Exception while executing operation createEntry service ExchangeService. Exception: org.apache.wsif.WSIFException: SOAPException: SOAP-ENV:ClientNo mapping found for 'com.ibm.jrom.JROMValue' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.; nested exception is: [SOAPException: faultCode=SOAP-ENV:Client; msg=No mapping found for 'com.ibm.jrom.JROMValue' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.; targetException=java.lang.IllegalArgumentException: No mapping found for 'com.ibm.jrom.JROMValue' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.]] [faultActorURI=/wsgwsoap1/soaprpcrouter] ...
[Attributes={}] [faultCode=null] [faultString=null] [faultActorURI=null] [DetailEntries=] [FaultEntries=]
These messages are consistent with Apache SOAP behavior, and are not correctable by the gateway.
WSGW0009E: Failed to deploy service. Exception: Error change service properties: com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC0105E: LoginConfig: AuthMethod Signature is not valid.This problem only occurs when you set Identification to Digital Signature. The problem is caused by a mismatch between the request bindings and the response bindings. For example, you might have set Request Sender signing information on the request bindings instead of Request Receiver, or Response Receiver on the response bindings instead of Response Sender. To fix the problem, set matching request and response bindings. For instructions on setting these parameters, see
[10/23/03 12:31:40:393 CDT] 78a54799 enterprise I com.ibm.ws.webservices.engine.enterprise TRAS0014I: The following exception was logged WebServicesFault faultCode: {http://schemas.xmlsoap.org/ws/2003/06/secext}InvalidSecurityToken faultString: WSEC5085E: Unable to build a valid CertPath: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: java.security.cert.CertPathValidatorException: The certificate issued by CN=Int CA2, OU=TRL, O=IBM, ST=Kanagawa, C=JP is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error
This problem occurs when one of the defined certificate stores on the Web services gateway administrative client is missing the certificate path.
To correct this problem,
X509 Certificate Path: /usr/WebSphere/AppServer/etc/ws-security/samples/intca2.cer
[10/3/03 21:35:48:597 CDT] 33c558 enterprise I com.ibm.ws.webservices.engine.enterprise TRAS0014I: The following exception was logged WebServicesFault faultCode: {http://schemas.xmlsoap.org/ws/2003/06/secext}FailedAuthentication faultString: WSEC5078E: Login failed: javax.security.auth.login.LoginException: java.lang.NullPointerException at com.ibm.wsspi.wssecurity.auth.module.WSSecurityMappingModule._login(WSSecur ityMappingModule.java:152)
The problem occurs when the Web services gateway does not enable global security and there is no LDAP user registry information to authenticate the incoming user login.
To correct this problem, enable global security on the Web services gateway application server using the same LDAP user registry that the deployment manager uses. See Enabling gateway-level authentication for more information.
Note: Before enabling global security on the Web services gateway, you need to uninstall the Web services gateway channels and applications, then re-install them after security is enabled.
WSEC5078E: Login failed: com.ibm.websphere.security.auth.WSLoginFailedException: AuthenLoginModule: Authentication failed reason = 2
This problem occurs when single sign-on is enabled and the same password is used on both the deployment manager and the Web services gateway application server. The login fails even though the deployment manager and the Web services gateway application server are both enabled with security, with the same LDAP user registry and with the same LTPA password. The problem occurs because the key that is generated and passed between the services is randomly generated, and is therefore different for each server even though the same password is used.
To correct this problem, export the key from one cell then import it into another.
Check that you entered, in the "EJB References" for the authorization session bean, the correct JNDI name of the imported Web service enterprise bean. Note that this home is case sensitive.
The Web services gateway can invoke Web services that include https:// in their addresses, if the Java and WebSphere security properties are configured accordingly. To check your security property settings, see the topic Invoking Web services over HTTPS
A number of tasks are required to disable security. Clearing the check box for 'Authorization Policy - Control access to this service' still leaves WebSphere Application Server security in place, so basic authentication might still be required.
To disable security fully, use the WebSphere Application Server administrative console Security Center to disable Global Security.
The SOAP message format must be Remote Procedure
Call (RPC) style. The gateway does not support Document style SOAP messages.
If you are using the Apache SOAP channel, then the
SOAP message format must be RPC style. To handle Document style SOAP messages,
use the SOAP over HTTP channel (which supports both RPC style and Document
style SOAP messages).
The gateway does not support SOAP messages
with attachments.
To handle SOAP messages with attachments, use the SOAP over HTTP
channel.
You need to do one of two things to support Web services that use complex types in the Web services gateway:
For more information on the factors to consider when choosing between these options, see Data type representation - Choosing between Generic classes and Deployed Java classes.
Note:
If your Web service contains complex
types, and it is deployed to Axis 1.0, and you used the Axis tools to generate
the WSDL file, then remove the following line in the WSDL schema definition:
<import namespace="any_namespace_name">