• Product: RSA Identity Governance & Lifecycle
• Version: 7.0.x, 7.1.x, 7.2.x
• Component: Workpoint Server, Workflow Engine, Change Request Processing
• Tool: SQL Server

RSA Identity Governance & Lifecycle uses third-party software called Workpoint to manage workflow processing queues. When these queues become overloaded, workflows stall and change request processing slows or stops entirely — bringing the application to a virtual halt.

Use this article if you are observing any of the following:

• Workflow stall messages appearing in the application
• Change requests are processing significantly slower than usual or have stopped completely
• The Workpoint server has shut down

CAUTION: Do NOT cancel any change requests or clear queue entries without first following the detection steps in this article. Cancelling valid work in the Workpoint queues can cause data loss or incomplete provisioning.

This article covers two tasks. Complete them in order — Task 2 cannot be performed until Task 1 is complete.

Shared connection details (Task 1):

Task 1: Detect and Terminate the Aberrant Change Request or Workflow

CAUTION: Do NOT cancel any change requests or queue entries until you have identified the specific aberrant workflow or change request. Cancelling valid work can cause data loss or incomplete provisioning.

1. Log in to your SQL tool (e.g., SQL*Plus or SQL Developer) as avuser.
2. Run the following query against the Job monitor table to identify workflows or change requests overloading the queue.

   SELECT * FROM (
     SELECT wpi.cr_id, wpi.name, wpi.proc_state_id, job.*
     FROM wp_proci wpi
     JOIN (
       SELECT proci_id, COUNT(proci_id) AS num_of_work_in_q
       FROM wp_JOB_monitor
       GROUP BY proci_id
       HAVING COUNT(proci_id) > 5
       ORDER BY COUNT(proci_id)
     ) job ON wpi.proci_id = job.proci_id
   )
   ORDER BY num_of_work_in_q DESC;

3. Run the same query against the Alert monitor table.

   SELECT * FROM (
     SELECT wpi.cr_id, wpi.name, wpi.proc_state_id, job.*
     FROM wp_proci wpi
     JOIN (
       SELECT proci_id, COUNT(proci_id) AS num_of_work_in_q
       FROM wp_ALERT_monitor
       GROUP BY proci_id
       HAVING COUNT(proci_id) > 5
       ORDER BY COUNT(proci_id)
     ) job ON wpi.proci_id = job.proci_id
   )
   ORDER BY num_of_work_in_q DESC;

4. Run the same query against the Script monitor table.

   SELECT * FROM (
     SELECT wpi.cr_id, wpi.name, wpi.proc_state_id, job.*
     FROM wp_proci wpi
     JOIN (
       SELECT proci_id, COUNT(proci_id) AS num_of_work_in_q
       FROM wp_SCRIPT_monitor
       GROUP BY proci_id
       HAVING COUNT(proci_id) > 5
       ORDER BY COUNT(proci_id)
     ) job ON wpi.proci_id = job.proci_id
   )
   ORDER BY num_of_work_in_q DESC;

5. Review the query results across all three runs.
   • The cr_id column returns the internal ID of the associated change request. If cr_id is null, the job is not associated with a change request — it is a standalone workflow.
   • Look for the change request or workflow with the highest num_of_work_in_q value.
   • A healthy workflow job should add close to one entry per queue. Entries in double digits or higher indicate an aberrant workflow or change request.
6. If you identify entries in double digits or higher, contact RSA Support. Provide the cr_id, name, and num_of_work_in_q values from your query output. RSA Support will assist with identifying and terminating the aberrant change request or workflow.
7. Verification: After RSA Support has confirmed the termination, re-run the three queries from Steps 2–4. Confirm that the num_of_work_in_q values for the previously identified change request or workflow have dropped to zero or are no longer returned in the results.

Task 2: Clean Up the Workpoint Monitoring Queues

NOTE: Task 2 must only be started after Task 1 is fully complete and RSA Support has confirmed the aberrant change request or workflow has been terminated.

1. Open a support case with RSA Support and inform them that:
   • The aberrant change request or workflow has been terminated (per Task 1).
   • You are requesting cleanup of the Workpoint monitoring queues.
2. Work with RSA Support to complete the queue cleanup. RSA Support will confirm when the cleanup is complete.
3. Verification: After the cleanup is confirmed, monitor the Workpoint queues continuously for a period of time to ensure the issue does not recur. RSA Support will advise on the recommended monitoring duration based on your environment.