Planning for Profiles usually takes most time and is the most challenging of all the features of IBM Connections because it utilizes data imported from the organization LDAP. This data can contain information such as user names, email, unid, and so on.
Some points to take care of while planning are:
- Which data sources are to be used?
- What are the field specifications of the source data (field name, type, data length)?
- Is data required to be synchronized and in what direction?
- If required, where are the additional data files like Photos located?
- Which fields are to be mapped 1:1?
- Which data fields are displayed in a profile entry, and which of them are editable by users?
It is also critical to ensure that IBM Connections has the proper access to the data and that the two systems can work together regarding data updates and synchronization.
It is also possible to upload individual user photographs while creating IBM Connections Profiles. To do this, first you must identify which photo repository is to be used and then where you want the photographs dump to be taken for uploading.
The upload file size limit is 15 KB so this aspect needs to be taken care of while planning.
Setting up Manager attributes
The setting up of Manager attributes in user profiles is an optional but desired feature of Profiles population.
Each user profile contains a manager_uid field which stores the UID value of that person's manager. This information is used to build the Reports To
display widget in the Profiles user interface.
Additionally, the isManager field (which equates to the Mark manager mapping task in the Profiles population wizard) is used to mark the user profile as being a manager. This information is used to build the People Managed
display widget in the Profiles user interface. A Y or N attribute is assigned to an employee to indicate whether the employee is listed as a manager of other employees.
While planning, you have to decide whether you want to populate these fields or not and accordingly decide on running the required scripts.
Cleaning up data sources
Before you import data into the IBM Connections databases, we suggest that you clean up your data sources and remove any redundant data. This not only leads to an error free import but also gives you an updated environment that you can use for other environments also. Also, it will save time during the import process.
This step should always be included in the deployment plan as apart from the advantages as mentioned above, cleaning up will also help you avoid any potential future issues in case you go for a clean up post installation of IBM Connections. In worst cases, you might need to do the import of Profiles data again.
IBM Connections uses the data populated in various columns of PEOPLEDB and other related databases for displaying different attributes of a user profile. All these values are the ones that are imported from various LDAP fields. If not specifically mentioned, these values are populated using the default mapping by the population wizard.
We recommend to have a detailed field level information of your LDAP ready before the data population. This helps you to accurately populate the data in the mapped fields and avoid any potential future issues.
Using profile types for custom profiles by user name
A profile-type defines a set of properties, also referred to as a schema, that are inherent to all profiles of that type. This set of properties is used internally to group objects and enforce overall system constraints. Examples of common profile-types are customer, employee, and contractor.
All profile records are classified by their profile-type property. If a property is not specified in the profile-type property definition of a profile record, it is not exposed to the Profiles user, either in the user interface or API. The deployer uniquely identifies each profile type using a 64-byte profile-type identifier
Profile-type definitions are declared and managed in the profiles-types.xml file.
Profile-types are managed in an object hierarchy with the following rules:
- Profiles defines a single base type of snx:person that enumerates the set of fields required on all profile records.
- You can define subtypes of snx:person (such as customer, employee, or contractor) to add your own unique properties.
- A profile-type inherits all the property references from its parent type.
- A profile-type hierarchy cannot contain circular loops. The application will fail to start if any loops are detected in the configured hierarchy.
- A profile-type declaration that omits a parentId implicitly inherits from snx:person.
The followin gis a sample code:
We recommend to explicitly map a defined profile-type to each profile record in the Profiles database as a part of the Profiles population process. If no profile-type is associated with the profile record, the Profiles application interprets the empty profile-type value as equivalent to the default
If the declaration of the default
profile-type has been removed from the profiles-types.xml
file, the application assigns the profile record the snx:person
profile type. As a result, the application only presents the minimal set of attributes defined in the snx:person
profile-type in the user interface.