IT Process Automation

I have a process that updates the category of a change order in SDM.  It's aborting and not finishing.  It has a handful of operators, logs into SDM, updates the category, then logs out of SDM.  The update operator is a soap call and isn't returning any info.  The only info I found was in the logs, Abort Request, "Process aborted by "user".

Even though it's aborting, the operator is updating the category correctly in SDM.

I did test the process by hardcoding the variables.  It finished successfully.  It's only aborting if it's called by another process.

Hi Scott.  I'm wondering about how the process is called from the parent process since that seems to be the scenario when the failure occurs.  In the "Start Process" operator on the parent, is the mode set to "Detached" by any chance?  This mode tells PAM for the parent to either keep control of the child process or let the child go off on its own which may be why the abort has to happen to end the child.  

Is there an exception handler on this process? And if so, are we performing the exception handler and perhaps that is aborting the process?

Also, could be that PAM is waiting for the response from Service Desk and when the response isn't fast enough, it times out.  That would explain why SD completes the request anyway even though PAM has timed out waiting on the response.  Is there a timeout on the operator?  Can you tell how long the operator runs before it times out?  If there is a time out, that might cause the exception handler to activate as well which may cause the abort.

Andrew, thanks for responding.  I reviewed the settings starting with the mode.  It was running in attached mode, so I changed it to detached and tried again.  This time the main and the subprocess finished successfully.  This makes sense with what support was saying.  Updating a category could affect the tickets attached workflow.  Since the subprocess is the last operator in the flow before completing, running in detached mode allows the main process is finishing before updating the category.

thanks again.

If your process is being launched by it's association to the Change Category then this all makes sense. Changing the Category tells Service Desk you want to cancel the workflow process (the one associated to the old Category) and then launch the workflow process associated to the new Category (or none if there isn't any associated).

By running a separate process (detached) from the main process, the sub process is not affected by this.