PAM - Troubleshooting CA ServiceDesk Connector Issues

Products

• CA Process Automation Base

Issue/Introduction

A process that we run is intermittently failing. When it does fail, it fails while running the same operator: CA ServiceDesk -> Select Object.

 

Environment

Process Automation Release : 4.3.05 CP03

ServiceDesk Manager Release : 17.3

 

Cause

The causes of failures will vary. This article recommends some techniques for troubleshooting. 

 

Resolution

To help isolate the root cause, there are a couple of techniques that can help. They are outlined below, but most focus on finding the details behind the failure. Process Automation uses WebService calls to communicate with SDM. It is not uncommon for these problems to fall under one of the following two categories:

1. Valid data being handled in error. In this scenario, the data being sent to SDM is valid but SDM is having a problem processing it when it shouldn't. For these types of errors we will need to investigate the cause in SDM. 
2. Invalid data being handled appropriately. In this scenario, the data being sent to SDM is invalid and SDM is appropriately returning an error. For these types of errors we will need to investigate the error message and figure out how the data fed through the operator needs to be manipulated/changed/corrected.

Using the "Operation Results" -> SoapErrorResponse

This assumes the data passed to SDM is invalid and rejected accordingly. 

1. Reproduce the issue OR review a previously failed process.
2. Select the operator that failed.
3. Expand the Dataset -> Operation Results. 
4. Double-click on the SoapErrorResponse variable to view the details of the failure. 

"Fault returned by the WebService:" in the c2o.log

This also assumes the data passed to SDM is invalid and was rejected by SDM. These occurrences often show some of the rejection info in the c2o.log.

1. Reproduce the issue.
2. Open the c2o_home/server/c2o/log/c2o.log file.
3. Search for occurrences of "Fault returned by the WebService:" - specifically around the time when the failure occurred.
   If it is not clear what time the error occurred then you Dataset (in the failed process) of the failed operator often has a System folder with "StartDate" and "StartTime" variables. For example:

"Error in post-execution code"

This assumes that the SDM call completed successfully. But there was an error while executing the "Execution Settings" -> "Post-execution code". This could be for any reason since it's code. However, if the code usually works then an occasional failure will often mean that the code is trying to handle unexpected data. You can usually find out more in the dataset after the failure. When experiencing this type of problem you will see this error when navigating to:

1. Select the operator that's failing in the process.
2. Expand the System dataset. 
3. Find the "Reason" variable. This is where you'll see the "Error in the post-execution code" error. 

Sometimes, additional information will appear at the bottom of this variable data. For example, maybe it will show:
-- TypeError. Cannot read property "0" from undefined (#3). 

If you are receiving an error like this then it would indicate that the data it is expecting is not available. Continue by researching the "Operation Results" and why the post-execution code thinks data is not available. 

Wireshark

If the problem is related to receiving unexpected results from SDM then using Wireshark can help by confirming the exact request being sent from ITPAM and the response being seen by ITPAM. If you capture the packets via Wireshark then the data exchanged between the ITPAM server and SDM server can be filtered using the filters:

• xml (for all communication between the two servers)
• xml.tag ~ doSelect (for all requests sent by the "Select Object" operator)