Enabling a Disabled Repository - Queued Provisioning Concerns

[brandonbollin]

I have a PROD repository that's been disabled for God knows how long. We need this repo enabled but I'm concerned that if I do that, provisioning events concerning that repo that are queued up will start pushing out. We don't want that. I've written up a refresh process to take what's in the BS-ABAP application and refresh IDM to match it as these systems are not in sync. I don't want queued up provisioning events to mess with the rights on the target system.

Does anyone know a way to query the DB and see if there's events queued up on a disabled repo and how to remove them before we enable?

[todor_petrov · Accepted solution]

Hi Brandon,

that's what the provisioning queue is there for. If the queue is empty, then there cannot be any hidden tasks that will be triggered. For all disabled repositories, the tasks start stacking in the queue and there you also have a column to see for which repository they stack (e.g. see also provisioning view in db).

If there are entries in the provisioning queue for this repository, then those surely will trigger once you enable it. If you want to remove those, there are a number of ways and i suppose you know at least one of them:)

BR,

Todor

[brandonbollin · Accepted solution]

Lol... you know, being out of SAP IDM for nearly two years, it's amazing how much elementary stuff I've forgotten about. Yes, this is the obvious answer and upon executing a query on this, we have 3,200+ lines in the provisioning queue for this repo. Now the question is, if I purge these lines, is that all I have to do? Or should I also search for any lines which share AuditIDs with these lines so any connected events that aren't specifically targeted to this repo but are part of the process also queued up can be eliminated too?

[todor_petrov · Accepted solution]

Hi Brandon,

okay, in this case there are more or less two options:

1. if possible, make sure that the prov. queue does not contain anything else, except the entries for the repo and then simply delete them. Before that you might want to complete there reference audits.

2. The complicated part comes, when there are also other provisioning entries, which should not be deleted. Then i suppose the best case is to find all mskeys, which contains the repoid and then search again by list of mskeys. This way you will capture all entries that might have to be deleted.

Let me know if it worked.

BR,

Todor

[brandonbollin · Accepted solution]

In the end, after reviewing with the client, they actually wanted all the provisioning events for the repo to go through. It was deemed that there was too much potential for important provisioning events to be in there that we'd rather let everything go through and then clean up anything that was off rather than remove everything and try to figure out what was missed.