Changing the type to Defect.
Currect logs are hard to understand for production use. Regular monitoring, solving typical support incidents, or connecting new systems would be complicated and time-consuming.
I will try to explain two most common use cases:
Synchronization of source system (HR system)¶
This is usually run very often, at least every day. At the first sight, I need to distinguish these situations:
A) how many accounts of existing identities were handled and the update was successfull. If there are no accounts, or if there are too many accounts, something is probably wrong with timestamps from HR, that should be checked.
B) how many accounts of existing identities were handled and there was some error - Usually error in HR data or unsupported processes
C) how many accounts didn't have identity and IdM successfully created it. Again, if there are no or too many accounts, there could be something wrong - e.g. creating identities for long-left employees, getting no data from HR for new employees,...
D) how many accounts didn't have identity and IdM couldn't create it - Usually error in HR data, I need to solve it immediatelly, because people will come to work on the first day and nothing is prepared for them.
E) how many "missing accounts" are there. It means usually some error in HR system. Those identities are not correctly updated from HR and can be wrongly handled by personal processes.
On the other hand, typical incident: "What happend with user xy, why wasn't (was) he or she updated and what did IdM do". First thing the administrator needs to do is to check, whether the user was handled by synchronization, what type of situation and what action was used, what was the result. Or whether the user wasn't handled at all, because HR forgot to update him.
Reconciliation of a newly connected end system¶
It is usually run several times.
First, I only want to get information about the Situation - which accounts could be linked to identities and which couldn't - without the actual action. This way I will find out if the correlation is correctly configured. I can also send the information about "missing identity" to the system administrator, who should clean obsolete accounts from the system (there is always some old garbage).
After that, I will run the reconciliation for real. I need to know:
A) how many accounts were already linked before the reconcilation - this number is good for checking that no account is missing
B) how many were newly linked to identities - which ID's to which identities. I will check this report with the administrator, who should approve that linking is correct. (Usual problems: people with the same name have mixed logins, mails or employee numbers and their account are linked incorrectly)
C) how many should be newly linked, IdM tried it, but failed - I will need to find the reason why, correct the errors and run reconciliation again
D) how many accounts are still in "missing identity" state - I will send this report to the administrator, who should approve that those accounts shouldn't be handled by IdM. Or he will find out that there is something wrong in the accounts (missing employeeNumber, typo in login or e-mail which are used for correlation, ....) and must correct them.
This cycle is usually run several times, depending on how much garbage there is on the system.
