Leverage SharePoint Search to Create a Department Directory

  • May 26, 2010
  • By Paul Galvin
  • More Articles »
Leverage SharePoint Search to Create a Department Directory Fashion a one-click company directory that always returns up-to-the-minute department member information. SharePoint intranets almost always feature company department sites. These include such departments as HR, Information Technology, Manufacturing, Legal, etc. Companies frequently want to create a one-click department directory for site visitors. For some people, the natural instinct is to reach for an out-of-the-box contacts list and populate it with department members' information. That's not a great idea.

Using Microsoft Office SharePoint Server's search function (or Windows SharePoint Wervices 3.0 plus Search Server Express), we can create a one-click company directory that always returns up-to-the-minute accurate department member information that pulls its data from a central repository (usually Active Directory). There's no need to explicitly maintain a department level contact list which inevitably gets out of sync with Active Directory when new people are added, folks transfer to departments or separate from the company for one reason or another.

Solution Overview

The core solution relies upon SharePoint's People Search functionality. People Search operates off the SharePoint user profile. SharePoint populates its user profile database by extracting content from a membership source which is normally a company's Active Directory.

We normally think of search as an interactive "type a search term and click search" operation. However, SharePoint provides more than a dozen individual web parts out of the box, one of which allows us to specify a hard coded query. This web part, the core results web part, allows us to specify some search terms and drop it onto a page. Every time a user visits that page, the query executes automatically and renders its results.

Figure 1: People Search core results.

Finally, the core results web part lets us override the default results view by providing our own XSL transformations. Using this approach, we can create a nicely sorted grid view, thus closing the loop on the kind of functionality that our users will expect: a nicely formatted listing of all department contacts sorted by last name.

Implementing the Solution

Access your favorite SharePoint sandbox environment and add the core results search web part to a web part zone. Modify the web part's properties to specify a hard coded query that says in English, "Return all users who are members of the IT department." Specifically, edit the web part's properties and specify the fixed keyword query:
    Department:"IT"
Replace "IT" with the department you want to use for testing.

Next, we need to tell the general-purpose core results web part to use its own fixed keyword query instead of one that might have been passed to it via an end user specified search query. We do this by changing the web part property, "Cross-Web Part query ID." The drop-down presents several options. Selected "Query 2". When you finish your properties will look similar to Figure 2:

Figure 2: Web Part Properties

If you click OK at this point, you'll get the usual SharePoint people search results in a list format similar to Figure 3:

Figure 3: People Search results list format.

Finally, we need to create the grid output, sorting by name. This is the only part that is at all tricky. Our goal is to an HTML structure along these lines: 
<html>
  <body>
    <table>
      <tr><td>Heading1</td><td>Heading2</td> [add more headings needed]</tr>
      <tr><td>[data]</td><td>[data heading 2</td>[add more data cols as needed</tr>
    </table>
  </body>
</html>
How do we do that? Let's take a quick step back. When the web part executes the query, it is sending a message to the search service saying "give me everyone that belongs to the IT department." The search services responds with an XML message containing the content. It's just a big jumble, however. It's not sorted in any particular way and not suited for direct human consumption. The answer is XSL - we transform the XML to HTML and sort it along the way. To create a sorted and tabular / grid layout, we need to override the XSL. The following bit of XSL solves the sorting problem:

Figure 4: XSL to Sort Search results.

The rest of it is a simple matter of emitting the table, tr and td structure we want.

And that's it. We've use the core results search web part to invoke our hard coded department contacts query and formatted the results. This is what it can look like in the end:

Figure 5: Sample output.

Modify the XSL to create your own HTML output and structure as per your needs.

Conclusion

We can drop a people search core results web part onto a web page and specify a fixed query and rendering (e.g. sorted grid format). When users visit that page, the search runs automatically and show the content with no user intervention. Finally, SharePoint is continually updating user profiles. There's no need to maintain a separate department contacts list that quickly grows stale, frustrating your users and harming SharePoint's reputation in the organization.
1


Networking Solutions







Partners















Jupitermedia Coorporation