.. _debugging: Debugging ======================================= When a dotCMIS based integration starts failing, it's usually because of what's actually on the wire rather than a bug in the calling code. The tools below help you inspect the AtomPub requests and responses exchanged with the CMIS repository so you can narrow down the cause. .. _inspecting-network-traffic: Inspecting network traffic """"""""""""""""""""""""""" Most issues encountered when integrating with CMIS are easiest to diagnose by looking directly at the HTTP traffic rather than the client code, since it removes dotCMIS as a variable entirely. Any suitable tool capable of capturing and inspecting the raw AtomPub requests exchanged between your application and ECM can be used for this purpose, for example Fiddler (paid) or Wireshark (open source). Replaying and modifying requests """""""""""""""""""""""""""""""""" Once you have captured a request, it can be useful to replay and tweak it outside of your application using a dedicated API client. This is a quick way to confirm whether a problem is caused by how dotCMIS builds a request, or by the request itself. Any suitable REST/HTTP client tool can be used for this purpose, for example Postman or Bruno. General tips """"""""""""""" - Reproduce the issue with the smallest possible request. Narrowing down to a single ``getObject`` or ``query`` call makes the capture much easier to read. - Compare a failing request against a known working one for the same repository. Differences in headers (particularly ``Authorization`` and ``AuthDomain``) are a common source of problems; see :ref:`Authentication` for details. - Check the response body of failing requests, not just the HTTP status code. CMIS error responses include an XML payload describing the specific exception raised on the server. - If the issue can't be resolved, see :ref:`Support` for how to lodge a request, including an exported capture of the failing request and response.