1 2 3 10 Previous Next

SAP Identity Management

143 Posts

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


Ever wanted to add a new attribute in your HCM-IDM integration?

Well here is how it can be performed. Just follow the steps below. This is a valid case for any attribute you need in your integration.


1) You need to login to your HCM system and execute SQ01



From this view, you should pick up your Query that is used when you extract data to the IDM. Then select Change and Basic List.

The basic list contains all attributes that could be used for a user. The ones that are in use are marked with green. You can also see the technical name of the attribute.

2) Select the attribute you wish to be used by clicking the checkbox "List Fields" and save your changes.


3) What you need to do next is to maintain field assignments for Data Export - by using transaction HRLDAP_MAP. You need to select the Global Work Area checkbox and enter the User Group and Name that you are using. If you've been using the official IDM-HCM integration documentation on your setup that would be /SAPQUERY/L1 for the group and LDAP_QUERY for the query. Here you should maintain the Query Fld/Description/Attribute Grp/Attrib.Name accordingly.

4) Then you need to maintan the LDAP Server Mappings. You execute LDAP transaction - then select your LDAP Server and then Mapping.mapping.PNG

Maintain the names of the field "Fld" and the Attribute names.

You are now done from the HCM part. Now follows the IDM part.

1) You need to navigate to the HCM Staging Area and expand the attributes in the Identity Store Schema.

Make sure your new attribute is correctly represented here.


What is important to know here - the attribute that you create here should have the Entry Type MX_HCM_Employee selected. (Properties of the Attribute > Entry Type Tab). Compare already created attributes to your setup if you can't find this option.

2) Last but not least you should add a line into the To Identity Store Pass usually named Write HCM Employee To SAP Master which will write down your record into the IDM itself - Destination Tab.


Make sure that the Attribute you are using exists in the IDM, otherwise you will get an error during the extract. If it is a completely new Attribute (MX_something) you need to create it from the IDM side too.

The latest version of the SAP Identity Management solution is now available for ramp-up customers.
Release 8.0 offers a new Eclipse-based developer studio and a connector for SuccessFactors, among other new features and enhancements.


For more information, check the following resources:



If you would like to participate in the ramp-up phase, please register on the SAP Service Marketplace.

SAP Identity Management 8.0 - the new major version of the product was just released and now is available for download on the SAP Service Marketplace.

As can be expected of a new major release - the product contains many enhancements along with some key new features.


Starting with the IdM Designtime -  IdM Developers can now benefit from a completely new development environment based on Eclipse - the new IdM Development Studio.  Going further - in the new version IdM continues to extend its integration capabilities with SAP products introducing a SuccessFactors connector (SFSF connector). I should also mention here improvements like  the new security concept and new process editor, as well as some renovations in repository and dispatcher management.


Of all the new features above in this blog I would like to focus on an overview of the SuccessFactors connector. We will take  a look at the two business scenarios that are supported as well as go into some more details about the new packaging concept and how the SFSF

connector is delivered as part of the SAP Provisioning Framework.


SuccessFactors, an SAP Company, is a global provider of cloud-based human capital management (HCM) software with its cloud offering Employee Central (EC).

On one side - like any HCM system, Employee Central is the leading system of record for employee data.  On the other side - SAP Identity Management is the leading system of record about identities, their data and privileges. So far in version 7.2 SAP IdM offered identity management processes around the on-premise SAP HCM solution. In IdM 8.0 we provide similar processes for Employee Central.  With the SuccessFactors connector we cover two main scenarios:

  • Identity propagation if initiated from SuccessFactors
  • Identity propagation is initiated from SAP Identity Management

In  the first scenario  SFSF EC is a central employee system and we have enabled identity propagation to be initiated from SuccessFactors. (Figure 1). For this we have implemented a pull mechanism in delta mode via scheduled Initial / Delta Load Job.




Figure 1


The other scenario that is targeted is the one where we have IdM as a Central system that initiates identity propagation. Here SAP IdM uses the SuccessFactors role-based permission concept and is used to assign users to roles and groups in SuccessFactor in a similar way like for any other system in the landscape (Figure 2). This way customers of SAP IdM are able to extend their SAP IdM deployment with SuccessFactors. This scenario could be used regardless of whether SFSF Employee Central is the leading HCM system or not.


Figure 2



The SuccessFactors  connector is shipped as a separate package in SAP Identity Management 8.0's Provisioning Framework. Introducing the new packaging concept in IdM 8.0 (for more details you can check what Fedya posted here) now you can consume it via importing the package that is called com.sap.idm.connector.sfsf - com.sap.idm.connector.sfsf.idmpck.


