1 2 3 10 Previous Next

SAP Identity Management

147 Posts

“Logic is the beginning of wisdom; not the end.” – Spock, Star Trek VI

I've been getting a lot of questions about managing external sources with IDM from a best practices perspective.  While I am not employed by SAP, I thought I would take the opportunity to share a few thoughts on this from both a logical viewpoint, along with my observations of watching people work with SAP IDM all these years.


Strictly from a compliance and governance standpoint, I've always been a fan of having IDM manage as much as possible. Reducing the use of disparate tools to manage digital identities in the SAP Landscape and the greater Enterprise will make your Internal Audit and Information Security groups happy. When we can centralize on a common tool that is capable of recording identity life cycle actions, approvals, notifications, escalations, delegations, etc., we make another step towards greater security and safety in our organizations.


Furthermore, since we can now put this all into a single tool, the Identity Management / Information Security team can create customized tasks and workflows to enable greater availability for these services to technical and non-technical managers, and in limited use cases, the users themselves (Self Service Password Reset and changes to personal data come to mind)


Ok, so this makes IDM the great equalizer.  Woo-hoo! Does this mean that we can only make changes to managed systems through IDM? I don't think so.


Managing the data in a system/repository from IDM is all well and good, but management of the system by its administrators should not be restricted. While I would say that it is a best practice to manipulate the data as much as possible via IDM, maintenance need not require IDM.


Administrators usually need to get deeper into the system and do more than IDM can support, so using IDM for everything in systems such as Active Directory or HCM might just not be possible. My advice to those that ask me would be as follows:


  • Whenever possible, work should be done through an audit-able system that requires logging in
  • All work sessions should be recorded in a log, along with a summary of work done, particularly when there is no login or access prompt
  • Maintenance to Production systems should always follow an established change control process
  • When doing maintenance, follow a "two-person" rule, where changes are verified by at least one other person, when data files, deletes, or modifications are being done on a large scale
  • Finally -- DOCUMENT EVERYTHING!!!!! I can't emphasize this one enough. Make sure there are thorough notes detailing what is being changed, anticipated results, scope of change, details of change, documented code, and so on.  You just can't have enough documentation.


Again, these are my thoughts on the issue.  I'd be interested in hearing yours.

Hi guys,


I have decided to present our custom extension for the standard IdM Password Change UI:

PWR Add-on.png

Here are some of the standard IdM Password Change limitations:

  • doesn't support dynamic account generation based on the user access
  • not possible to select just one or two of the available systems
  • not possible to have a password provisioning status update
  • mobile version - not supported
  • not very user friendly UI

So we have decided to create a custom solution using SAPUI5. Our UI dynamically generates the available systems based on the logged user information and allows to select only the systems you want for password change. As well, we have added a progress status and system status, so in case the password provisioning fails in IdM/back-end you will have UI error state for the failed systems. The users can also log in from a mobile phone/tablet and change their password from there.

For a similar solution you will need IdM&SAPUI5 knowledge and additional IdM development for the UI REST calls and the password provisioning logic.

In IdM you have to create 2/3 UI tasks responsible for the user data display and for the GET/POST calls to IdM, additional entry type is needed. Depends on the customer needs, you have to create additional attributes responsible for the status update and the system provisioning. For the back-end systems you will have to create a custom password change task instead of the standard one.



Kind Regards,

Simona Lincheva

We have just released SAP Identity Management 8.0 and it has General Availability now.

First several customers have successfully completed upgrade projects from Identity Management 7.2 to IdM 8.0 and new installations of IdM 8.0 during customer validation and ramp-up phases.


SAP Identity Management 8.0 comes with the following main improvements:

Innovative design-time IdM Developer Studio as Eclipse plug-in. It replaces the Identity Center Management Console and comes with new configuration packages concept and better usability as well as multi-user environment. Supports Visual Workflow Design which allows you to visualize conveniently and to drag and drop processes in a workflow diagram

• Extended integration capabilities with SAP products with SAP SuccessFactors connector

Improved security concept


You can get more insights in the following blogs:



More detailed technical information can be found on the SAP Identity Management 8.0 help portal and Release notes.

This issue is reported by many customers.

A proper note will be created but I will also have it explained here as well.


So the situation is as follows. A user in the database has his password changed. Then the customer expectation is that when the dispatcher is restarted it should work again. This is wrong. You should change the password in exactly two places and regenerate the scripts in order this to take effect.


1) If we are speaking about the RT user you need to change the JAVA RT properties first


2) Then you need to change the Windows RT connection string


3) Do not forget to press APPLY otherwise your changes won't be saved


4) Regenerate the scripts and then try to start the dispatcher it will be all fine now.

Every day it is fantastic to see the collaborative efforts in the IdM community with some really talented IT experts sharing their knowledge (Topic leader board take a bow :-)    ) with the greater IdM community. At times IdM can be complex when trying to realise the goals/processes set out in a project.


