If you are having problems receiving or processing inbound messages
in a provider mode pipeline, there could be a problem with the transport or
a specific SOAP message.
- You receive a DFHPI0401, DFHPI0502 or similar message, indicating
that a HTTP or WMQ transport error has occurred. If the transport
is HTTP, the client receives a 500 Server Internal Error message. If the transport
is WMQ, the message is written to the dead letter queue (DLQ). A SOAP fault
is not returned to the Web service requester, because CICS is unable to determine
what type of message was received.
- If you are using HTTP, check that you have specified the charset
parameter on the Content-Type header of the Web service request; for example, charset=ISO-8859-1 During request processing of the inbound SOAP request, CICS checks for
a charset value and issues the DFHPI0401 message if this
parameter is not present. The client receives a 500 Server Internal Error
message.
- You receive a DFH-prefixed message, and a 404 Not Found error message.
- If you are not using the Web services assistant, you must create
a URIMAP resource. If you are using the Web services assistant,
the URIMAP is created automatically for you when you run the PIPELINE
SCAN command. The system log provides information on any errors
that occurred as a result of running this command.
- Check that the WEBSERVICE resource is enabled and that the URIMAP
it is associated with is what you expected. If your WEBSERVICE
resource has installed in an UNUSABLE state, see Diagnosing deployment errors.
- Check that you have correctly specified the URI and port number. In particular, check the case as the attribute PATH on the URIMAP resource
is case sensitive.
- If there are unexpected errors being reported, consider using CEDX
to debug the Web service application.
- Check the system log to see what error messages are being reported
by CICS. This could give you an indication of what type of error
is occurring. If CICS is not reporting any errors, ensure that the request
is reaching CICS through the network.
- Run CEDX against CPIH for the HTTP transport, CPIQ for the WMQ
transport, or the transaction that you specified in the URIMAP if this is
different.
If a task switch occurs during the pipeline processing
before the application handler, then unless the DFHWS-TRANID container is
populated, the new task runs under the same transaction id as the first one.
This can interfere with running CEDX, as the first task has a lock on the
CEDX session. You can avoid this problem by using DFHWS-TRANID to change the
transaction id when the task switches, allowing you to use CEDX on both the
pipeline and application tasks separately.
- If CEDX doesn't activate or allow you solve the problem, consider
running auxiliary trace with the PI, SO, AP, EI, and XS domains active. This could indicate whether there is a security problem, TCP/IP problem,
application program problem or pipeline problem in your CICS region. Look
for any exception trace points or abends.
- If you are receiving conversion errors, see Diagnosing data conversion errors.