on 2003 Nov 19 5:24 PM
Hello everyone... I am currently involved in a project that requires that we create and store proprietary user properties. The break-down goes like this:
Primary user information is coming from a read-only LDAP (the official SAP corporate LDAP to be precise). Since we cannot store any user-specific attributes there, we need a way to store them somewhere else in a way that when a user logs on, these extraneous attributes are available from the same user object that you get the user's firstname and lastname from.
What's more, we need to persist these attributes, allowing users to occasionally change them (hopefully) through their user profile page. How to add fields to the user profile page, then have those values propagate to a specific user attribute store is another big question that I cannot find an answer to in the existing documentation.
I've had suggestions to use another LDAP server, like eDirectory, to store these new user attributes, but I cannot find any way to attach another LDAP in a way that allows it to add it's attributes to those coming from the main user store in the common user object accessible from within a component's code.
Anyone have any ideas?
I thought about your request a little more and spoke with the UM team. I think what you want to do is quite simple. Since the DB is the automatic fallback for any attributes not configured in the LDAP or other data stores, you can simply store any arbitrary attribute and then retrieve it. The whole process is quite magical...
To store the attribute, get the IUserMaint object for the user:
String NAMESPACE = "com.company.usermanagement";
IUser user = request.getUser();
String attrib = "costcenter";
IUserMaint u = UMFactory.getUserFactory().getMutableUser(user.getUniqueID());
String [] attrval = {"123456"};
u.setAttribute(NAMESPACE,attrib,attrval);
u.commit();
u.save();
The UME engine will detect that this namespace/attribute does not exist in the XML configuration for your LDAP server and will use the DB to persist it....
To retrieve the attribute:
String NAMESPACE = "com.company.usermanagement";
IUser user = request.getUser();
String attrib = "costcenter";
String attrVal = user.getAttribute("com.company.usermanagement",attrib);
response.write(attr + " = " + attrVal[0]);
I'm writing a series of SDN articles. I guess I'll put this in too...
Best regards,
Will
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The thing is, default behaviour is usually a very bad thing to rely on in any system. Considering the amount and nature of the changes going on in the Portals system, I would rather not use any "default" behaviour for operations that are supposedly configurable. In addition, we'd like full control over what new attributes get stored and where they are persisted.
The documentation talks about being able to configure the persistance manager to control what user data is stored and accessed from which data source, but that same documentation never tells you where and how this configuation is performed. I've searched through the portal system and cannot find any interface for the Persistance Manager, nor can I find any xml document to edit.
There is also the matter of adding the new attributes to the standard user profile page so the user can modify the values and have those values passed to the persistance manager and stored.
- John O'Grady
Do these custom attributes need to be retrieved / viewed by other users or administrators? If not, then I think I have a solution for you that makes a clever use of personalization properties.
Best regards,
Will
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
interesting question, we have some docu about this , bur I think no tutorial:
http://help.sap.com/saphelp_ep60sp2/helpdata/en/38/76bd3b6e74d708e10000000a11402f/frameset.htm
Regards, oliver
Excerpt:
Data Persistence - Storing User Management Data
This section outlines how SAP User Management Engine (UME) stores user data that needs to persist even if a system is shut down or restarted. The data repositories in which user data is stored are referred to as data sources.
Multiple Data Sources
With UME you can leverage existing user data repositories in your system infrastructure by connecting to a wide range of data sources using configurable persistence adapters. You can read data from and write data to multiple data sources in parallel. For example, you can configure UME so that user data is read from an existing corporate directory, while new users are written to a database. A persistence manager is responsible for reading the data from or writing the data to the correct data source. The data source to which the persistence manager writes is transparent to the application.
Data Partitioning
UME also supports data partitioning. This means that you can configure UME to use different data sources for different user sets or attribute sets. You can partition data in two ways:
· Attribute-based data partitioning: Different sets of attributes are written to different data sources. For example, global user attributes, such as telephone number, email address, and so on, are written to a corporate directory while SAP-specific data is written to a database.
· User-based data partitioning: Different sets of users are written to different data sources. For example, in a collaboration scenario, where both users internal to your company and users from other companies work together in the same application, the external users need a user account as well. In this case you can configure the persistence manager to store company internal users in the corporate directory, whereas external users are stored in a separate directory.
Architecture
The following diagram illustrates the architecture of UME:
UME user data is stored in one or more data sources. Each type of data source has its own persistence adapter. The persistence manager consults the persistence adapters when creating, reading, writing, and searching user management data. The application programming interface (API) is a layer on top of the persistence manager.
In the persistence manager, you configure which data is written to or read from which data source, so that the applications using the API do not have to know any details about where user management data is stored.
Persistence Adapters
Persistence adapters for the following types of repositories are available:
Database: See the Product Availability Matrix on SAP Service Marketplace (http://service.sap.com/pam60) for details on which databases are supported.
· Lightweight Directory Access Protocol (LDAP) directory: See the Product Availability Matrix on SAP Service Marketplace (http://service.sap.com/pam60) for details on which directories are supported.
SAP Systems based on Web Application Server 6.20
You can configure UME to use one or more of these persistence devices in parallel. Users can also be stored in several different physical LDAP directory servers, or in different branches of the same LDAP directory server.
Replication Manager
The replication manager replicates UME data to external systems. User data that is written to the persistence manager is also written to the replication manager. The replication manager generates XML documents and sends them to the external systems which process them and perform the corresponding actions.
For example, if you are using UME with SAP Enterprise Portal and want an SAP Customer Relationship Management (CRM) system to work with the same user base as the portal, you can configure UME to replicate all user data from the portal to the CRM system.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
81 | |
11 | |
10 | |
10 | |
10 | |
8 | |
8 | |
7 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.