Bus-enabled web services troubleshooting tips
Use this set of specific tips to help troubleshoot problems you experience with service integration bus-enabled web services.
To help you identify and resolve bus-enabled web services problems, use the WAS trace and logging facilities as described in Set up component trace (CTRACE).
To enable trace for bus-enabled web services, set the application server trace string to com.ibm.ws.sib.webservices.*=all=enabled. If we encounter a problem that you think might be related to bus-enabled web services, we can check for error messages in the WAS administrative console, and in the application server SystemOut.log file. We can also enable the application server debug trace to provide a detailed exception dump.
A list of the main known restrictions that apply when using bus-enabled web services is provided in Bus-enabled web services: Known restrictions.
WebSphere Application Server system messages are logged from a variety of sources, including application server components and applications. Messages logged by application server components and associated IBM products start with a unique message identifier that indicates the component or application that issued the message. The prefix for the bus-enabled web services component is CWSWS.
The topic Messages contains information about all WebSphere Application Server messages, indexed by message prefix. For each message there is an explanation of the problem, and details of any action that we can take to resolve the problem.
Security tips:
- Bus-enabled web services are unable to connect to a secure service integration bus
- Error when JAX-RPC client running on WebSphere Application Server Version 5.1 uses SOAP over JMS to invoke a web service
- WSDL must be retrieved though command line if bus needs to pass messages through an authenticating proxy server to retrieve WSDL documents
- Malformed URLException error when trying to send a SOAP over HTTPS message
- Error returned when installing the sibwsauthbean.ear file
Non-security tips:
- The service integration bus times out while an outbound service is waiting for the response from a target service
- A bus-enabled web services application or resource needs to be installed manually
- Client application works under WebSphere Application Server Version 5.1, but problems in later versions
- Error message when attempting to create an Informix database for use with the SDO repository
- Inbound service published to a UDDI registry is not listed and republish is unsuccessful
- Use JMS to connect to a remote bus requires extra configuration to allow web service clients to connect to the bus
- Out-of-memory error in the Java virtual machine when passing a large attachment through the service integration bus
- Error when trying to create a new endpoint listener configuration using the administrative console
- Error trying to create a new inbound service through the administrative console
- Problems with handling SOAP messages with attachments
- JNDI lookup errors when JMS resources on different machines have the same names
- Precise problem cannot be determined from SOAP fault messages
- Listener port timeout errors when large messages are passed using the SOAP over JMS endpoint listener
Bus-enabled web services are unable to connect to a secure service integration bus
When the bus-enabled web services component cannot connect to a secure bus, the following error message is issued during the server start (in the application server SystemOut.log file) when the service integration resource adapter attempts to connect to the bus destination:
CWSIV0801E: The exception javax.resource.ResourceException: CWSIV0958E: The authorization exception com.ibm.wsspi.sib.core.exception.SINotAuthorizedException: CWSIP0302E: A user HostServer is not authorized to access the messaging engine xyzNode01.server1-xyz on bus xyz. was thrown while attempting to create a connection to messaging engine 221C86B845BE5E8B using the activation specification [<activation_specification_field_trace>]. was thrown during the creation of a connection to messaging engine xyzNode01.server1-xyz on bus xyz.By default, the bus-enabled web services component can connect to a secure bus destination through the service integration resource adapter. Therefore the configuration must have been changed in some way.
The default configuration that the bus-enabled web services component uses to access a secure bus is as follows:
- Access to a bus is configured through the bus connector role. By default, every bus connector role includes a group called server. Members of this group are authorized to connect to the bus.
- The service integration resource adapter uses a J2C activation specification to communicate with the bus. By default, this activation specification has a Boolean custom property useServerSubject set to true. Allow the service integration resource adapter to connect to the bus as a subject (a member) of the server group.
We can override this default configuration by defining an authentication alias that the service integration resource adapter uses to access the bus. For more information, see Overriding the default security configuration between bus-enabled web services and a secure bus.
For detailed information about the default configuration, and the effect of modifying or overriding this configuration, see Bus-enabled web services default configuration for accessing a secure bus.
To help you narrow down the problem area, set the application server trace string to com.ibm.ws.sib.webservices.*=all=enabled because there are several components that can be the cause of the problem. In the trace, check SibRaMessagingEngineConnection.createConnection():
- The phrase Creating connection with Userid and password indicates that the system has found, and is attempting to use, an authentication alias configured for the J2C activation specification.
- The phrase No userid/password passed. Creating connection using server subject indicates that the system has found, and is attempting to use, the server subject.
The service integration bus times out while an outbound service is waiting for the response from a target service
The following error can occur in the service integration bus when an outbound service is waiting for a response from a target web service:
java.net.SocketTimeoutException: Socket operation timed out before it could be completed
The default timeout value is 60 seconds, so this error occurs if the target web service takes longer than 60 seconds to respond. We can increase the timeout value by setting a timeout custom property on the inbound port as described in Inbound Ports [Settings].
A bus-enabled web services application or resource needs to be installed manually
The following bus-enabled web services applications and resources are installed automatically when they are first needed:
- The bus-enabled web services application (the application that lets you configure and access web services through a service integration bus).
- The service integration technologies resource adapter (used to invoke web services at outbound ports).
- The endpoint listener applications (used to enable the points at which messages for inbound services are received).
For example, an endpoint listener application is installed as part of the process of creating a new endpoint listener configuration.
However if you do have to manually install one of these applications, we can do so using the supplied sibwsInstall.jacl script, and following the instructions given in the WAS Version 6.0.x topic: Installing the bus-enabled web services applications and resources
Client application works under WebSphere Application Server Version 5.1, but problems in later versions
You have a client application that works under WebSphere Application Server Version 5.1, but in later versions you get problems caused by poorly-formed requests or responses.
Bus-enabled web services check the validity of web service messages more thoroughly than is done in WebSphere Application Server Version 5.1. As a result, some client applications that use poorly-formed requests or responses (where the message parts are misnamed), and that work when using Version 5.1, are identified as poorly-formed in later versions. For the steps to take to resolve the problem, see Toleration of poorly-formed SOAP messages
Error when JAX-RPC client running on WebSphere Application Server Version 5.1 uses SOAP over JMS to invoke a web service
A JAX-RPC client running on WebSphere Application Server Version 5.1 uses SOAP over JMS to invoke a web service running on a Version 5 application server. No user ID or password is required on the target MQ Series queue. After the application server is migrated to a later version, and to use default messaging, client requests fail because basic authentication is now enabled.
The problem appears as a log message:
SibMessage W [:] CWSIT0009W: A client request failed in the application server with endpoint <endpoint_name> in bus your_bus with reason: CWSIT0016E: The user ID null failed authentication in bus your_bus.For the steps to take to resolve the problem, see the following service integration technologies troubleshooting tip: Migrate a Version 5.1 application server to WAS v7 or later
Error message when attempting to create an Informix database for use with the SDO repository
You unsuccessfully attempt to create an Informix database for use with the SDO repository, and receive the message No Transaction Isolation on non-logging databases.
If No Transaction Isolation on non-logging databases. is displayed as part of an exception message, it is because logging is disabled on the Informix database being used. To use an Informix database with the SDO repository, enable logging.
The full exception text is:
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: javax.transaction.TransactionRolledbackException: ; nested exception is: javax.ejb.TransactionRolledbackLocalException: ; nested exception is: com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1013E: Exception occurred when verifying current backend id INFORMIX_V94: javax.resource.spi.ResourceAllocationException: DSRA0080E: An exception was received by the Data Store Adapter. See original exception message: No Transaction Isolation on non-logging dbs., error code: DSA_ERROR, error code: DSA_ERROR vmcid: 0x0 minor code: 0 completed: NoLogging is disabled by default, so the create database statement CREATE DATABASE SDOREP; results in an exception at run time. When we create the database, use one of the following database creation statements:
- CREATE DATABASE SDOREP WITH LOG;
- CREATE DATABASE SDOREP WITH BUFFERED LOG:
- CREATE DATABASE SDOREP WITH LOG MODE ANSI;
Inbound service published to a UDDI registry is not listed and republish is unsuccessful
You have an inbound service that, according to the administrative console, is published to a UDDI registry. When you check the UDDI registry you discover that the service is not listed there. When you attempt to use the administrative console to republish the service to UDDI, the attempt is unsuccessful.
The service was published to the UDDI registry, and the service configuration shown in the WAS administrative console includes a UDDI Service Key, but the service has subsequently been unpublished from UDDI without the corresponding update being applied to the WAS master configuration. One way in which this situation can arise is if you use the administrative console to delete an inbound service that is published to a UDDI registry, then log out of the administrative console without saving the changes. In this case, the service is unpublished from the UDDI registry, but not deleted from WebSphere Application Server (because the delete request is not confirmed, and therefore is not applied).
To update the service configuration information and republish the service to UDDI, use the administrative console to complete the following steps:
The service is successfully republished, and is reinstated in the UDDI registry.
- In the navigation pane, click Service integration -> Buses -> bus_name -> [Services] Inbound Services -> service_name. The current settings for this inbound service are displayed.
- Click Reload template WSDL, then save the changes.
- Click Unpublish from UDDI, then save the changes.
- Click Publish to UDDI, then save the changes.
WSDL must be retrieved though command line if bus needs to pass messages through an authenticating proxy server to retrieve WSDL documents
If the bus needs to pass messages through an authenticating proxy server to retrieve WSDL documents, then use command-line tools to retrieve the WSDL.
Neither the administrative console panels used to create a new web service configuration, nor the Reload WSDL button provided on the panels used to modify an existing web service configuration, allow you to enter a J2C authentication alias for WSDL retrieval. Therefore when creating or modify inbound and outbound services, if the bus needs to pass messages through an authenticating proxy server to retrieve WSDL documents then use one of the following command-line tools to retrieve the WSDL:
- Create a new inbound service configuration by .
- Create a new outbound service configuration by .
- Refreshing the inbound service WSDL file by .
- Refreshing the outbound service WSDL file by .
Use JMS to connect to a remote bus requires extra configuration to allow web service clients to connect to the bus
If we are using JMS to connect to a remote bus, extra configuration is required to allow web service clients to connect to the bus.
A web service client application running in a server that is a member of a bus can locate a messaging engine in that bus. A web service client application running outside of an application server - for example, running outside the WAS environment - cannot locate directly a suitable messaging engine to connect to in the target bus. Similarly, a web service client application running on a server in one cell that needs to connect to a target bus in another cell cannot locate directly a suitable messaging engine to connect to in the target bus.
To enable the web service client application to contact a target messaging engine in a remote bus, configure the JMS connection factory that the client uses so that the client can connect to a bootstrap messaging engine in the remote bus. The bootstrap messaging engine then identifies the target engine, and the information required to access the target engine is passed back to the client. For the bootstrap process to be possible, configure one or more provider end points in the connection factory used by the client. For more information, see Configure connection to a non-default bootstrap server.
Out-of-memory error in the Java virtual machine when passing a large attachment through the service integration bus
You pass a large attachment through the service integration bus and you get an out-of-memory error in the Java virtual machine.
If this error occurs, increase the heap size as described in Tune bus-enabled web services.
Error when trying to create a new endpoint listener configuration using the administrative console
When you try to create a new endpoint listener configuration using the administrative console, and click New on the endpoint listener collection panel, the "Please wait" icon is displayed but the target panel does not appear.
This problem is only found with older versions of the Mozilla web browser. Upgrade your browser to Version 1.4 or later. As a workaround, click New a second time and the target panel is displayed.
Error trying to create a new inbound service through the administrative console
When you try to create a new inbound service through the administrative console, the drop-down list of destinations is empty and the wizard stops you at step 1 with the error message A destination must be selected.
This can only happen if there is no messaging engine on the service integration bus on which we are creating the inbound service. Create a messaging engine, then create a service destination, then re-run the wizard to create a new inbound service configuration.
Problems with handling SOAP messages with attachments
Malformed URLException error when trying to send a SOAP over HTTPS message
We are trying to send a SOAP over HTTPS message, and you are receiving a Malformed URLException error.
The service integration technologies can use Secure Sockets Layers (SSL) to invoke external web services that include https:// in their addresses. For more information see Invoking outbound services over HTTPS.
JNDI lookup errors when JMS resources on different machines have the same names
You get JNDI lookup errors when you use the same names for JMS messaging queues and queue connection factories that run on application servers on different machines.
We must not use the same names for messaging queues and queue connection factories that run on application servers on different machines, because the service integration technologies always look first for JMS destinations locally, and only use the full JNDI reference if they cannot find the destination locally. If we configure as an outbound service a web service that is hosted on a remote machine, and you use the same names for messaging queues and queue connection factories on the remote machine and on the machine on which the outbound service is hosted, then the service integration technologies find and use the local queues even if the remote JNDI destination is provided in full in the WSDL service definition.
Error returned when installing the sibwsauthbean.ear file
We are password-protecting a web service operation, but when you install the sibwsauthbean.ear file, an error message is displayed in the WAS administrative console detailing a Java Naming and Directory Interface (JNDI) problem.
When you password-protect a web service operation, check that you enter, 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.
Precise problem cannot be determined from SOAP fault messages
We are getting SOAP fault messages, but cannot determine the precise problem from the fault message.
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 we 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 bus-enabled web services.
Listener port timeout errors when large messages are passed using the SOAP over JMS endpoint listener
As with any synchronous endpoint listener, timeout errors can occur. To minimize the frequency of timeout errors, increase the timeout settings for the endpoint listener. If the problem persists, then disable trace and logging for service integration technologies by setting the application server trace string to com.ibm.ws.sib.webservices.*=all=disabled.
Subtopics
- Bus-enabled web services: Known restrictions
There are a small number of known restrictions that apply when using service integration bus-enabled web services.
Related tasks
Secure bus-enabled web services Work with password-protected components Password-protecting inbound services Invoking outbound services over HTTPS Access a password-protected proxy server Password-protecting a web service operation Use assembly tools to password-protect a web service operation Reference topic