All about pending values - I

[former_member192665]

A good topic to start this blog with is something that some if not most SAP NetWeaver Identity Management beginners have problems with. The concept of pending values.

Pending values have been introduced to SAP Identity Center with version 7.0 SP2. A pending value is an object in Identity Center which represents an attribute value which is not yet valid (for whatever reason) or in other words: pending.

Why can a value be pending? Mainly because of 2 reasons: First of all the attribute might become valid only in the future and second and more importantly, the attribute might be subject to approval. Both these 2 use cases can be very elegantly implemented with pending values in Identity Center.

Let's start with approvals, this will keep us busy during the entire part I, in part II we'll handle attributes which become valid in the future.

In most situations if you assign a role to somebody or if somebody applies for a role the gain in authorization must be approved by somebody, be it the role owner or the manager of the requestee or both. Let us build a role assignment in Identity Center and let this assignment be approved by an approver.

In order to create test data, I've created a simple job in the job folder that creates a role which you can see here:

Pretty basic stuff, except for the attribute MX_ADD_MEMBER_TASK attribute, perhaps. I execute this job and check the result in the DB:

The value of the MX_OWNER attribute is the mskey of the administrator, so everything as expected. The effect of the MX_ADD_MEMBER_TASK attribute is that when a user is assigned to this role, instead of applying the membership immediately, task 289 is started. 289 is nothing special, it is just an id that Identity Center has assigned to a task that I have developed for this blog and that you can see here:

Below the ordered task group of task 289/Approval Task you can see an approval task ("Here is the approval") and another task called "Appy Pending Value" (we'll come to that later). The "Set MX_APPROVERS" task computes the approvers, but I'll cover this later as well. For the moment it is important to understand what happens if somebody tries to assign a user to this role. Let's do so by a simple job which sets the MXREF_MX_ROLE attribute on a user:

Now let's execute this job. By the way it does not matter that this assignment is not done by a UI task (at least not for what I'm trying to demonstrate here). What happens? I said above that when this attempt to make this assignment takes place task 289 is started.  But which is the object that is passed as an argument to task 289? The user? The role? No. The answer is: A pending value is created and this pending value will be passed to task 289 for execution. This pending value represents the linkage of user ULLRICHK to role "Test Role for Kais Blog": The assignment is pending until approved.

But let's get away from pure theory and dive into practice. After execution of the job a little digging in the database brings up the pending value:

Let's recap a bit. I said the pending value stands for an attribute value which is pending something. How does the above print out reflect this? Let's go through it attribute by attribute:

• MSKEYVALUE. Simply the ID of the object. Is always MX_<mskey>
• MX_ENTRYTYPE. Nothing to explain here
• MX_ENTRY_REFERENCE. This is a reference to the object that is about to be modified. 1006 is here simply the mskey of user ULLRICHK.
• MX_ATTRIBUTE_NAME. Name of the attribute that is going to be written. This is "MXREF_MX_ROLE", as you can also see in one of the previous screenshots.
• MX_ATTR_STATE. Very important attribute. This tells us what this object is waiting for. 1 means pending approval, 2 means pending enable, or in other words: Valid from date is a date in the future. 3 means declined. And there are of course a couple of error codes.
• MX_APPROVALS. Used internally for approvals.
• MX_APPROVERS. Multi value attribute which contains a reference to an approver. Here, 1016 is the mskey of the Administrator user.

MX_ATTR_STATE=1 tells us the pending value is ready for approval and 1016 (=Administrator) is the approver. So the administrator should see something in her inbox. Let's check this:

This is what the Administrator user sees on her To Do tab. Let's click on the item.

Even though there is some work left to do regarding the attribute labels we are able to approve this request. Let's click "Approve" and check how user ULLRICHK looks like in the DB after that:

So after the approval the role assignment has really been carried out. What has happened to the pending value? The query used before

select attrname,avalue from mxiv_sentries where mskey=1057

gives us an empty result. Why? After approval, all pending values are deleted and go to the history database: The query from the history database

select attrname,avalue from mxiv_oentries where mskey=1057

gives us

Please note that we have 2 values of MX_APPROVALS, one is the initial value that was valid when the object went into the approval task and the second one is the update after the approval took place.

Now let's talk about the "Apply Pending Value" task. It is responsible for converting the "pending" assignment into a "real" assignment. The only thing it does is executing a little script, this script calls the built-in function uApplyPending as can be seen below:

// Main function: ApplyPending
function ApplyPending(Par)
{
    mskey = Par.get ("MSKEY");
    uErrMsg (1, "Pending Value being applied: " + mskey);
    outString = UserFunc.uApplyPending (mskey, 0);
    return
}

But what would have happened if the Administrator had declined? Let's open the corresponding branch in the workflow tree:

The task "Set State to Declined" simply sets the state of the object to 3. The effect is that when applied subsequently, the pending value object is simply deleted without applying the role membership to the user.

The only thing that's left to be explained is the Set MX_APPROVERS task. Here is what it does:

And the Util_GetAttributeByMSKEY script looks like this:

// Main function: Util_GetAttributeByMSKEY

function Util_GetAttributeByMSKEY(Par)
{
    var args = Par.split("!!");
    var mskey = args [0];
    var attrname = args [1];  
    return uSelect ("select avalue from mxiv_sentries where attrname = '" +
              attrname + "' and mskey = " + mskey);
}

This task simply reads the contents of the attribute MX_OWNER of the role being assigned and writes it into the MX_APPROVERS attribute of the pending value. (Please note that this task only works fine if you have one single role owner, multiple role owners and roles as role owners need a more sophisticated handling.)

Thanks for reading. Hope you have liked it. Stay tuned for part II where I'll explain how to deal with attributes which become valid only in the future.