Exception Handling - Retry SDM login for SID

[J W]

PAM 4.3.1 integrated with SDM 14.1.03

CA Process Automation Sample Process Definitions for CA SDM for SDM 14.1 imported.

 

I am using the sample Exception Handler that comes with the SDM process definitions.  They trap 'System_Error', 'Unidentified_Response', and 'Aborted' exceptions.

 

I am developing processes that kicks off from SDM tickets, gathers initial ticket and contact information, and then continues to assign tasks to contacts and move forward as needed.  It is expected to take days between completion of tasks, so the initial SDM session id (SID) will timeout after an hour. 

 

The exception handler was designed to trap this event and automatically login again to get a new SID. This is handled by the 'Unidentified_Response' operator. 

///////////////////////////////////////////////////////////////

Process.exceptionType = "Unidentified Response"
Process.source = Process.Unidentified_Response.source
if(  Process[Process.source].Reason.indexOf("Service Operation succeeded. Fault returned.") != -1 )
{
  Process.errorMessage = Process[Process.source].FaultMessage;
  Process.sosfr = true;
}
else
{
  Process.errorMessage = Process[Process.source].Reason
  Process.sosfr = false;
}

//////////////////////////////////////////////////////////////

 

But what I am finding is that this works as designed when the operator has no Post_Execution code to process the web services response. The Reason is 'Service Operation succeeded. Fault returned' and the Fault Message is:  soapenv:Client 1010, which is expected for a bad SID and is returned from the Operation Results.

 

However, it is not working when there is Post_Execution code. Instead, the error that is trapped is the Aborted type and reported by the System Results and the Reason is usually 'msg.valuemap.unexpected.field.type'  - because the web service call failed and so the assignment fails because the response is empty.  However, when I look at the Operations Results, the Fault Message is still the same 'soapenv:Client 1010'.

 

The Aborted handler script is:

//////////////////////////////////////////////////////////

Process.exceptionType = "Aborted"
Process.source = Process.Aborted.source
Process.errorMessage = Process[Process.source].Reason

///////////////////////////////////////////////////////////

 

It doesn't matter if it is the standard SOAP operator or the SDM Custom Operators.

 

So, I'm trying to figure out why this is the case that the 'Aborted' is handled instead of the 'Unidentified_Response' when the latter occurs first.  Are all the faults evaluated before the handler picks them up?

 

If I reset the process and remove the Post_Execution code, then the retry works again, but I see that both  types of exceptions are tripped.

 

 

And, of course, there is no error is there is a valid SID.

 

I seem to remember that there was some special use of the sosfr flag, but that was for creating custom operators and this occurs with the standard SOAP as well.

 

TIA,

 

J.W.

[Legacy User]

Hi JW, I've got what I now realise is the same issue, but in my context it occurs quite rarely (presumably when SDM is under heavy load) and I hadn't worked out what was going on underneath - I look forward to hearing what responses you get.

Regards,

James

[Andrew Thompson]

The post-execution code tries to run even if the operator itself fails and if the post-execution code fails, the error from that overrides any previous errors in the operator.

 

In this case, the soap fault can be found by drilling into the dataset.  Click on the failed operator and in the dataset expand the "Operation Results" folder.  Under that you should see the "Fault Message" which in your case is

 

soapenv:Client

1010

 

representing the invalid SID.

 

So that message is actually stored in a variable like: Process.Invoke_SOAP_Method.FaultMessage

[J W]

Andy_Thompson

 

Thanks, that was it exactly.  I had tried to add the same conditional check format from the "Unidentified Response" handler to the "Aborted" handler earlier but it still aborted without retrying.  That was because I was trying to use "Process[Process.source].FaultMessage".  Looking at your response made me rethink that and I changed it to "Process[OpName].FaultMessage" and it picks it up every time.  I have tested this on processes with downstream operators several days after start and it is working great.

 

For those of you looking to the final code, here it is:

 

In the javascript under the Aborted handler:

 

Process.exceptionType = "Aborted"
Process.source = Process.Aborted.source
//Process.errorMessage = Process[Process.source].Reason

if(  Process[OpName].FaultMessage= 'soapenv:Client 1010' )
{
  Process.errorMessage = Process[Process.source].FaultMessage;
  Process.sosfr = true;
}
else
{
  Process.errorMessage = Process[Process.source].Reason;
  Process.sosfr = false;
}

Note that I commented out the original static assignment.  Compare this to the same code under "Unidentified Response".

 

Thanks,

 

J.W.

 

#soapenv:client