Diagnosing MTOM/XOP errors

MTOM/XOP errors can occur at run time, in both requester and provider mode pipelines.

If you are having problems configuring a pipeline to support MTOM/XOP, follow Diagnosing deployment errors.

Procedure

  • If you are able to send a web service request message in MTOM format, but are getting a SOAP fault message from the web service provider, look at the contents of the DFHWS-BODY container for details of the SOAP fault.
    1. Is the web service provider able to receive MIME Multipart/Related messages?
      If the web service provider does not support the MTOM format, the fault that you get back can vary depending on the implementation. If the web service provider is another CICS application, the SOAP fault would indicate that the MIME message is not a valid content type.
    2. If the web service provider can receive MIME messages, check to see if the pipeline is sending the message in direct or compatibility mode.
      If you are sending an MTOM message in direct mode, there could be a problem with the XML.
    3. To find out if the problem is with the XML, turn validation on for the web service.
      This causes the MTOM message to be processed in compatibility mode through the pipeline. As part of this processing, the MTOM handler parses the message contents to optimize the base64binary data. If there is an error in the XML, CICS puts the error in the DFHERROR container and issues an MTOM transport failure in the pipeline.
    4. Examine the contents of the DFHERROR container to see if this indicates what problem occurred. If this isn't enough information to help you diagnose the cause of the problem, run a level 2 trace of the PI domain.
    5. Look for trace point PI 0C16.
      This describes the problem that was encountered in more detail, and should help you to fix the problem with the XML that is provided by the requester application.
  • If expected binary attachments are missing from the outbound MTOM message, this could indicate that the binary data is considered too small to optimize as a binary attachment.
    CICS only creates binary attachments for data that is large enough to justify the processing overhead of optimizing it in the pipeline. Any binary data below 1,500 bytes in size is not optimized.
  • If you are unable to send an outbound MTOM message in compatibility mode and the pipeline is returning a DFHERROR container, there was a problem when the pipeline tried to process the MTOM 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. Check that the XML in your outbound MTOM message is valid.
      CICS does not perform any validation on outbound messages in the pipeline.
  • If you receive a DFHPI1100E message, there was a problem with the MIME headers of an MTOM message that was received by CICS.
    The CICS message contains the general class of MIME error that occurred. To find the exact problem that occurred:
    1. If you have auxiliary trace active in your CICS region, check for any exception trace entries.
    2. Look for trace point PI 1305.
      This describes the nature of the MIME header error, the location of the error in the header, and up to 80 bytes of text before and after the error so you can understand the context of where the error occurred.
    For example, the following excerpt of trace indicates that the MIME content-type start parameter was invalid because it was not enclosed in quotes, but included characters that are not valid outside a quoted string.
    PI 1305 PIMM *EXC* - MIME_PARSE_ERROR - 
             
             TASK-01151 KE_NUM-0214 TCB-QR   /009C7B68 RET-9C42790A TIME-10:33:41.3667303015 INTERVAL-00.0000053281        =000599=
               1-0000  C5A79785 83A38584 40978199 819485A3  859940A5 8193A485 40A39692 85954096  *Expected parameter value token o*
                 0020  994098A4 96A38584 40A2A399 899587                                         *r quoted string                 *
               2-0000  D4C9D4C5 40A2A895 A381A740 85999996  994081A3 404EF0F0 F0F0F1F1 F2408995  *MIME syntax error at +0000112 in*
                 0020  40C39695 A38595A3 60A3A897 85408885  81848599                             * Content-type header            *
               3-0000  5F626F75 6E646172 793B2074 7970653D  22617070 6C696361 74696F6E 2F786F70  *_boundary; type="application/xop*
                 0020  2B786D6C 223B2073 74617274 2D696E66  6F3D2261 70706C69 63617469 6F6E2F73  *+xml"; start-info="application/s*
                 0040  6F61702B 786D6C22 3B207374 6172743D                                       *oap+xml"; start=                *
               4-0000  3C736F61 70736C75 6E674074 6573742E  68757273 6C65792E 69626D2E 636F6D3E  *<soapslung@test.hursley.ibm.com>*
                 0020  3B206368 61727365 743D7574 662D38                                         *; charset=utf-8                 *
  • The pipeline processing fails to parse an inbound MTOM message, and the web service requester receives a SOAP fault message.
    This indicates that there was a problem with the XOP document in the MTOM message. In direct mode, the SOAP fault is generated by the application handler. If the pipeline is running in compatibility mode, the message is parsed by the MTOM handler when constructing the SOAP message. In this case, CICS issues a DFHPI prefixed error message and a SOAP fault.
    1. The DFHPI prefixed error message indicates what was wrong with the XOP document.
      For example, it could be an invalid MIME header or a missing binary attachment.
    2. To find the exact cause of the problem, check for any exception trace points.
      In particular, look for trace points beginning with PI 13xx. This describes the exception that occurred in more detail.
    You can also run a PI level 2 trace to establish the sequence of events leading up to the error, but this can have a significant performance impact and is not recommended on production regions.