Adding an Address Book to your KMS

Sujay V Sarma

Last time we saw how to manage documents better by placing them in a central workspace like environment and adding version control to it. This time, we take up another branch of our knowledge management system and centralize that as well. This is your organization's contacts database. Having up-to-date contact information of your business partners and potential customers is vital to the growth of your enterprise. So how do you ensure that everyone has access to this information? Better still, how do you control access while ensuring availability of your address books to all concerned? The way out is to use a centralized address book server (like an LDAP server). Let's be upfront about one factor here-this system will still not prevent people from having their own gloat-ware address books that contain carefully selected addresses that the person does not wish to reveal. 

Two-pronged database
Our address book is a dual-purpose database. It will contain information about your internal contacts as well as those of external agencies. This is easily achieved if you run a domain based network, with an LDAP server at the core. Then, this LDAP server will already have information about your users. Do note that the more the number of domains you have in your network, the more complicated (by scale) this solution will be. In our example, we shall be using a single-domain network. This can be scaled up easily by looping the code for each domain in your environment.

The IsInternal flag, if set to 1, means that the entry is for an employee of our organization. In such a case, you might want to fill in the employee's ID as well. The department (such as 'Shop Floor') and role ('Manager') information can help you quickly locate all the entries of people in a particular department or role to send them information quickly. Typically, such information would also be available in your employee master table or in the fields of your LDAP server if these have been properly and fully entered (most administrators usually just fill in a name, user name and password, leaving the rest of the contact information blank). We do not have the traditional address book 'Alias' field here since this is a central database and aliases would be particular to finer groups of people within the organization. If you like, you can add an additional field here to indicate which of your domains the user resides on. This will simplify synching up the information from your domain controllers.

While the information for external contacts can be easily entered through a simple data entry web page, you may want to capture internal contact information from your LDAP server to avoid duplication of work. Please note that if you're using MS Exchange as your messaging server, you're still using LDAP at the backend. 

Retrieving from LDAP
The simplest way to retrieve information is to query for records of type 'User' or 'Contact' in your domain. The 'User' record entities would also have associated Windows user accounts (as in they can login to the network) while the 'Contact' record entities are simply address book entries. The typical query to do this would be as simple as (function 'FindEmail', you need to include System.DirectoryServices for this to work):

Public Function FindEmail(ByVal UserName As String, _
Optional ByVal DomainName As String=””) As String
Dim eRoot, eDomain As DirectoryEntry
Dim dsSearcher As DirectorySearcher
Dim sResult = SearchResult
If (DomainName = “”) Then
eRoot = New DirectoryEntry(“LDAP://RootDSE”)
DomainName = eRoot.Properties( _
“defaultNamingContext”)(0)
End If
eDomain = New DirectoryEntry(“LDAP://” & DomainName)
dsSearcher = New DirectorySearcher()
With dsSearcher
.Filter = “(SAMAccountName=” & UserName & “)”
.PropertiesToLoad.Add(“mail”)
sResult = .FindOne()
End With

If (sResult Is Nothing) Then Return “”
Return sResult.Properties(“mail”)
End Function

Now, if you have multiple domains in the organization, or even multiple organizations (that is as sites and forests), then simply use multiple snippets of the above code (or in a loop) to retrieve the relevant information. You could simplify the same by using conditional loops if enough information about what is being searched for has been provided. For instance, if you have three domains 'foo1.com' to 'foo3.com', and the searcher has specified that the contact is a member of 'foo2.com', then you could search only that domain. And then there would be the connector to the messaging system we're going to build in next month.

Disconnected system
For this, we implement a Web service in ASP.NET that takes in the query values along with what kind of information (telephone, messenger ID or e-mail address) to return, performs the search through our above search engine and returns an XML reply to the caller. The code for this is similar to the FindEmail function described above, except that instead of doing a Return with the e-mail address, it sends it back as an XML string:

John Doe
john.doe@foo.com

Other than this, we can have multiple contact cards and fields (like phone number, department and so on) in this returned data that corresponds to multiple contacts or search hits. We'll build the messaging module with our workflow system next month.

Source: PCQuest