UME Configuration Settings – 2

In addition to my earlier blog regarding the UME settings <http://scn.sap.com/community/netweaver-portal/administration-and-development/blog/2012/05/09/ume-configuration-settings>, this blog would help clearing the understanding on the datasourceConfiguration xml file.

Let us start with some background information; MSADS- the LDAP directory server is configured with UME portal to store the user information. Users can be created in the portal by two ways 1) User Management Admin Console 2) UME API

No matter how the users are created, their information is stored in the LDAP and we have proper control over what we want to be stored. This SAP Portal to LDAP directory server configuration can be found under UME Configuration. You can find different Data Source option to choose from the drop down (see Fig:1.0). By default the UME uses Flat Hierarchy because it supports the existence of multiple groups in LDAP Directory Server.

Fig:1.0

LDAP Directory Server property is described under the ‘LDAP Server’ tab . Server name, Port and user Login credentials are the basic connection parameters to establish the connection. (See Fig:2.0). User path and Group path describe the place where the user information will be stored in the Flat Hierarchy structure of the LDAP Directory. The tick on the little check box for SSL ensures the access of the LDAP from the protal.

Fig: 2.0

All other detail level configuration is defined in the xml file datasourceConfiguration_ads_writeable_db.xml (see Fig 3.0)

Fig: 4.0

Further, the datasource CORP LDAP points to the data stored under LDAP directory (See Fig: 5.0) and contrary to the Private Datasource, this is not home for the service Users.

Fig: 5.0

Instead, the CORP LDAP is responsible for the account and user information. See Fig 6.0

Fig: 6.0

The user information is the same which is seen in the Identity Management. The property ‘populateinitially=true’ makes that field mandatory to fill at the time of user creation. The namespace comes into picture when we sue the UME API to read/write the user info. I would probably cover that in my next blog.

So far so good. Now if you are thinking ‘I get what you told, but how does this UME data is getting stroed in LDAP? ‘ then I believe you are exactly following this blog and my purpose of the blog is fulfilled. See the Fig 7.0. In the xml file you can find the attribute mapping tag. The tab ‘attribute name’ is the one which is at UME and can be used via UME API and the tag saying ‘physicalAttribute name’ is the one which is at LDAP for the above mentioned attribute. So this means, ‘firstname’ at UME is actually stored as ‘givenname’ in LDAP. And similarly all the other attributes are mapped.If the physical attribute is set to null, that obviously means, that attribute is not getting stored in LDAP and you can update the same, save it, upload the file back again and restart the server to reflect the changes.

This blog would clear almost all doubts related to the UME configuration. I plan to write the next blogs on how to add a custom attribute in the UME and how to control the UME attributes through APIs.