Identity Management processes always involve Request and Approval Workflows. As en example think of the on-boarding process for a new employee where the manager for this employee has to approve some basic permissions like Internet or VPN access in a first approval step. For this scenario, we do not want to "hardcode" the responsible manager for an organisational unit and therefore the employee. Instead we want to reseolve the approver as well as the approvee at runtime. This blog explains how this can be impolemented in SAP NetWeaver Identity Management 7.0.
The following systems / applications have been used in this blog
- SAP NetWeaver Identity Management 7.0 SP02 Patch 2
- MS SQL Server 2005 Database
- SAP NW Identity Management Knowledge
- Basic SQL knowledge
Basic filter functionality in the SAP NW IDM workflow module
The workflow module of SAP NetWeaver Identity Management 7.0 allows to define filters for determining entitled people for defined workflow tasks. With those filter definition you can resolve entitled people by an SQL query, which is in most cases sufficient - at least for tasks other than approval tasks. The following screenshots shows such a filter definition. It retrieves all identities of type MX_PERSON from the identity store, whose language is "German" (just a more or less reasonable example).
Note: To be able to define filter definitions you have to enable the usage of filter definitions in the Acess Contol definition by disbling the Check box "Use simplified access control in the "Workflow" Tab of your Identity Store.
The SQL statement used for the resolution of all eligible persons matching the given criteria is the following. (Assuming the ID Store ID of your Identity Store is 3).
| SELECT DISTINCT mskey FROM mxiv_sentries WHERE is_id=3 AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_LANGUAGE' AND searchvalue = 'DE') AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_ENTRYTYPE' AND searchvalue = 'MX_PERSON') |
Basic filter functionality in the SAP NW IDM workflow module for approval tasks
For approval tasks, not only the identity that is eligible to execute the task (called "Approver") has to be determined but also the one the workflow is executed upon (called "Approvee"). Comparable with the example of a standard workflow task, the approver as well as the approvee can be determined by executing an SQL statement.
Let's assume, we want to enable all german speaking mamagers to approve requests of all german speaking employees. Therefore we would configure the Approver and Approvee Filter in an approval task as follows.
The SQL statement used for the resolution of all approvers (all german speaking mamagers) matching the given criteria could be the following. (Assuming the ID Store ID of your Identity Store is 3 and an additional attribute called "Z_MANAGER" has been created to indicate, if the identity is a manager [TRUE] or not [FALSE]).
| SELECT DISTINCT mskey FROM mxiv_sentries WHERE is_id=3 AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_LANGUAGE' AND searchvalue = 'DE') AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='Z_MANAGER' AND searchvalue = 'TRUE') AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_ENTRYTYPE' AND searchvalue = 'MX_PERSON') |
The SQL statement used for the resolution of all approvees (all german speaking employees) matching the given criteria could be the following. (Assuming the ID Store ID of your Identity Store is 3).
| SELECT DISTINCT mskey FROM mxiv_sentries WHERE is_id=3 AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_LANGUAGE' AND searchvalue = 'DE') AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_ENTRYTYPE' AND searchvalue = 'MX_PERSON') |
Enhanced dynamic filter functionality for approval tasks
Assume you want to inplement the following scenario: We want to enable all managers to approve requests of all his employees (directly assigned to his organisation).
As a prerequisite we again define additional attributes:
- Z_MANAGER => TRUE, id manager of Organisational Unit
- Z_ORGUNIT => Contains the code of the Organisational Unit, the identity belongs to.
For implementing this requirement, it is necessary to consider in the "Approvee" filter definition the currently logged in user, since only with this information, a correlation between the employee and its manager can be established.
The following variables can be used to satisfy this requirement:
- %ADMINMSKEY% => For the user currently logged in user.
- %USERMSKEY% => For the current workflow object.
Therefore we would configure the Approver and Approvee Filter in an approval task as follows.
The SQL statements used for the resolution of the approver (Manager) as well as the approvee (working in the department of the approver) could be the following. (Assuming the ID Store ID of your Identity Store is 3 and the above mentioned attributes have been created and populated).
"Approver" Filter Definition:
| SELECT DISTINCT mskey FROM mxiv_sentries WHERE is_id=3 AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='Z_MANAGER' AND searchvalue = 'TRUE') AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_ENTRYTYPE' AND searchvalue = 'MX_PERSON') |
"Approvee" Filter Definition:
| SELECT DISTINCT mskey FROM mxiv_sentries WHERE is_id=3 AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='Z_ORGUNIT' AND searchvalue = (SELECT searchvalue FROM mxiv_sentries WHERE attrname='Z_ORGUNIT' AND mskey=%ADMINMSKEY%) ) AND mskey IN (SELECT mskey FROM mxiv_sentries WHERE attrname='MX_ENTRYTYPE' AND searchvalue = 'MX_PERSON') |
Summary
This example showed, that it is possible also to use information which is only available at runtime (like e.g. the currently logged in user) for resoving eligible users for approval tasks. This is a very powerful capability that allows to implement complex definitions for permission determination.
