|Applies To||RSA Product Set: RSA Identity Governance & Lifecycle|
RSA Version/Condition: 7.0.x, 7.1.x, 7.2.x
|Issue||RSA Identity Governance & Lifecycle uses third party software called Workpoint for workflows. Workpoint server monitors provide a way of monitoring the Workpoint queues to ensure that workflows are running smoothly. If these queues become backed up, workflows can stall and at times the Workpoint server can shut down. At this point change requests stop processing and the RSA Identity Governance & Lifecycle application may come to a virtual halt.|
This RSA Knowledge Base Article explains how to detect what is causing stalled workflows and/or the Workpoint server shutdown, and how to rectify the situation.
|Resolution||The Workpoint server slows down and possibly halts when the Workpoint queues become overloaded and cannot keep up. The first signs of this happening are workflow stall messages and slowing down of change request processing. Both good and bad design of workflows and change requests can cause this situation. For example, a perfectly valid change request that generates ten million items with one job per item can cause the Workpoint server to slow down. Over time a large change request that causes this slowdown will usually clear up on its own. But what if there is an aberrant or poorly designed change request? Workflows can operate independently from change requests such as custom tasks or rules, etc. What if one of these workflows becomes aberrant or is poorly designed?|
Consider the following analogy. Traffic may be slow because there is an accident on the highway. Or it may be slow because there are too many cars on the highway. Either way, the situation will usually resolve itself given time. However, consider the situation where one person (WF JOBS) is driving 1000 cars (Work in the Queue). This will cause the Workpoint monitor to shutdown.
There are two parts to this resolution:
|Notes||See related RSA Knowledge Base Articles:|