A possibly over looked tool beside the community forum is the SAP wiki. The main aim of the wiki is :



  • Create findable, usable content (solutions)
  • Capture within the workflow: solutions are in the context of a target
  • Just in Time: solutions are easily improved over time based on demand
    and usage (edit as you go)
  • Opportunity to reward contributors based on knowledge they share


There are already some really useful wikis like the Troubleshooting Guide that can help when setting out on the IdM journey.





idm troubleshooting guide .PNG


The main IdM  wiki space can be found at





and the main Netweaver troubleshooting wiki can be accessed here .



From the support side it would be great to get feedback if the wiki is a resource you have ever used or do you ever feel a need to contribute content to ?
All opinions both good and bad/constructive (please be gentle !) would be appreciated.




Chris (from SAP)

This blog post is about changing data with help of SAP Identity Management REST API v1, also multi values and role references with validity data.

I suggest using Google Chrome and the REST plugin Postman for this as test environment.



To be able to change data via POST request, two header variables have to be send to the Identity Management backend for security aspects. First one is X-Requested-With = JSONHttpRequest. The second one is more difficult. First, you have to send a GET request with X-CSRF-Token = Fetch to the server. You will receive a token, which has to be used in the POST, e.g. koMUjIyXs5z3qxUkAcKgJrJ0jOezwEQv2ZQ. All together:

  1. X-Requested-With = JSONHttpRequest
  2. X-CSRF-Token = <token_received_from_GET_request>

See therefore SAP Note 1806098: Unauthorized Use of Application Functions in REST Interface


To be able to change validity dates, you have to change the application property v72alpha.validity_enabled = true in AS Java.

See therefore SAP Note 1774751: Reading/Writing VALIDFROM and VALIDTO values with REST API


Change Singe Value Attributes:

This example changes first and last name.

POST http://localhost:50000/idmrest/v1/entries/<mskey_of_entry>/tasks/<task_id>?MX_FIRSTNAME=Benjamin&MX_LASTNAME=Franklin


Change Multi Value Attributes:

This example changes the additional phone numbers.

POST http://localhost:50000/idmrest/v1/entries/<mskey_of_entry>/tasks/<task_id>?MX_PHONE_ADDITIONAL=[{"VALUE":"555-41863218"},{"VALUE":"555-43518792"}]


By default, these values will be added. In order to delete values, add the changetype = delete.

POST http://localhost:50000/idmrest/v1/entries/<mskey_of_entry>/tasks/<task_id>?MX_PHONE_ADDITIONAL=[{"VALUE":"555-41863218"},{"VALUE":"555-43518792","CHANGETYPE":"DELETE"}]


Change Role References with Validity Dates:

Validity dates are optional. As value, use the mskey of the roles you want to assign.

POST http://localhost:50000/idmrest/v1/entries/<mskey_of_entry>/tasks/<task_id>?MXREF_MX_ROLE=[{"VALUE":"29","REASON":"Test","VALIDFROM":"1999-01-01","VALIDTO":"2049-12-31"},{"VALUE":"28","REASON":"Test","VALIDFROM":"2000-02-15","VALIDTO":"2015-06-31"}]


REASON, VALIDFROM, and VALIDTO are link attributes. You are also able to set the context ID by setting CONTEXTID=<mskey_of_context> as additional link attribute.


Privileges have to be changed my MXREF_MX_PRIVILEGE. MX_ASSIGNMENTS is only a virtual attribute and cannot be changed.


(For GET requests, make sure to set "List Entries on Load" in the attribute definition in order to get role or privilege assignments via REST).


URL Encoding:

Always make sure you are using URL encoding for these URL parameters (or use a library, which is capable of doing this), which will lead in URLs like these:

POST http://localhost:50000/idmrest/v1/entries/<mskey_of_entry>/tasks/<task_id>?MXREF_MX_ROLE=%5B%7B%22VALUE%22%3A%2229%22%2C%22REASON%22%3A%22Test%22%2C%22VALIDFROM%22%3A%221999-01-01%22%2C%22VALIDTO%22%3A%222049-12-31%22%7D%2C%7B%22VALUE%22%3A%2228%22%2C%22REASON%22%3A%22Test%22%2C%22VALIDFROM%22%3A%222000-02-15%22%2C%22VALIDTO%22%3A%222015-06-31%22%7D%5D


Related blog posts:

Write your own UIs using the ID Mgmt REST API

A simple example consuming SAP Identity Management REST API

When I am working on IDM projects, one of the things that I commonly find is that there is insufficient emphasis placed on the deprovisioning process. I have found this to be the case for a number of reasons, all of which usually come out during the requirements and discovery process, prior to determining a final design.


