How to show your Organization tree structure as separate Profile types in Connections Profiles (part 1)
We sometimes get the question, if it’s possible to include the organization tree into Connections Profiles. As you know, since Connections Profiles is user centric, and it includes a hierachy, but the hierarchy is based on people, there is no real separate hierarchy that depicts the organization tree.
Now this article describes how you could include your organization tree in Connections Profiles, as a profile type.
Idea
The idea is to use a custom profile-type for departments, or organizations.
This means we would need to import the departments from somewhere, and store them in Connections Profiles with the “default” profiles.
I’ll take some shortcuts here, since this is merely a demonstration of the principle. So I’ll store the departments/organizations in LDAP , in a way that I can easily pick them up using the default TDI assemblylines that come with Connections. I do not make any programmatic changes to the TDI assemblylines , although in reality, that’s what you’ll want to do if you want to deploy this solution in a production environment.
Note that there is no (out of the box) way to edit the deparments using “Edit my Profile” - a Department cannot log in to Connections. So all the information you want to store in the Organization’s/Department’s profile must be in the source where TDI syncs from, in this case LDAP.
End result
So in the end, I would have an actual profile for my departments (organization’s tree), which give me a lot of possibilities.
I could add a richtext field to them , to show more data about them, although I did not do that here.
I could also tag or let the organizations be tagged.
I can link users’ profiles to his organization’s profile,…
Notice the Report-to-Chain widget, which shows the hierarchy for the organization…
And what it was all about in the first place, I can show the organization tree, using the out of the box Reporting Structure feature in Connections…
Because the organizations are stored as profiles, the standard profile search applies. So if I do a search on keyword, “marketing”, I get the marketing departments together with the actual people. Visually, it’s pretty easy to distinguish them.
Also in the Full text search over Connections, the results will appear :
OK, now on to how to actually do this ….
Setup
Departments stored in LDAP
To store the departments in LDAP, I created an Organizational Unit (ou=Organization), and created the Departments with following attributes:
- used 2 objectclasses (organizationUnit and inetOrgPerson) - to have all the attributes available to me . To have matching attribute names for the mapping in TDI, this was the easiest solution (although I would not recommend it in a production environment).
- added the fields I intend to use in the Departments Profiles later on:
- sn : the lastname is required by Connections, so it needs to be added. It’s also a required field in the inetOrgPerson schema anyway.
- telexNumber : will be used to store the profile-type
- departmentNumber : contains the department number. Is not actually used, but will be synced to Profiles.
- manager : contains the higher level organization, so a tree can be constructed.
- searchGuide : a field that could contain a link to the profile of the Manager of the Department. The logic here is more applicable the other way around : the user’s profiles could contain links to the departments they belong to a similar way.
dn: cn=Corporate communications - 2C2,ou=Organization,dcÞMOS,dc=IBM,dc=COM
objectClass: person
objectClass: top**
objectClass: inetOrgPerson**
objectClass: organizationalPerson**
objectClass: organizationalUnit**
cn: Corporate communications - 2C2
ou: 2C2
sn: Corporate Communications**
departmentNumber: 2C2**
description: Corporate Communications
mail: organization.2C2@demos.connectionsww.ibm.com**
manager: cn=Corporate Communications - 2C1,ou=Organization,DCÞMOS,DC=IBM,DC=COM**
physicalDeliveryOfficeName: Office at the 3rd floor searchGuide: http://connectionsww.demos.ibm.com/profiles/html/profileView.do?email=nolmos@demos.ibm.com&lang=en secretary: cn=Vivian Hanley,DCÞMOS,DC=IBM,DC=COM telexNumber: organization
My full LDIF file is here : complete_organizations.ldif
TDI sync
TDI mapping
Since we now have the Organizations in LDAP, we just need to make some changes to the mappings and to the ldap search filter :
In
/opt/IBM/TDI/TDISOL/profiles_tdi.properties
I add a filter for the OrganizationalUnits (which do not have a uid).
source_ldap_search_filter=(|(&(uid=*)(objectclass=inetOrgPerson))(&(ou=*)(objectclass=organizationalUnit)))
In
/opt/IBM/TDI/TDISOL/map_dbrepos_from_source.properties
Change the following default mappings.
calendarUrl=seeAlso
deptNumber=departmentNumber
freeBusyUrl=searchGuide
profileType=telexnumber
The only real important field here is the profileType mapping, to `telexnumber, a field that we abuse in the LDAP. Since normal users do not have a telexnumber, they will be mapped to the “default” type. In practice, you would likely set the profileType in your assemblyline by scripting, so you don’t have to create a specific mapping for it and you don’t have to store it.
Now would be a good time to run a full sync, so the Profiles Database is updated.
/opt/IBM/TDI/TDISOL/sync_all_dns.sh
Photos
Now to make it easier to identify these new profiles as being “organizations” instead of real user profiles, it’s a good idea to give them a profile picture.
I’m using the out of the box Assemblyline that comes with Connections, and that you can run with the script load_photos_from_files.sh (in the TDISOL directory).
It depends on a file collect_photos.in (in the TDISOL directory) to contain a list of photo locations and then the uid of the user to assign it to.
I’ve put the photo (org.image.jpg) in the directory /opt/IBM/TDI/TDISOL/dump_photos/ and have following lines in the file
photo:file:/opt/IBM/TDI/TDISOL/dump_photos/org.image.jpg
uid:Office of the CEO
.
photo:file:/opt/IBM/TDI/TDISOL/dump_photos/org.image.jpg
uid:corporate communications - 2C1
.
(continues ...)
Run the script
/opt/IBM/TDI/TDISOL/load_photos_from_files.sh
This concludes the TDI configuration.