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, the problems could be due to errors in individual
Web services or issues at the transport level.
- If you are using the INVOKE WEBSERVICE command
in your application program, a RESP and RESP2 code are returned when there
is a problem.
- Look up the meaning of the RESP and RESP2 codes for the INVOKE
WEBSERVICE command to give you an indication of what the problem might be.
- 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.
- Look at the contents of the DFHERROR container. This
should contain an error message and some data describing the problem that
occurred.
- 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.
- If the Web service requester application is not using the INVOKE
WEBSERVICE command to send a Web service request, check that it
has created all of the necessary control containers and that they are the
right datatype. In particular, check that the DFHREQUEST container has a datatype
of CHAR rather than BIT.
- If the Web service requester application is using the INVOKE
WEBSERVICE command an INVREQ and a RESP2 code of 14 is returned,
this indicates that there has been a data conversion error. See Diagnosing data conversion errors.
- 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 WEBSERVICE 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 normally returned as a SOAP fault.
- Check that the network end point is present.
- Ensure that the dispatcher timeout for the transaction meets
your application's requirements. The DTIMEOUT attribute on the
transaction defines how long CICS waits for a reply from the Web service provider
before returning to the application.
- 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.
- 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.