Stuck In Progress Tasks / Events & Garbage Collection

Discussion created by Chris_Thomas Employee on Feb 14, 2012
Latest reply on Dec 6, 2018 by Gabriele_Rusconi-Moviri

[color=#ff0000]***For some reason this post was marked as a draft and attachments were lost during the MyCA upgrade *** Will need to search for attachments and update it again with the supporting information. (pending)[color]

Tasks can become stuck in progress for a variety of reasons, most notably, view submitted tasks shows the task / event as stuck in progress or the associated workflow job is left in an unapproved state.

Task Persistence Database

TP Database structure, which is leveraged by View submitted tasks feature within the IME, involves 5 differet DB tables:

1. event_object12_5
2. event12_5
3. lock12_5
4. object12_5
5. tasksession12_5

The 2 tables that report the state of the task/event are:

event12_5 and tasksession12_5. On both tables there is a field called state which will indicate at the task/event state.

Here is a list of the possible states:

BEGIN_STATE = 0x00; // 0
PRE_STATE = 0x01; // 1
INVALID_STATE = 0x02; // 2
PENDING_STATE = 0x04; // 4
EXECUTING_STATE = 0x08; // 8
APPROVED_STATE = 0x10; // 16
REJECTED_STATE = 0x20; // 32
POST_STATE = 0x40; // 64
COMPLETED_STATE = 0x80; // 128
CANCELLED_STATE = 0x100; // 256
UNKNOWN_STATE = 0x300; // 768
INITIAL_STATE = 0x400; // 1024
PRIMARY_PENDING_STATE = 0x800; // 2048
PRIMARY_COMPLETE_STATE = 0x1000; // 4096
AUDIT_STATE = 0x4000; // 16384

So state 2 is failed as you can see INVALID_STATE.

All the task states are mapped to 'pending' and 'in progress' except for 'completed', 'cancelled' and 'rejected'.

I.e., "In Progress" or "Pending" = TP states 0, 1, 2, 4, 8, 16, 64.

'Failed' tasks do not have a unique state because the tasks can fail during different events within the task. Failed tasks will have the last logged state at the time of the failure which could be one of the pending or in process states.

It's important to keep your task persistence database lean and in peak performance, by regularly implementing OOTB garbage collection procedures here:

If you've neglected to run garbage collection on your submitted tasks within the task persistence database, it's possible that the OOTB garbage cleanup procedure can easily become overwhelmed.. If your garbage collection is taking exceedingly long to complete, you may want to consider implementing this and INITIATION_DATE <{ts '2012-01-04 00:00:00'} This will need to be changed to reflect the current date range when you run this SQL statement.

Additionally attached to this thread is the garbage collection procedure for workpoint specifically.

Selecting only the parent jobs isn't necessary because the Workpoint delete stored procs only delete the jobs where the parent is marked to be deleted. For instance if you update a sub-proc and not the parent, the sub-proc will not be deleted.

Please respond with any questions or concerns.
Thank you.

Chris Thomas
CA Technologies
Principal Support Engineer
Identity Manager Reporting Expert
Tel: +1-631-342-4360