Diagnosing service requester runtime errors

Read this section if you are having problems sending web service requests from your service requester application, or you are receiving SOAP fault messages from the web service provider.

• If you are using the INVOKE SERVICE command in your application program, a RESP and RESP2 code are returned when there is a problem.
  1. Look up the meaning of the RESP and RESP2 codes for the INVOKE SERVICE command to give you an indication of what the problem might be.
  2. Check the CICS® system log to see if there are any messages that can help you determine the cause of the problem.
• If you are unable to send a SOAP request message and the pipeline is returning a DFHERROR container, there was a problem when the pipeline tried to process the SOAP message.
  1. Look at the contents of the DFHERROR container.
     This should contain an error message and some data describing the problem that occurred.
  2. Have you introduced any new message handlers or header processing programs in the pipeline?
     If you have, try removing the new program and rerunning the web service to see if this solves the problem. If your message handler is trying to perform some processing using a container that isn't present in the pipeline, or is trying to update a container that is read-only, the pipeline stops processing and returns an error in the DFHERROR container. Header processing programs can only update a limited set of containers in the pipeline. See The header processing program interface for details.
  3. If the web service requester application is not using the INVOKE SERVICE command to send a web service request, check that it has created all of the necessary control containers and that they are the correct datatype. In particular, check that the DFHREQUEST container has a datatype of CHAR rather than BIT.
  4. If the web service requester application is using the INVOKE SERVICE command and a RESP value of INVREQ and a RESP2 code of 14 is returned, this indicates that there has been a data conversion error.
     See Diagnosing data conversion errors.
  5. Check that the XML in your SOAP message has not been invalidated by a custom message handler during pipeline processing.
     CICS does not perform any validation on outbound messages in the pipeline. If your application uses the INVOKE SERVICE command, the XML is generated by CICS and is well formed when the body of the SOAP message is placed in the DFHREQUEST container. However, if you have any additional message handlers that change the contents of the SOAP message, this is not validated in the pipeline.
• If you are able to send a SOAP message, but are getting a time out or transport error, this is usually returned as a SOAP fault. If your program is using the INVOKE SERVICE command, CICS returns a RESP value of TIMEDOUT and RESP2 code of 2 for a timeout error, and a RESP value of INVREQ and RESP2 code of 17 for a transport error.
  1. Check that the network end point is present.
  2. Ensure that the RESPWAIT attribute on the PIPELINE resource is correctly configured to meet your application's requirements.
     The RESPWAIT attribute defines how long CICS waits for a reply from the web service provider before returning to the application. If no value is specified, CICS uses the defaults of 10 seconds for HTTP and 60 seconds for WebSphere® MQ. However, CICS also has a time out in the dispatcher for each transaction, and if this is less than the default of the protocol that is being used, CICS uses the dispatcher time out instead.
• If you are able to send a SOAP message, but are getting a SOAP fault response back from the web service provider that you didn't expect, look at the contents of the DFHWS-BODY container for details of the SOAP fault.
  1. If you sent a complete SOAP envelope in DFHREQUEST using the DFHPIRT interface, ensure that the outbound message doesn't contain duplicate SOAP headers.
     This can occur when the requester pipeline uses a SOAP 1.1 or SOAP 1.2 message handler. The SOAP message handlers add SOAP headers, even if they are already specified in the SOAP envelope by the service requester application. In this scenario, you can either:
  • Remove the SOAP 1.1 or SOAP 1.2 message handler from the pipeline. This will affect any other service requester applications that use this pipeline.
  • Remove the SOAP headers from the SOAP envelope that the application puts in DFHREQUEST. CICS adds the necessary SOAP headers for you. If you want to perform additional processing on the headers, you can use the header processing program interface.
  • Use a WEB SEND command instead in your application and opt out of the web services support.
• If you think the problem is related to sending or receiving MTOM messages, see Diagnosing MTOM/XOP errors.