Adding an Address Book to your KMS

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