It's not that organizations don't know that users need to be deprovisioned, rather it's the policies that need to be acknowledged during the process. Let's talk about three common types of systems found in a SAP IDM project: Active Directory, Email, and the SAP System of your choice.


For various reasons, we may want to ensure that the person leaving the company might have information that we will need to hold on to some of their information. Information held on individual drive shares, emails, etc. could be required for legal or compliance reasons.  Also there's the chance that the termination is not actually a termination, access might be suspended for various types of leaves or sabbaticals. So how do we handle this? The first thing is that we need to understand what happens during the process.  For example, typical things I see are:


  • SAP IDM - Password is to be set to a random value, The MX_DISABLED attribute is set to a non-null value. (Note that MX_INACTIVE has some more far reaching effects. Please refer to page 92 in the document SAP NetWeaver Identity Management Identity Center - Identity Store Schema - Technical Reference.)
  • Active Directory / Exchange - User is to be disabled, moved to a separate, specific Organizational Unit, password to be reset to a random value.
  • SAP Systems - Login disabled, Password is to be set to a random value.


Typically this state is kept for a period of 14 to 180 days after which the accounts are permanently deleted, unless they have been reactivated.


One of the effects of these Business Processes, is that the SAP IDM Provisioning Framework needs to be updated.  Before considering any actions on the framework it is important to remember:


  • Make sure the original Framework install is backed up (I recommend a copy and paste to another part of the configuration and doing an export)
  • When editing specific tasks and jobs, make a back up copy.


Now you can go ahead and extend the framework. Note the following example where I have updated the Delete Plugin of the AD Connector:

SAP IDM PF Changes.png


Note that I make a copy of the "3 Delete AD User" task and then made a few changes, linking in the disable user task and moving the user to "ou=disabled" (for more information on this move, look here.)


You can use this same other approach for any other SAP IDM Connector. I suppose a more full-featured change for some connectors  would have have a conditional task to evaluate what kind of termination event this was and then either disable or straight out delete, but I have to leave some topics for future writing


Please let me know if this helps you or if you would take this a different way.

Originally RDS package is developed for Identity Management 7.2 and if you are an IDM 8.0 early customer and need certain functionality available in this RDS package here is a quick beginners guide which does not pretend for completeness, but rather shows minimum set of steps to enable a certain functionality - in this case Copy Identity.

To fully benefit from all of the RDS features follow the Initial System Setup in RDS Configuration Guide in the following file RDS_NW_IDM_IDM720_SERV\SAP_BP\BBLibrary\Documentation\D04_IDM720_BB_ConfigGuide_EN_XX.doc which you can find in:

SAP Service Marketplace>Products>SAP Rapid Deployment Solutions (RDS)>Lines of Business>Finance>Enterprise Risk and Compliance>SAP Identity Management>Solution Deployment


1. Download the IDM 8.0 Patch 1 SCA and deploy it (e.g. via telnet) on the AS JAVA.

2. Install the IDM 8.0 Eclipse Developer environment Patch 1 from the SCA.

     In Eclipse go to Help\Install New Software\Add and choose archive and find the location of the Eclipse archive from SCA content


3. Download the RDS package for IDM 7.2 - https://service.sap.com/rds-idm

     Go to SAP Service Marketplace>Products>SAP Rapid Deployment Solutions (RDS)>Lines of Business>Finance>Enterprise Risk and Compliance>SAP Identity Management>Solution Deployment and then choose SAP Identity Management RDS Content V1

4. Import schema mcc as shown on the picture.

  • Right click on Identity Store Schema\Import and find the import files folder like shown bellow.
  • In the lower right corner of the Open Dialog choose the IDM 7.2 “MCC files” and then select the 0256_IDM72_Identity_Store_Schema.mcc file.
  • From the Packages node’s context menu import the other two files:
    • 0256_IDM72_Job_Folder.mcc
    • 0256_IDM72_Provisioning_Folder.mcc


5. In order to see the web forms in the manage tab you need to give the respective role to the manager user: SAPC_IDM_ADMINISTRATORS

Assign this role to the user froms the web UI


6. Then the user should be able to see the RDS forms


  You can add to favorites this function copy identity  and it will appear in front of  Choose task button



     If still do not see the new forms in the UI then restart the IDM JMX Java application in SAP NetWeawer application server.


7. Finally in the RDS package constants you should check the following

     Double click the identity store


     Check that the ID of the identity store in this case “1”


     Open the idm\admin UI and go to system configuration and open the package constants of the provisioning package and make sure SAP_MASTER_IDS_ID value is equal to the above ID of the identity store in this case “1” and save.



