Issue with Approval Item Rejection after Work Item Expiry in QA Environment

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

8.5

Hello Everyone,

I have updated the After Script in the Provisioning Approval Subprocess to mark the approval items as Rejected if the associated work item has expired. When I test this locally, it is working perfectly fine. However, in the QA environment, after the expiration occurs, the following error appears on the Access Request page:

“Error: This request timed out waiting for one or more items.”

Although the approval items get rejected and the IdentityRequest is marked as completed, this error still occurs.

Do you have any ideas why this might be happening?

Additional context / question:

Also, could you please provide insights on why this behavior is as expected in my local environment (where I am using Time Machine to simulate expiry) but not in the QA environment?

After Script:

import sailpoint.workflow.IdentityRequestLibrary;

import sailpoint.object.WorkItem;

import sailpoint.object.ApprovalItem;

import sailpoint.tools.Util;

import org.apache.log4j.Logger;

Logger workflowLogger = Logger.getLogger(“workflow.LCM.ProvisioningApprovalSubprocess”);

workflowLogger.debug(“Entering After Script”);

if (item == null)

return;

// Handle Expired work item before assimilation

if (WorkItem.State.Expired.equals(item.getState())) {

// Ensure all approval line-items gets rejected if workitem is expired

if (approvalSet != null) {

    List aitems = approvalSet.getItems();

    if (!Util.isEmpty(aitems)) {

        for (Object obj: aitems) {

            if (obj instanceof ApprovalItem) {

                ApprovalItem aItem = (ApprovalItem) obj;

                aItem.setState(WorkItem.State.Rejected);

            }

        }

    }

}

}

assimilateWorkItemApprovalSet(wfcontext, item, approvalSet);

auditDecisions(item);

IdentityRequestLibrary.assimilateWorkItemApprovalSetToIdentityRequest(wfcontext, approvalSet);

workflowLogger.debug(“Exiting After Script”);

3

Thanks for letting me know Kannan,i’ll give it a try

4

@LohithHarish Is it possible for you to share the complete workflow to review if there is any more customization? assimilateWorkItemApprovalSet and assimilateWorkItemApprovalSetToIdentityRequest should take care of updating request in case of rejection.

5

Sure NeelMadhav

ProvisioningApproval-Subprocess.xml (25.3 KB)

6

Thanks @LohithHarish Let me check and get back.

7

Hi Lohith,

When Work Items expire, the UI times out because the IdentityRequest sees the items as Completed but not fully Finished. The reason it works in your local Time Machine setup but not in QA is likely due to thread timing. Locally, everything is often happening in a single execution context, but in QA, the background task for expiration is fighting with the UI’s polling mechanism.

The fix is to set the Provisioning State when rejecting expired items so the request stops waiting.

if (WorkItem.State.Expired.equals(item.getState())) {
    if (approvalSet != null) {
        List aitems = approvalSet.getItems();
        if (!Util.isEmpty(aitems)) {
            for (Object obj : aitems) {
                if (obj instanceof ApprovalItem) {
                    ApprovalItem aItem = (ApprovalItem) obj;
                    // Mark as rejected
                    aItem.setState(WorkItem.State.Rejected);
                    // CRITICAL: Tell the IdentityRequest this item is finished 
                    // and won't be sent to the provisioning engine.
                    aItem.setProvisioningState(ApprovalItem.ProvisioningState.Finished);
                }
            }
        }
    }
}

In addition, please do check that you are passing the item to the assimilation call if you want the library to handle the state transition automatically:

IdentityRequestLibrary.assimilateWorkItemApprovalSetToIdentityRequest(wfcontext, item, approvalSet);

Give a try in QA, it should work.

Regards,

Kannan

8

Thnaks for the reply kannan, Could you please suggest a way to replicate the same issue in local

9

@LohithHarish - I understand your point, but the local environment usually wont behave the same. In this case, I am not sure whether the issue can even be reproduced locally. Were you able to test the scenario I mentioned in the QA environment.

-Kannan