Resolving problems when you use HTTP and 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 broker, you can choose to handle HTTP messages by using either the broker 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.

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

1. Check whether the broker listener is disabled:

   mqsireportproperties IB9NODE -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 broker listener is active, you must check the specific integration server.

   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 integration server are using the embedded listener.

   Check all integration servers 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 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.

• 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.