Resolving problems when you use HTTP and SOAP nodes

Use the advice that is given here to help you to resolve common problems that can arise when you develop web services message flows that contain HTTP and SOAP nodes.

About this task

If you experience problems when you use HTTP and SOAP nodes in message flows, complete the instructions for the following scenarios to diagnose and solve the problem.

Use the replies to the following questions to assist you in diagnosing problems with HTTP or SOAP nodes:

Error message BIP3689 is issued when you deploy or restart an integration server

Procedure

  • Scenario: You configure Web Services Reliable Messaging (WS-RM) on one or more message flow nodes in your message flow configuration. When you attempt to deploy the configuration to an integration server, or to restart the integration server, you see a BIP3689 error message.
  • Explanation: Two or more message flow nodes in your deployment configuration have the same value for the Path suffix for URL property, and at least one of these nodes is using WS-RM. Using the same URL twice is not allowed, as one integration server might get messages intended for another integration server, therefore breaking the WS-RM message ordering.
  • Solution: Review the values for the Path suffix for URL property in the message flow nodes that you plan to deploy to the same integration node. Ensure that the URL for a node that is using WS-RM is not used anywhere else in the deployment configuration.

Warning message BIP3690 is issued when you deploy or restart an integration server

Procedure

  • Scenario: Your integration server contains SOAP or HTTP input nodes in one or more message flows. When you attempt to deploy the integration server, or to restart it, you see a BIP3690 warning message.
  • Explanation: This warning message indicates that you are using the same value for the Path suffix for URL property in both SOAP and HTTP nodes in your deployed topology. You do not see the warning if you use the same URL in two or more HTTP nodes, or in two or more SOAP nodes.

    For example, you might deploy the same flow to multiple integration servers for scaling and performance reasons; this configuration is valid and does not trigger the warning. However, using the same URL across SOAP and HTTP nodes might result in unexpected behavior, and always triggers a warning, even if the configuration is valid.

    If you are using SOAP nodes and HTTP nodes in message flows on a single integration node, you can choose to handle HTTP messages by using either the integration node listener or embedded integration server listeners. If a listener in your configuration receives messages that both SOAPInput and HTTPInput nodes might get, you must carefully check the URL specifications in these nodes. If both URL specifications match an incoming message, the wrong type of node might get the message, and processing might fail or produce unexpected results. This situation occurs if you specify identical values for the Path suffix for URL properties of the HTTPInput node and the SOAPInput node. It can also occur if you use wildcards in either or both specifications, and an incoming message matches both properties.

  • Solution: Check the URL specifications in your HTTP and SOAP input nodes and confirm that message routing works as intended.

A HandshakeException is issued when you use an HTTPRequest node to make an HTTPS call

Procedure

  • Scenario: You are trying to make an HTTPS call to an external web service from your IBM® Integration Bus message flow by using an HTTPRequest node. You receive the following error: 
    javax.net.ssl.SSLHandshakeException: 
com.ibm.jsse2.util.h: PKIX path building failed:

java.security.cert.CertPathBuilderException: 
PKIXCertPathBuilderImpl could not build a valid CertPath.;

internal cause is: 
java.security.cert.CertPathValidatorException:
The certificate issued by OU=Class 3 Public Primary Certification Authority,
O="VeriSign, Inc.", C=US is not trusted;

internal cause is: 
java.security.cert.CertPathValidatorException: Certificate chaining error
  • Explanation: The integration node cannot build the entire certificate path. The keystore of this integration node must contain all the certificates in this chain of certificate authorities (CA). For an integration node to verify the digital signature on a signed certificate, the keystore must contain the public key of the certificate authority (CA) that issued that certificate. If this public key is itself issued on a signed certificate, the keystore must contain the public key of the CA that issued that certificate. This chain continues until the integration node reaches a root certificate authority that issues a self-signed certificate.
  • Solution: Verify that you added all the required certificates to your keystore. If any of the components in the certificate chain are missing from your keystore, re-create your keystore by using keytool with the genkey option, then reimport your application certificates.

How do I tell which listener the HTTP and SOAP nodes are using?

Procedure

  • Scenario: HTTP and SOAP nodes that you include in a message flow can use either the integration node listener or the embedded listener that is defined to the integration server to which the containing message flow is deployed.
    Both listeners can handle both HTTP and HTTPS messages by handling the different message types on different ports.
  • Solution: Use the mqsireportproperties command to check the properties that define what listener is in use.
    1. Check whether the integration node listener is disabled:
      mqsireportproperties IBNODE -b httplistener -o HTTPListener -n startListener

      If this property is false, all HTTP and SOAP nodes in all integration servers are using an embedded listener.

    2. If the integration node listener is active, you must check the specific integration server.

      For example, check whether the listener in integrationServerName is being used to process HTTP messages for HTTP nodes:

      mqsireportproperties integrationNodeName -e integrationServerName -o ExecutionGroup  -n httpNodesUseEmbeddedListener

      If this property is true, all HTTP nodes that you deploy to this integration server are using the embedded listener.

      Check all integration servers for which you want to know this information.

      Check whether the listener in integrationServerName is being used to process HTTP messages for SOAP nodes:

      mqsireportproperties integrationNodeName -e integrationServerName -o ExecutionGroup  -n soapNodesUseEmbeddedListener

      If this property is true (the default value), all SOAP nodes that you deploy to this integration server are using the embedded listener.

      Check all integration servers for which you want to know this information.

    3. If both properties are false, all HTTP and SOAP nodes that you deploy to all integration servers are using the embedded listener. The value for the integration server property is ignored.

Results

If you are experiencing problems with message flows that contain HTTP or SOAP nodes, and you want to collect trace information to provide to your IBM Support Center, trace the integration server. If you are using the integration node listener for HTTP or SOAP nodes, also trace the HTTPListener component.

How do I collect HTTPListener trace?

About this task

To gather information about HTTP nodes and listeners, you must start trace, run your message flows, then retrieve and format the trace information.

Trace the integration server and the HTTPListener component:

Procedure

  • Start trace for the integration server.
    For example:
    mqsichangetrace IBNODE -t -e integrationServerName -l debug
  • If you are using the integration node listener for one or more integration servers, start trace for the HTTPListener component in one of the following two ways:
    • Trace all integration node components:
      1. Run the mqsichangetrace command to start trace with the following options: 
        mqsichangetrace component -t -b -l debug
        where component is the integration node name.
      2. Retrieve the HTTPListener trace log by using the mqsireadlog command with the HTTPListener qualifier for the -b parameter.

        For example:

        mqsireadlog integrationNodeName -t -b httplistener -f -o listenertrace.xml
      3. Format the trace log by using the mqsiformatlog command to view its contents.
    • Trace only the HTTPListener component:
      1. Run the mqsichangeproperties command to start trace with the following options: 
        mqsichangeproperties integrationNodeName -b httplistener -o HTTPListener 
	-n traceLevel -v debug
      2. Retrieve and format the HTTPListener trace log as shown in the previous example.

What to do next

Save the trace output so that you can send it to the IBM Support Center, if requested.

Turn off trace when you finish collecting information to avoid affecting the performance of the integration node.