For further details refer the Identity Management 7.20 - Setup and Provisioning (D04) document mentioned above (D04_IDM720_BB_ConfigGuide_EN_XX.doc

I thought I would share some of my experiences about IdM solution design and start with connecting IdM to Leading Identity System(s). I started in new IdM-project some time ago and my first task was to come up with an IdM-concept. In order to facilitate the workshops and discussions I put together a set of questions that I must get an answer. For this blog I included some descriptive text to give background why I think the topic/question is relevant.


All of this blog is from my personal experience or thoughts, not the full nor only truth. Although I tried to re-write it as generic as possible it might be missing an angle or two.


But I hope it helps someone new to the SAP IdM and especially when SAP HCM is the Leading Identity System.


Integration to Leading Identity System

The identity lifecycle and various status changes of the user record in IdM should happen in controlled fashion that works as designed/according to requirements. Identities normally map to employees and the identity/employment data comes outside IdM and the lifecycle is usually controlled by events that are outside of IdM, like hiring or firing.


There are exceptions like technical user accounts or external workforce. Those accounts may not have an existing dedicated system where they're managed, so the full lifecycle of them can be done in IdM. Developing a set of UIs and background batch jobs that enable for example the basic administration of contractors can be achieved quite easily.



  • What are the Leading Identity System(s)?
  • Single system vs. multiple systems?
  • What types of identities are supplied by Leading Identity Systems?
  • Attributes / data model
    • What will be the unique identifier (MSKEYVALUE) of the user entry in IdM?
    • What are the mandatory attributes for the user entry in IdM (plus Target Systems) and can the Leading Identity System supply all of them?
    • Does the user entry have to be enhanced with data from other system? Any transformation IdM must do the attributes?
    • Does the Leading Identity System supply an attribute/field that can be used in detecting the employment status or does it supply start/end dates?
  • Technical points in integration
    • What systems are involved? Technologies? Protocols? Frequency? Configurable out-of-the box interface like SAP HCM or LDAP or custom-interface?


Data Model

I typically start working on data model immediately, that's why the attributes are relevant. The data model sounds fancier than it actually is, basically a spreadsheet having an attribute map between IdM and Leading Identity Systems and Target Systems. Any data transformation rules can also be documented to the attribute map, for example if IdM is supposed to generate the MSKEYVALUE or email-address. It should also be highlighted which system "owns" which attribute, what can be maintained in IdM, what is mandatory/relevant attribute for each system and what attribute value change is relevant for each system (what attribute should trigger Modify for each target system).


Types of identities/User Entries


  • What types of identities does the future IdM-solution handle:
    • Just employees / internal users?
    • Also external users?
      • Subcontractors
      • Suppliers
      • Partners
      • Customers
      • who else?
    • What is the Leading Identity System for each?



The unique identifier of the user entry in IdM is an attribute called MSKEYVALUE.

In most of my projects the leading Identity System has been SAP HCM. The easiest solution integration-wise is that HCM is already storing the username to the SY-UNAME field of InfoType 0105 which would map into MSKEYVALUE (by the "standard" attribute mapping in the HCM to IdM-interface). This way the problem with unique value is put to HCM which simplifies the IdM-solution. But on the other hand I've seen an awkward process in HR-dept to generate the username, so IdM autogenerating it and writing it back to IT0105 can also make the process better.


I've also had requirements to generate the MSKEYVALUE based on HCM data or use Personnel Number as MSKEYVALUE.



  • Where to get the unique id/MSKEYVALUE for the user entry?
    • Is it supplied by Leading Identity System? If the Leading Identity System is SAP HCM what field is going to be mapped to the MSKEYVALUE:
      • IT0709/PERSONID_EXT
      • IT0105/SY-UNAME
      • IT0000/PERNR
        • If it is tied to IT0000/PERNR will the personnel number ever change? What should happen in IdM if the Personnel Number changes?
    • If the Leading Identity System is not SAP HCM, what (hopefully unique) field is mapped to MSKEYVALUE?
      • for example; samAccountName from AD? uid-attribute of LDAP?
      • is the value unique or must IdM be adapted somehow?
    • If the field is not supplied by Leading Identity System:
      • does IdM generate the MSKEYVALUE based on Leading Identity System data?
      • does IdM generate the MSKEYVALUE based on other means, like just an auto number?
      • what data integrity checks are needed? LDAP/AD-lookup? SAP HCM IT0105/SY-UNAME lookup?
  • Where will the MSKEYVALUE go?
    • Which Target Systems will have the MSKEYVALUE as username? Does the length or format of the Target System username affect to MSKEYVALUE?
    • Does the generated MSKEYVALUE need to be updated to SAP HCM IT0105/SY-UNAME-field?


User Entry Status

The user entry in SAP IdM does not have status as such. There are two attributes can be used in handling the status or replicating the status to target systems.

  • mx_disabled (true/false) => can be used in disabling the user in target system, ie. prevent login
  • mx_inactive (true/false) => can be used in deprovisioning, it makes the user entry inactive and hides it from active db-views and UI.


It is also possible to have a custom-attribute to represent the status of the user record in IdM or display values from leading Identity System, for example displaying the employment status of the user from SAP HCM.


The functionality tied into the mx_inactive differs a lot between the different versions of SAP IdM. Special consideration should be used when planning using the attribute. With the current Sp9 patch level that I am working with, inactivating the user automatically de-provisions all the access and re-activating (setting mx_inactive=false) reprovisions all access user had before inactivation (which may not be desirable).


(Note that the booleans in IdM work so that if the attribute exists it means logical true and no attribute for the record or removing the attribute means logical false.)



  • How is the user’s status in Leading Identity System mapped to SAP IdM?
    • If SAP HCM, how to map employment statuses to mx_disabled and/or mx_inactive?
    • If Active Directory, how to map userAccountControl to mx_disabled and/or mx_inactive?
    • If any other system, how to map the statuses to mx_disabled and/or mx_inactive?
    • If no status but validity dates are sent, what happen should happen in IdM when validity end is met?
    • Any other means of identifying the identity status change from Leading Identity System?

Joiners/Leavers/Transfers processes


Big benefit of IdM is the automatic on-boarding and provisioning process. A lot of automated provisioning actions can be built into on-boarding.


  • Any special processes in on boarding like approval steps (for example when the Leading Identity System is not 100% trusted) or will the identity be written into IdM as-is?
  • Will the employees starting in future be imported once they exist in Leading Identity System? (so the access could have been requested and put into place for the first day)
    • If SAP HCM is the Leading Identity System, then the integration step that moves the employee data from Staging to Productive Id Store must be configured so that at least the mandatory attributes are written immediately to Productive Id Store (by default the future values are stored as pending values that become visible once the validity start date is met).


Technically the on/off-boardning processing can take place in the event task that writes the identity to Productive Id Store or event tasks in Productive Id Store.



Along with the hire and automatic user creation the other big benefit of automated identity management is the automatic off-boarding and de-provision.


  • What happens on withdrawal?
    • Is the identity kept in IdM to reserve the MSKEYVALUE or other unique attributes? If so what status does the withdrawn entry have disabled vs. inactive?
    • Any grace period before losing any access? Same rules for all target systems?
    • If the user entry is to be deleted, is there a grace period before the entry really is deleted? Can a new user have the same MSKEYVALUE?
    • Any requirements on recovering access on:
      • re-hire
      • employee changes mind and does not exit
      • expired contractor or temp gets an extension
      • key person or C-title holder leaves, any emergency disabling of access?


Long Absence

What happens to the user entry during long absence (like maternity/paternity leave, study leave, long illness..) can vary a lot depending on the corporate or legal practices.


  • What happens on long absence
    • Does the user log-in to any systems during absence? (for example to see electronic pay-slip in SAP HCM’s ESS?)
    • Is the user disabled without losing any access during the absence?
    • Is any access removed?




  • Will there be a new MSKEYVALUE on rehire?
  • Will the old access rights be restored back?


Position / Organization Change or change in any other attribute that drives access



  • Any access driven by position (or other organization-related HCM-attribute)?
    • Context based assignment?
    • Dynamic groups?
    • Does the email-address change (to have a country specific domain name)?
    • Does the AD-container of the user change (if the "LDAP-path" has organisational data)?
    • Does any of the usernames change if any country specific prefixes exist?
    • What rights must expire that are driven by current location or organization specific attributes?
  • Any grace periods if access is driven by attribute value and old access must remain for a while? (adding attribute validity to existing attribute value)


Employee Name Change


  • How is the change replicated to IdM? Just 1:1 immediate change or are there any legal matters or policies involved or for example does the employee have to request to have the new name(s) in the IT-systems?
  • What attributes are driven by employee’s first/middle/last names and how should the change be reflected in IdM?
    • Email-address and proxy email-addresses?
    • Usernames to Target Systems?
    • Display name?


Concurrent Employment and Personnel Numbers in SAP HCM

If Personnel Number is used as MSKEYVALUE it should be noted that Personnel Number can change (depending on the HCM solution). Also, in the HCM data model there are two personnel number fields; PERSONID_EXT and PERNR. The former field means roughly the "unique identifier of the employee in HCM" and the latter as the "unique identifier of the job contract". For the first "contract" the value of the Personnel Number field is the same as Person Id Ext.

The employee can have multiple job contracts:

  • the employee may be a temp that gets new contract after the previous one has expired
  • the employee may be a temp that works for different organisational units in same HCM-implementation (concurrent employment scenario)
  • the employee may be going to expat assignment to another country / org unit (or may be returning from one)

Generally it is safer to map the Person Id Ext to MSKEYVALUE as it won't change.


It should be noted that HCM will export the old personnel number with employment status “withdrawn” and new personnel number with “active” employment status, the IdM solution must be configured accordingly.


External contractor becomes employee or employee becomes external contractor

With todays requirements for flexible job market I guess there are more contractors than ever, so most of the IdM-projects have had something special for contractors vs internals.



  • Will there be new MSKEYVALUE in the employment change?
  • If the same MSKEYVALUE is kept what happens to any attributes that highlight that user is “external” or "internal"?
    • email address (for example if email has prefix, like “ext-“)
    • displayname (for example if displayname has word “external” for externals)
  • What happens to existing access rights?
    • Does the user have to re-apply for them?
    • Are rights automatically moved to new identity if the job role stays the same?

     Managing identities and their permissions is important for the companies. Along with performing specific operations, companies also would like to have details/reports on top of the identity management data. These reports could cover the current state of assigned privileges, for example, or what was the situation last year. Some of the requirements for such reports are common to the different companies, but it is also true that there are company specifics. By creating reports on identity management data, companies could do some analyses and if needed execute proper actions.


     In the following article we'll create, modify and extend an analytical report. For this purpose we'll get the SAP IdM data and via SAP Lumira we'll create nice looking reports, share them with colleagues and add options to filter/drill-down into the report so that we could discover the information that is important for us. The described approach is applicable to any IdM version and all supported DBs.


     Here are the technical details of our configuration:

  • Installed, configured and operational instance of SAP Identity Management 7.2 SP9, which is used to manage identities in a multinational company. As DB for this IdM instance we’ll use MS SQL Server and we have created user with proper select permissions for this DB
  • Installed SAP Lumira Desktop, an MS Windows application that will be used for building the analytical report
  • Created account in SAP Lumira Cloud, an environment that will be used to publish and after that access the analytical report





     We'll go through:


     As a result we'll create a sample analytical report that combines several information sets inside and provides filtering capabilities. The report is easily accessible and could be used for a daily business. In our case the report is almost real-time - the data could be refreshed based on time schedule or on demand. Last but not least, a similar report could be created on top of any SAP IdM version if you use the public APIs (DB views) that are exposed, the same way we did it here.




     Additional information and options for IdM reporting could be found in:

     As described in the master document of this blog post series, we'll start with creating a simple IdM report and it will be used for later enhancements.


Part 1: Create initial version of IdM report via SAP Lumira

Create DataSet


     The first step in creating an IdM report is to define the requirements for a given report. Our initial requirements are the following:

The report should contain all company employees and assigned business roles, presented in a tabular format.

The report should be accessible in an easy way (e.g. via web browser).


     When the requirements are fulfilled, we should proceed with creating the report. The next step is to connect from SAP Lumira Desktop to the SAP IdM instance. This is needed to extract the identity data and form the report. Connection is done via JDBC directly to the IdM DB. Once the connection is established, the information is extracted in so called DataSets. To achieve that, we'll do the following:

Start SAP Lumira Desktop

Open File->New or use the shortcut (Ctrl+N)

Select the option “Query with SQL” from the Source options list


Select the DB type. In this example we use MS SQL, but you should select the proper type based on your installation.


Provide connection details and connect to the DB. It is also helpful to save the connection details, that way we’ll not be asked to enter them each time we try to connect to the DataBase.


The next step is to specify which data will be extracted in the DataSet. We should define the name of the DataSet and provide the query definition.


In this case the name of the DataSet will be RolesSCNDS and the query will extract display name of the business role, identifier of the person, identifier of the business role and information about the time when the business role was created. To extract that details, we'll use 2 of the DB views that IdM provides:


               entries.mcDisplayName as RoleDisplayName,

               links.mcThisMSKEY as RolePersonIdentifier,

               links.mcOtherMSKEY as RoleIdentifier,

               links.mcOtherMSKEYVALUE as RoleName,

               entries.mcCreated as RoleCreated


               idmv_link_ext as links inner join idmv_entry_simple_all as entries on links.mcOtherMSKEY = entries.mcMSKEY


               links.mcThisOcName = 'MX_PERSON' and

               links.mcOtherOcName = 'MX_ROLE'

Press the “Preview” button to see whether the data will be loaded into the table at the bottom right part of the window. If everything is correct, we should see several records in the table.

Pressing the “Create” button will create the DataSet.




Create Table visualization


     After we completed the creation of the DataSet, we will navigate to the SAP Lumira Desktop main screen. The next step of the process is to create visualization objects that will display the content of the report.

Make sure that “Visualize” tab is selected in SAP Lumira Desktop.


We'll select Table from the templates.


Add “RolePersonIdentifier” and “RoleDisplayName” dimensions as “Rows Axis”. This could be done via drag-and-drop or by using the "+" button.





Create Story Board


     Now that we constructed the table, we should create “Story Board” where to add the table and combine it with other graphical objects later.

We should navigate to “Compose” tab in SAP Lumira Desktop.


As we do not have other Story Boards created, the application will ask us to create one. We’ll name this Story Board RolesSCNSB and press the “Create” button.

Change the default title of the Story Board to “Roles”. Double click the title to open it for editing.


Drag and drop the visualization object that is available in the pane on the left side.


As a result, the following visualization object is displayed:





Save SAP Lumira Desktop document


     As we have the initial version of the report ready, we could also save our work in SAP Lumira Desktop if we want to modify the report later.

To do that we'll open File->Save As (or Ctrl+Shift+S) and specify the name of the document.


We could save the changes locally or on the cloud.




Publish the report


     The next step of this part is to publish the created story Board to SAP Lumira Server and share it.

Prior to publishing the report, we should guarantee that the network settings are correctly maintained. We'll do that from File->Preferences menu (or Ctrl+P) and then go to Network. Check the proxy settings and make sure that the SAP Lumira Cloud URL is entered.


To publish the report, we need to go to the “Share” tab.


Select the RolesSCNSB and press the “Publish to SAP Lumira Cloud” button.


We’ll be asked to provide our credentials for the cloud environment.


After we enter that details and connect to the cloud environment, we need to confirm the publication. Shortly after that the DataSet and the Story Board will be published to SAP Lumira Cloud.





Open and share the report


     After we publish the report to SAP Lumira Cloud, let’s try to open it.

We need to open SAP Lumira Cloud and provide the credential details. We’ll be navigated to the cloud environment and will see all objects that we have published. In our case these are the Story Board and the DataSet.


Click over the Story Board RolesSCNSB and the report will be opened.


We could also share the report with other people. To do that, we'll open “Share” from the Story Board context menu.


Change the access to public and save the sharing URL.



* In this case the report will be visible to everybody, but there are also options we could use to share a report to specific people or groups.


     Now the initial version of our report is created, published and accessible to other colleagues. Any later changes that we’ll do will be automatically available via the sharing URL that we have copied in the previous step




As we are ready with the initial report, we could proceed further to the next step and modify the report

     As described in the master document of this blog post series, after we created the initial version of the report, we'll proceed further with modification of that report.


Part 2: Modify initial version of IdM report created via SAP Lumira


     The report that was created contains just few attributes and later on we’ll see how that details could be extended. Now we’ll take a look at how the report could be modified.

Modify visualization label


     We can start modifying the table visualization by changing its title.

     To do that, we need to open the Visualize tab in the SAP Lumira Desktop.

Double click the title of the table to open it for editing and specify the new name e. g. “Person Details”.





Modify column labels


     We could also rename the table columns as the current names are inherited from the Dimension names. To modify the column names, we need to change the dimension names.

From the context menu of “RolePersonIdentifier” dimension, select “Rename…” and specify the new dimension name. In our case let’s name it “Person Identifier”.


Repeat that procedure for “RoleDisplayName” and set the new name to “Role Display Name”.

Now we could save the changes of the document and republish the Story Board to SAP Lumira Cloud. We'll be asked to confirm the overwrite, as the content is already published to the cloud. As a result of this, the report is updated and if we use the sharing URL that we defined earlier, the new visualization will be displayed as follows:




As we are ready with the modifications, we could proceed further to the next step and combine information from several DataSets.

     As described in the master document of this blog post series, after we created the initial version of the report and modified it, we'll proceed further with combining several DataSets.


Part 3: Combine information from several DataSets in IdM report created via SAP Lumira


     The report that we created covered the initial requirements that we defined. Let's extend them with the new information that should be added to the report:

Add employee name to the table with user details.

Add statistic how many employees have a given business role.




Create second DataSet

     The DataSet that was created earlier does not contain information about the employee name, therefore we need to create a new DataSet and merge it with the DataSet RolesSCNDS.

Having the RolesDocumentSCN opened in SAP Lumira Desktop, we need to navigate to Prepare tab and add a new DataSet.


The steps to create the second DataSet are the same as the ones for the first DataSet. Let’s name the second DataSet UsersSCNDS and use the following select clause to extract the user identifier, user state, user display name, information when the user was created, information when the user was last modified, city in which the user is located. To extract that details, we'll use again DB views that IdM provides:


               entryView.mcMSKEY as UserIdentifier,

               entryView.mcEntryState as UserState,

               entryView.mcDisplayName as UserDisplayName,

               entryView.mcCreated as UserCreated,

               entryView.mcLastModified as UserLastModified,

               valuesView.aValue as UserCity


               idmv_entry_simple as entryView,

               idmv_value_basic_active as valuesView


               entryView.mcEntryType = 'MX_PERSON' and

               valuesView.attr_id in (SELECT mxiv_allattributes.Attr_ID FROM mxiv_allattributes WHERE mxiv_allattributes.AttrName = 'MX_address_city')and

               valuesView.MSKEY = entryView.mcMSKEY

As result of this, we have two DataSets.





Merge 2 DataSets

     We have the DataSets created and now we should go forward and merge the content from them in one DataSet.

Make sure that RolesSCNDS is selected and start the wizard for merging DataSets.


On the left side the current DataSet should be RolesSCNDS and on the right side we should have UsersSCNDS. We should also mark the columns that will be used for merging, these are “Person Identifier” and “UserIdentifier”. Also we should specify the merge type – in our case “Inner Join”. After we press the Merge button the RolesSCNDS will be enriched with the content from the UsersSCNDS.


     We extended the RolesSCNDS as in Lumira the Visualizations and Story Boards are associated with DataSet. As our first object was created on top of RolesSCNDS, after the extension we are able to continue further to make the report richer.

     If we now navigate to Visualize tab, we’ll find that there are more dimensions in the list.

We'll change the name of “UserDisplayName” to “User Display Name” and add it as a second column in the table.

We could also save the document (now it contains 2 DataSets and one Story Board) and publish the story board to SAP Lumira Cloud. This publication will trigger publication of the modified DataSet as well.




As we are ready with the extension of the DataSets, we could proceed further to the next step and combine multiple visualizations.

    As described in the master document of this blog post series, after we created the initial version of the report, modified it and enhanced the DataSets, we'll proceed further with combining several visualizations in one Story Board.


Part 4: Combine multiple visualizations in IdM report created via SAP Lumira


Create second visualization


     After adding an additional column to the table, we should create a new visualization that we’ll show on our report together with the first table. The second visualization will be of type Column Chart that will display the number of users for a specific business role.

Navigate back to Visualize tab and create new visualization via the “+”. The second visualization should be of type “Column Chart”.


For X Axis, set the “Role Display Name” dimension.

From the “Person Identifier” dimension create a new measure.


For the newly created measure, change the aggregation to “Count (Distinct)” and change the name to “Unique Users”.


Use this measure as Y Axis and change the name of the chart to “Unique Users by Role”.


Jump to Compose tab and via drag-and-drop place the new Column Chart visualization next to the table with user details.

Save the document and republish the Story Board.


     Now the reports should contain two graphics and should look like this:





Create third visualization


     As we mentioned in the master document of this blog post series, the company is international, so we would like to extend the report with details that cover that aspect – number of users per country. For this extension we’ll use some of the capabilities that SAP Lumira provide out of the box.

Go to Prepare tab in SAP Lumira Desktop and make sure that RolesSCNDS is opened.

From the “UserCity” dimension, create new geographic hierarchy by names.


In the Geographical Data window, set the City to be “UserCity” and confirm.

As one of the cities in our case exists in several countries, we need to manually specify which the right one is. We’ll set it to Norway.


After the operation is complete, few more Dimensions will appear in the prepare tab.


Navigate to the Visualize tab and create new visualization of type “Geo Choropleth Chart”.


Use the “Country” attribute from the newly created "Geography_UserCity" dimension as geography criteria and “Unique Users” measure.


From the settings, activate Data Labels.


Navigate to Compose tab and via drag-and-drop add the new visualization to the report.



     After you save and publish the Story Board, you’ll be able to access the extended version of the report via the sharing URL.



As we are ready with the new visualizations, we could proceed further to the next step and provide filtering capabilities.

    As described in the master document of this blog post series, after we created the initial version of the report, modified it, enhanced the DataSets and combined multiple visualizations, we'll proceed further with providing filtering capabilities.


Part 5: Provide filtering in IdM report created via SAP Lumira


     Our next extension of the report will provide some filtering capabilities.

Filtering based on Business Role

Filtering based on Country



Create filtering based on existing dimension


     The first filter that we'll introduce will be based on Business Role. We already have a dimension that represents the Business Role, and we should proceed as follows.

We need to open the Compose tab of SAP Lumira Desktop.

Select the Input controls and visualize all possible controls.


Via drag-and-drop put the “Role Display Name” next to the other visualizations.


We could publish the modified report to the Cloud and select some of the Business Roles from the filtering section. As a result, the 3 graphics will be refreshed and their content will be displayed according to the filtering.





Create filter based on calculated dimension


     The other filter (based on country) could not be added that way as the geo hierarchy dimensions are not displayed. To enable that filtering, we’ll do the following:

Navigate to Prepare tab

Add new calculated dimension


Set the dimension name to “Country Name” and in the formula enter {Country} or just double click on the Country dimension.

Open again Compose tab and we should be able to see the newly added calculated dimension.

Drag and drop “Country Name” dimension above the other filter.



     Now we could combine both filters e.g. all employees from Bulgaria, Check Republic and Norway that have Employee role assigned to them



Filter Blog

By author:
By date:
By tag: