CR stuck at Fulfillment Phase

[EmreGuloglu1]

Hi all,

I've faced with an issue on change requests. Eventhough all items in cr are completed and reflected to target system, the cr does not yield to completed state. Going to demonstrate with an example:

Product Version: 7.0.2 P06

• Change request seems it's on Fulfillment Phase

• But overall status of cr is %100 and there is no item which is not completed

• Eventhough all account changes are verified after collection of application, they still seem to wait for verification.

• When an information button is clicked, it points that item is completed.

Kind regards,

Emre

[wjmay]

Have you verified that the item is marked complete in the DB? For example, if operation was Delete Account, is that account marked deleted on AVUSER.T_AV_ACCOUNTS, or for Remove Approle/Ent from Account, verified on AVUSER.T_AV_EXPLODEDUSERENTITLEMENTS?

[EmreGuloglu1]

Thanks for reply William, the operation is 'add application role to account' and account-approle relation is inserted to T_AV_EXPLODEDUSERENTITLEMENTS.

[JoannaYang1]

The watch might closed before change request item completed. 

Running following query, it should tell you if the watch  is closed. 

SELECT CHANGE_REQUESTS_ID, TYPE, OPERAND_TYPE, STATE, DERIVED_TYPE, OPERATION, FULL_OPERATION, VALUE_TYPE
FROM T_AV_CHANGE_REQUEST_DETAILS cri
WHERE cri.state IN('WD','PZ','PV')
AND cri.watch_id IN (SELECT ID FROM T_AV_DATAPROCEVENTWATCHES WHERE status ='C');

If the watch is closed, you need to set their satus to Open (Status='O'), then re-run account collector.

[EmreGuloglu1]

According to your query, nothing returns. So, I assume watch is open. Could you please share if there is anything else to check?

[JoannaYang1]

That was our problem and once we changed watch to open fixed our problem.

[MHelmy]

In cases where the watch is still open, it most probably means the change was not actually performed. I've seen many cases where we would think the change was done but when you look down into how the end-user got/removed the requested access we saw something different. Some examples:

1. A CR was generated to add a Group to a user account which was granted on the target system but not verified.
   1. After checking the internal IDs in the tables, we found that the user was granted the group but through a different account than the one in the CR so the change did not verify.
   2. In these cases it could either be a mistake during provisioning or sometimes a misconfigured collector could be mapping your collected data to the wrong accounts.
2. A CR was generated to remove a group from one user, which was removed on the target system but not verified. In this case it was a problem that the user was still a member of that group through another sub-group relation.

As I said these are only examples but I would recommend you go through your source data and the UI to trace and make sure whatever access changes requested were exactly performed and not something similar.

[MohitVohra1]

Hello Mostafa,

If I go by your statement, then am I correct in interpreting that any change request item where watch status is 'Closed' means the change has actually been performed [even if the request item state is still 'Pending Action']?

I am seeing number of such cases within our current Production instance where the change request item is in 'Pending Action' state [not Completed which the original thread states] but the watch status is 'Closed' - would changing the watch state to 'Open' for such cases and re-running the account / entitlement collector or both help mark the change request item to 'Completed' state? [depending on whether its RemoveUserFromEnt / RemoveUserFromAppRole / RemoveUserFromGroup  as for these we'll need to run entitlement collector as well or DeleteAccount for this we'll need to run ADC]

[MohitVohra1]

Hello Joanna,

Did you also try the same approach [changing Watch status to 'Open' for closed instances where CRD.State = 'Pending Action' [i.e. the request item state is not Completed] and then re-running the collector? Just keen to note if you noticed any cases like that in your instance [where change request is in Pending Fulfillment state, request is in Pending Action state but the actual action has been performed in end application [the app team says they've removed it but its not reflecting in Aveksa]