I need to troubleshoot a call request to our Remedy system for the CreateITSMTicket (part of CA Remedy Gateway) process. How can I enable some trace or log to see the actual XML that is sent to Remedy?
Reply to my own message with new discovery...
Seems the line with "c:\request.xml" needed to be "c:/request.xml". This allowed the request to be written out to a file where it could be examined.
Changing the logging level was helpful because it allowed me to see that this backslash was causing this to fail. It did not provide the trace data I was looking for, however. Bottom line, I was able to diagnose that the CA Remedy Gateway CreateITMTicket is in fact failing to send all of the ticket fields in some cases. Now I'm working to find out why.
You can increase PAM logging level and some detail on your XML will be output into the \pam\server\c2o\log\c2o.log file.
TEC575522 Increase logging levels, file size and rollover for PAM logs
But the logs can be diffciult to review for individual instance runs, to review the soap for a specific instance run is probably simpler to use the Datasets within the instance runs to get these details:
As well as the results:
I don't seem to have the same display available. Instead I have:
Ah, you are using the Remedy connectors which as specialized versions of the other operators, in this case the Soap operators. I would assume the details sent are in one of those other dataset properties options, possibly HelpDeskCallParams, unless they are being contained in the request.xml.
Additionally, you will want to review and apply the current connector to help clear the stop signs, though if you have modified and saved this process they will remain the stop signs.
See TEC595757 After upgrading from ITPAM 2.x/3.x to ITPAM 4.x, classic connector icons are showing as red stop signs. for more details.
I believe we've done all we can to remove the stop signs.
As I mentioned on other thread on case, I don't see any file as described "c:\request.xml". I guess I'll try changing the PAM logging level and see if I get anything.
Just to clarify. The details are in those dataset values. But I really need to see what the outgoing XML looks like. I have cases where the call succeeds and where the call fails and the dataset shows everything basically the same.
Retrieving data ...