WebSphere Message Broker, Version 8.0.0.7 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

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.

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 execution group

  • Scenario: You configure Web Services Reliable Messaging (WS-RM) on one or more nodes in your message flow configuration. When you attempt to deploy the configuration to an execution group, or to restart the execution group, you see a BIP3689 error message.
  • Explanation: Two or more 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 execution group might get messages intended for another execution group, therefore breaking the WS-RM message ordering.
  • Solution: Review the values for the Path suffix for URL property in the nodes that you plan to deploy to the same broker. 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 execution group

  • Scenario: Your execution group contains SOAP or HTTP input nodes in one or more message flows. When you attempt to deploy the execution group, 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 execution groups 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 broker, you can choose to handle HTTP messages by using either the broker listener or embedded execution group 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

  • Scenario: You are trying to make an HTTPS call to an external web service from your WebSphere® Message Broker 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 broker cannot build the entire certificate path. The keystore of this broker must contain all the certificates in this chain of certificate authorities (CA). For a broker 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 broker 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?

  • Scenario: HTTP and SOAP nodes that you include in a message flow can use either the broker-wide listener or the embedded listener that is defined to the execution group 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 broker listener is disabled:
      mqsireportproperties MB8BROKER -b httplistener -o HTTPListener -n startListener 

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

    2. If the broker listener is active, you must check the specific execution group.

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

      mqsireportproperties TEST -e EG_A -o ExecutionGroup  -n httpNodesUseEmbeddedListener

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

      Check all execution groups for which you want to know this information.

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

      mqsireportproperties TEST -e EG_A -o ExecutionGroup  -n soapNodesUseEmbeddedListener

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

      Check all execution groups for which you want to know this information.

    3. If both properties are false, all HTTP and SOAP nodes that you deploy to all execution groups are using the embedded listener. The value for the execution group property is ignored.
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 execution group. If you are using the broker-wide listener for HTTP or SOAP nodes, also trace the HTTPListener component.

How do I collect HTTPListener trace?

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 execution group and the HTTPListener component:

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

        For example:

        mqsireadlog brokerName -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 brokerName -b httplistener -o HTTPListener 
        	-n traceLevel -v debug
      2. Retrieve and format the HTTPListener trace log as shown in the previous example.
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 broker.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2016Copyright IBM Corporation 1999, 2016.

        
        Last updated:
        
        Last updated: 2016-05-23 14:48:28


Task topicTask topic | Version 8.0.0.7 | bu43710_