As you can see on Figure 3 the connector consists of the following components:

  • An SFSF repository type.
  • Jobs and processes that control provisioning from and to SuccessFactors.

To configure the SuccessFactors connector, you have to create a repository and run an Initial Load job.

For more information and details about the configuration you can take a look at the new extended Configuration Guide that we have prepared for IdM 8.0.


Figure 3


Further interesting information for the IdM 8.0 release could be found in the SAP Identity Management 8.0 Release Highlights and in SAP Identity Management 8.0 Developer Studio Eclipse Plug-in

As outlined in my previous blog, one of the major improvements in SAP Identity Management 8.0 is the new design time Developer Studio which is an Eclipse plug-in which replaces Identity Center Management Console. And although this change might seem big the feedback we got from early users was that for the users with background in earlier versions it was easy to get used to the new one and in addition were pleased by some of the features Eclipse brings with it e.g. to be able to work with more than one entity at the same time, JavaScript code coloring and code completion.


In the SAP Identity Management 8.0 Release Highlights blog I mentioned about the improved security model and now will make a short detour to elaborate a bit on that.


Developer Studio connects to the IdM Developer Studio Service running on SAP NetWeaver AS Java. The service then uses AS Java UME for authentication, that’s why you should have the respective users in the UME and in addition it is required that this user also exists in the Identity Management database with the same username as in the UME. Then the service connects to the Identity store(s) and verifies all incoming requests so that the developer actually no longer needs to know the database credentials. All authorized IdM developers are stored in the IdM database in the configuration tables e.g. MC_USERS but not in the Identity store meaning that a developer does not have MX_PERSON entry. These tables in IdM database are only writable by mxmc_admin user which is created during install or upgrade and thus prevent developers from modifying them. This is done for security reasons – as developers have access to the identity store and might easily break the security and authorization model. Therefore, the mxmc_rt user which is used by the runtime components also does not have the permissions to modify that.


Having created a Developer admin user you are ready to go.

Once you open Eclipse you would need to go to Window/Open Perspective/Other and switch to SAP Identity Management Developer Studio perspective to be able to take full advantage of the IdM Development Studio plug-in features.

Then you would create Identity store. The Developer Admin user can also add developer users given that they are created in the UME first. Developer administrator can add or remove users, create identity store, create package, modify identity store schema and manage the package access rights. As Developer administrator you have the ability to suspend/resume or stop a dispatcher remotely from the Developer Studio Eclipse plug-in – another feature that was appreciated by our early customers as you do not need operating system level access to the runtime machine. Of course you can use the new dispatcher utility.

Developers have access to one or more packages. If a developer is owner of a package, she can grant access to other users. Developer can modify anything, but Layout Developer can only modify form layout. Import authorization would allow overwriting by importing. View authorization allows read only. Access to each package can be modified by the administrator or the owner. This can be done only if the package is checked in.

Then you would import the SAP Provisioning Framework packages and it is worth to mention few here:

  • Engine - contains the core provisioning flow which is responsible for triggering the necessary processes (Provision, De-provision and Modify) as well as common scripts used by all packages so most other packages depend on it.
  • At least one connector package - The package for each connector contains the specific processes for provisioning to a specific system e.g. com.sap.idm.connector.abap.idmpck which includes ABAP specific repository type, processes, jobs and scripts.
  • Custom package (com.sap.idm.connector.custom.idmpck) – is package with default settings and configurations, default constants and scripts and customers can make customizations in this package so that it is less likely to modify SAP delivered packages and preserve their easy upgradability in future. Connectors have extension points which can be implemented in these custom packages. Currently extension points are a given set and we would need feedback to see what else has to be added as extension points.
  • One of the new connectors we deliver with this release is SuccessFactors connector and you will find a bit more in this blog article of Ralitsa Chipeva.
  • Forms package - The forms package contains the definition of all User Interface tasks for CRUD operations (create, read, update, delete) on different entry types
  • Notification package - The notification package contains the notification task and the notification templates that are used to send notifications from the SAP Provisioning framework, approval and attestation tasks


Finally the workflow diagram editor allows you to view existing processes in a more convenient way and model new ones with the mouse. Actually “drag-and-drop” implies drag, but actually you do not need to drag, rather you click on the palette element and then put it where you wish – usually over an arrow. I found this convenient once got used to it. Also it has got nice Auto layout function.


Now the Eclipse plugin is available on the central update site also known as SAP Release Train for Eclipse. You can see how to access it here: SAP Development Tools for Eclipse



Filter Blog

By author:
By date:
By tag: