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.

Sujay V Sarma