000037452 - Change Requests sometimes complete but bypass both AFX and manual fulfillment and fail to modify the endpoint in RSA Identity Governance & Lifecycle

Document created by RSA Customer Support Employee on May 9, 2019•Last modified by RSA Customer Support Employee on Dec 13, 2019
Version 4Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000037452
Applies ToRSA Product Set: RSA Identity Governance & Lifecycle 
RSA Version/Condition: 7.0.2, 7.1.0
 
IssueIntermittently, change requests in RSA Identity Governance & Lifecycle complete but bypass both AFX and manual fulfillment and fail to modify the endpoint. 

When this occurs, the processing workflow of the change request may be missing the sub process nodes as in the example below.

User-added image



The same change request using the same workflow sometimes works. In this case, the processing workflow of the change request contains the expected sub process nodes as in the example below.
 



User-added image




Sometimes both behaviors may be exhibited in the same change request. That is, two different change request items may show as completed but one change request item provisions to the endpoint and one does not (i.e. skips AFX and manual fulfillment.)

The aveksaserver.log file may show the following exception:
 




06/28/2019 01:40:10.648 ERROR ([ACTIVE] ExecuteThread: '94' for queue: 'weblogic.kernel.Default (self-tuning)') 
[MessageSubscriber] Listener threw during Message notification, for listener AuthorizationServiceProvider
java.util.ConcurrentModificationException


Please refer to RSA Knowledge Base Article 000030327 -- Artifacts to gather in RSA Identity Governance & Lifecycle to find the location of the  aveksaServer.log file for your specific deployment.  
CauseThis issue may occur if the first node of the request workflow is a fulfillment node instead of an approval node.   

Although the main workflow items associated with the change request are created immediately, the sub-processes for the workflow are instantiated when Workpoint encounters the fulfillment node in the workflow. In a typical workflow, the request will pause at the approval node before moving on and this allows time for the main workflow to be created before the sub processes are created. In some instances, if there are performance issues, the system may not have time to create all the sub processes correctly. This may affect some or all of the items in the request.
 
ResolutionThis issue is resolved in the following versions:
  • RSA Identify Governance & Lifecycle 7.0.2 P08
  • RSA Identify Governance & Lifecycle 7.1.0 P02
  • RSA Identify Governance & Lifecycle 7.1.1 
WorkaroundThe workaround is to add a non-operational (dummy) approval node as the very first node in your approval workflow.  To do this you would add a normal approval node and set the settings under Behavior to Do Not Process, as shown:

User-added image



This will essentially create an auto-approval node. The only downside to this would be that the workflow would have a bit more overhead, but not significantly so. This node may be removed once the appropriate patch is installed.

Attachments

    Outcomes