So I'm struggling a bit with NWIDM 7.2 SP4. When I create new users and assign business roles and privileges manually to the users, they are provisioned perfectly. However when I want to update a role (assign a new role and/or privilege to the user), the changes are never provisioned. The only time the user is actually resent to the target ABAP system is if I change an attribute on the MX_PERSON entry type (if I change a name, email, phone number, etc.). At that point, the entire user is sent to the target system and the privileges are assigned just fine.
This problem only started happening after applying SP4 to this system. When I was on SP3, I was able to add/remove privileges and roles and the provisioning was working fine. I am using everything standard out of the SAP to ABAP provisioning framework, no custom jobs or tasks at all. I find that if I remove ALL business roles from the user (which effectively deletes the user in the target system because the PRIV:<REPOSITORY>_ONLY privilege is contained in the business role then add it again it works. I assume this is because it is triggering the Create user task instead of the Modify task.
When I look at the Provisioning Audit, I see that when I modify something like the Name of the user, then the following string of tasks happens:
1324/Modify Identity --> 751/Modify -> 660/2. Modify BS User takes place.
When I just update a role or a privilege, the 1324/Modify Identity runs, but doesn't kick off any further tasks.
From reading, I've been led to things like the MX_RECONCILE global variable (which I have set to TRUE). My understanding of this is that it should provision users automatically if I add a new privilege to the role. This shouldn't have anything to do with my problem above, but thought it might be important in this post. The other thing that I'm reading about, but don't fully understand is the use of the MX_MODIFYTASK_ATTR attribute. Currently, that is empty and the MX_PRIV_MODIFY_POLICY is not in my Global constants. From what I understand if MX_PRIV_MODIFY_POLICY is not there, then ANY change to the user (and I consider adding a new role a change) will result in the user being provisioned.
I must be missing something, so any input would be appreciated.
You issue seems to be the reconciliation of dirty entries. A dirty entry is what you've described, changing a BR that is already assigned to a user and wanting the user to be provisioned these new assignments. There are several options for reconciling these entries.
You can run a standard job, "reconcile dirty entries."
The MX_RECONCILE global variable will automatically reconcile dirty entries. You understanding is a bit flawed, it does not relate to provisoining when a user is assigned a privliege. It relates to provisioning when a entry is dirty (their BR assignments changed in some way).
The MX_MODIFYTASK_ATTR relates to triggering a modify action when a certain attribute is changed. This gives you control for when a modify task will be triggered. For example, at my current project, we only want a modify task to trigger when MX_DISABLED gets triggered. This attribute also relates to the system privilege (PRIV:SYSTEM). On these privileges is where you set which attributes will trigger a modify task. So both this constant and the way you have configured system privileges work together.
I can't comment on the way that SP3 and SP4 are different, but my guess is that you either had automatic reconciliation enabled previously, or the web task that you had configured had a reconciliation subtask executing that was reconciling things properly.
Both processes you've outlined are a bit complex, so let me know if you have additional questions and I will try to clear things up for you.
Thanks for the reply. I think the MX_RECONCILE is behaving like it should. For example, when set to TRUE, when I add a privilege to the role the mxiv_dirty_entry view has no records in it and when I change something else on the user, the new privilege gets added in the target system. When it is set to FALSE, the mxiv_dirty_etnry view has some records in it and is cleared out once I run the "dirty entry" job. This works as it should. The issue is that either way, the role change to a user (through the change person task, or the assign task, or the change business role task, or even after running the dirty entries job) has no affect on actually triggering a provision to the target systems. It is only when I change an attribute (other than role or privilege assignment) that the user and roles/privileges are distributed to the target system. I'm trying to find out how I can get that provisioning to work when the only change to a user is by adding a role or privilege to him in the IDM.
On the repository you want to provision to, go to Event Tasks tab -> Assignments Section.
Add task and Remove task need to be pointed at Provisioning and Deprovisioning respectively. Are they?
If they are and you're still not having luck, please make sure your system privilege and master account privilege are in the system and configured properly. (PRIV:SYSTEM:<repName> and PRIV:<repName>:ONLY).
Perfect Chris. It was an issue with the Modify Task Trigger Attributes in the Repository. MXREF_MX_ROLE and MXREF_MX_PRIVILEGE were not set as a Triggering Event. I find this a bit odd though, as I'm the only one working in this system and can't for the life of me remember even updating this section of the Repository. Stranger things have happened, so I'll just blame this on short term memory loss.
Now for a quick validation question:
What I'd like to happen is that when I manually change the role and/or the privilege assignment on a person, I want the provisioning to happen immediately. If I am adding a new privilege to a role, then I am OK with marking that role as dirty and running the update dirty job after hours which I expect to update the privilege assignments and provision the changes to the target systems.
With that requirement, I believe this is what I need to do, but would like to double check:
1. On my PRIV:SYSTEM:<Repository> privileges, mark the MXREF_MX_ROLE and MXREF_MX_PRIVILEGE attributes as Triggering events on the Tasks tab of the Repo. This should tell the system that when this attribute changes, I want to use to trigger changes to the target repository system
2. Set the global constant MX_RECONCILE to FALSE
3. Schedule the "Reconcile dirty entries" job to run daily after hours.
Can you let me know if that sounds about right? Is it not Best Practice to trigger changes to the target system immediately after a role or privilege assignment changes? I would expect that when a user requests a role change, they should get that as soon as it is changed.
1. You won't want to make MXREF_MX_ROLE and MXREF_MX_PRIVILEGE as triggering events, because you won't want to have a modify action run on those, you'll want an assignment task to run which is either under "provisioning" or "deprovisioning" in the framework. If modify runs every time an assignment changes, this will hurt performance. Assignment actions will get handled by your event tasks on the repository: Assignment/Add task and Assignment/Remove task.
2 and 3. Yes that will work.