Skip to Content

Introduction

The enhanced approval mechanism was introduced with SAP NetWeaver Identity Management 7.2 SP4. The purpose was to add more functionality as well as improve performance.

This post will attempt to clarify how the basic approvals are handled when the 7.2 approvals are enabled. It will explain why you won’t always see the approvers for the basic approvals in the “Approval Management” of Identity Management Administration User Interface.

Defining the basic approvers

For basic approvals, the approvers are defined on the task, and it uses the same mechanism as the access control. This may include using an SQL filter, to determine who is allowed to approve. This gives you a really powerful way of defining the approvers, but also has some drawbacks.

In the following example, I’ve defined a role called ROLE:APPROVER. A user with this role is allowed to approve, but is only allowed approve users within the same cost center, i.e. with the attribute MX_COSTCENTER with the same value.

The approver definition looks like this:

BasicApprovalAccessControl.png

The filter to select users within the same cost center may look like this (on Microsoft SQL Server):

 

SELECT DISTINCT mskey

    FROM idmv_value_basic with (NOLOCK)

     WHERE IS_ID=1 AND

     ((mskey IN (SELECT mskey

        FROM idmv_value_basic

        WHERE AttrName=‘MX_COSTCENTER’ AND

        SearchValue = (select aValue

                          from idmv_value_basic

                          where AttrName=‘MX_COSTCENTER’ and

                         MSKEY=%ADMINMSKEY%))))

During execution, the %ADMINMSKEY% will be replaced by the MSKEY of the approver.

Determining the approvers

To determine the approvals for a given user, each and every pending approval must be checked. This evaluation is done when the To Do tab is opened. So for everyone who is a member of ROLE:APPROVER the system will have to check all the pending approvals to see if the target of the pending approval is in the same costcenter as the logged in user.

It is not possible to “reverse” the statement to get all the approvals for a given user(%ADMINMSKEY%).

As a side note: determining approvers for assignment approvals is simpler, as this will always be a list of users, privileges or roles, which can be expanded immediately.

Performance improvement for basic approvals

A major performance improvement was done with handling basic approvals, as the approver information is saved, which means that each approver only needs to run the above check once, for each new approval.

Whenever an approver is calculated, this approver is added to the internal approval data structure, which means that subsequent listing of approvals is very fast, compared to having to calculate this every time the user lists the approvals.

The MX_APPROVALS attribute

The MX_APPROVALS attribute is (as before) written to entries where an approval is pending, but is not used during the approval process. Therefore, if you have code which has manually changed this attribute, this will not have any effect on the pending approval.

Approval management

With the 7.2 approvals, we also added approval administration, both for manager and for administrator. This works fine for the assignment approvals (which are always expanded), but for basic approvals, you will only see approvers which have actually listed their approvals in the “To do” tab, and as a result, being added to the mxi_approver table.

Summary

Because of the possibility to use filters for defining approvers for basic approvals, it is not possible to expand the approvers initially, thus it is not possible to send notification messages. In addition they will not be shown in the approval management for the manager, until they have been expanded.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply