This document describes utilities that are helpful for debugging Web Services API related issues with Service Desk.
CA Support will not assist in debugging the customer's Web Services Client code.
However, Support will work with you to find out if the problem is with the Service Desk Web Services API and not with the field developed Web Services consumer/client.
When discovering a problem with the Service Desk Web Services API, the following information can be helpful to you and Support in finding what the appropriate next action is.
- Summarize the Web Services Calls you are making to Support and in which order.
- login to create a Session ID (SID)
Used to retrieve the handle (persid) for an assignee or affected end user.
Used to query to see if there is an existing request by searching the request table by affected end user's handle/persid.
If no requests are found, createRequest is called to create a request with this data.....<data>.
End the session with Service Desk.
- Any exceptions caught by the Web Services Client are helpful and what you see that tells you there is a problem.
Often, there will be a Service Desk error code returned. For example, "3002" or "1010". The descriptions for these are found on page 52 of the r11 Web Services User Guide.
- Use a SOAP Trace Tool to capture the XML sent to Service Desk and returned. Microsoft offers MS SOAP Toolkit, and there is a java tool called "tcpmon":
For use with troubleshooting Web Services issues in Service Desk, the TCPMon can reside on ANY machine on the same network.
The Web Services Application or in many cases the CA application using the CA Service Desk Web Services API needs to be pointed to the port TCPmon is running on.
This corresponds to the "Local Port" in TCPmon. use common sense when picking this port (and/or netstat to make sure the port is not already in use).
The server port is the Service Desk tomcat port.
The Server Name is the hostname/IP address of the Service Desk server. See Figure A:
Example of TCPMon capturing error, notice the Web Services Exception on the bottom pane.
The bottom pane shows the return from Service Desk.
The top shows what was sent to Service Desk, see Figure B:
Example of TCPMon capturing working call. Notice the handle (persid) returned in the bottom pane, see Figure C.
The intent behind this is to compare what was sent to Service Desk and what was returned to the Web Services client.
This is helpful to capture errors if something goes wrong or a specific method is not working in your environment.
Sending the XML to Support is when opening the issue is helpful.
Support can then run the same method call in-house, see where the problem lies and offer feedback.
- The following Service Desk logging is also helpful. This will record verbose output to the stdlog files under NX_ROOT/log.
Please be sure to send Support the entire NX_ROOT/log folder for review:
pdm_logstat -f api.spl 300
pdm_logstat -n sda 300
pdm_logstat -f spelsrvr 300
Reproduce the problem, then turn off the logstat as follows:
pdm_logstat -f api.spl
pdm_logstat -n sda
pdm_logstat -f spelsrvr
- Patch Level
At times, specific patch levels need to be looked at. Please send Support a copy of the $NX_ROOT/<servername>.his file.
Note: CA Support will not assist you in debugging your code. However, they will do their best to help you identify what arguments or data needs to be corrected to resolve the issue.
For assistance with creating Web Services Applications to utilize the Service Desk Web Services API, please contact CA Technical Field Services through your CA Account manager.