We have several entries in the provisioning queue where we are trying to understand why they are not being processed or cleared from the queue successfully for specific mskey #'s. I have read Steffi's blog post SAP IDM: Provisioning is stuck (yet again) - My checklist. In particular, we executed step 3 'Check for waiting tasks via the SQL developer' with no success.
I'll try to explain the scenario here. I want to get a 2nd opinion to see if this would negatively impact the mskey #/system that I'm not aware of before executing in production? Or, are there other areas to investigate that I'm missing? We are on IdM 7.2 SP8 (one of the earlier patch levels) with DB2.
The entry is active within IdM (MX_INACTIVE = NULL). Here's the provisioning queue for the specific MSKEY # that I changed (i blocked out the MSKEYVALUE from MSG):
This has been in the provisioning queue for several months with nothing being done. Here's a screenshot of the provisioning status of the auditid that it's waiting for (1100 = OK):
I continue to look at the REFAUDIT to see if I can see anything there.
The auditref has a status of 20 (Pending), which is the parent ordered task that started the chain of events. However, not all of the tasks/jobs have finished as one of the tasks has a status of 5 (Waiting). For some reason, the entry in the provisioning queue with a state of 24 is not finishing to kick off the task that has a status of 5.
At this point, I tried a few things since I'm working in a non production system. This is where I landed by executing the following SQL statement.
update mxp_provision set state = '2' where mskey = 2282651 and actionid = 1003557
This updated the state from 24 (Wait for event task status) to 2 (Ready to Run). This cleared the provisioning queue for the mskey #. Looking at table MXP_AUDIT PROVSTATUS changed from 20 to 1101 for the parent ordered task.
MSG: Error in expanding linked tasks (3): -803:SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint Task:1003557
This accomplished my goal of cleaning up the provisioning queue for that specific MSKEY #. The attributes for the MSKEY # did not change (which was what I wanted as well). And, nothing showed up in the system/dispatcher/job logs.
In addition, I tried variety of other direct database updates to mxp_provision, but didn't go as far as deleting anything. Example, I changed the sate to 21 (Expanded OK), whic didn't do anything.