Michael_Lowry

Deactivating tasks

Discussion created by Michael_Lowry on Sep 18, 2014
Latest reply on Mar 30, 2017 by Michael_Lowry
We have an automated clean-up process that deletes old objects. As a part of this, a Java program lists active tasks associated with an object. It uses the UC4 Java Application Interface and direct queries of the UC4 DB for this purpose.

Until now, we have been operating under the assumption that active tasks with a status code of 1800 or greater can be deactivated immediately without canceling them first, and that active tasks with a status code less than 1800 must be cancelled before they can be deactivated. We have learned however that there are many situations that can prevent a task from being deactivated. For example, we have discovered that a task cannot be deactivated if it has a parent workflow that is still active. Perhaps there are other conditions that can prevent deactivation. Perhaps there exist status codes greater than 1800, jobs of which must be cancelled prior to deactivation.

Moreover, we would like to get a more complete understanding of the criteria that determine whether a task can be deactivated or not, and how to handle the situations where an obstacle prevents task deactivation.

Has anyone else run into this challenge before? How do you handle automatically deactivating a list of objects? If you have a long list of objects of many different types, is there a preferred order in which they should be deactivated? E.g., is it best to deactivate JOBP objects first, and then the other types of objects? Is it necessary to check the status of all child tasks first? Alternatively, has anyone tried parsing the messages returned by DeactivateTask, to make an intelligent system capable of handling all of the obstacles that can prevent task deactivation?

Thanks in advance!

Outcomes