Queries are sent to the Address Book Web Query Server by using HTTPS (or HTTP if configured through the URL). The ASP.net first pre-processes the query and forms an SQL query, which is executed by the SQL Server (or SQL Server Express for SE) using the RTCAb database. Next, post-processing of the results occurs (that is, constructing the information to be sent to the client). The query results are then returned to the client.

Following are sample URLs for internal and external Address Book Web Server queries. The specific search attributes are not included.

https://server.contoso.com/GroupExpansion/int/service.asmx?op=QueryAbContacts

https://server.contoso.com/GroupExpansion/ext/service.asmx?op=QueryAbContacts

The following table lists the RTCAb database fields that are extracted from the RTC database by ABServer.exe.

Table 1. RTCAb Database Fields

The RTCAb database is designed so that additional search fields can be easily added to the database (adding additional fields is currently not supported). The example in the following table shows sample data in the AbAttributeValue table, which is the primary table in the RTCAb database that is used for queries. The UserIDcolumn maps to an address book entry (for example, a user or contact object). The AttrIDcolumn identifies the attribute (see the previous table), the Valuecolumn is the alpha-numeric value of the attribute (for example, “Bill Malone”), and the DTMFcolumn encodes the string value in a numeric format for predictive text dial pad.

Table 2. Sample AbAttributeValue Table

Note:
The digit 1 in the dual-tone multifrequency (DTMF) interface is used for various characters (for example, !, @, ., -) and the digits 0 and 1. The symbol * is used to represent a space or other separators.

Currently, Office Communicator is the only client that leverages the Address Book Web Query Service. The Address Book Web Query Service supports a wide set of query options.

The following table contains the parameters and default values that can be processed by the Address Book Web Query Service. Although it is not possible for users or administrators to modify this query, this table helps demonstrate how Address Book Query works and how queries may differ for future clients that may leverage this service.

Table 3. Parameters and Default Values

The following table lists parameters that Communicator Mobile uses. These are hardwired into Communicator Mobile and cannot be changed.

Table 4. Communicator Mobile Parameters

Currently the Address Book Server only supports name-based queries based on display name. It does not support queries based on the Active Directory entries for last name (that is, SN), first name (that is, givenName), and so on. It may also match the user part of the Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) or e-mail address. To support names typed in different orders (for example, “Sara Davis”, “Davis, Sara”, and “Davis Sara”) and users with multiple first or last names (for example, “Pablo Rovira Diez”), multiple entries are placed into the AbAttributeValue table for the display name. For example, the following entries are placed in the table for Pablo Rovira Diez:

Pablo Rovira Diez

Diez Pablo Rovira

Diez, Pablo Rovira

Rovira Diez Pablo

Rovira Diez, Pablo

Since the Address Book Web Query Service leverages the SQL LIKE string matching expression, all of the following strings will match at least one of the table entries, and will return “Diez Pablo Rovira” as a match (in addition to other possible matches).

Pa

Pablo

Pablo Rovira

Diez Pablo

Diez, P

Rovira

Rovira Diez P

Rovira Diez, P

However the following strings will not create a match:

Rovira Pablo

Pablo Diez

The general case for display name index generation is as follows:

• Simple Case
  
  
  • DisplayName = "A B" will support
    
    
    • A B
      
      
    • B a (Inversed)
      
      
    • B,A (Inversed with Comma)
      
      
    • Generates 3 indices
      
      
• Complex Case
  
  
  • Display Name = “A B C D E” will support
    
    
    • A B C D E
      
      
    • D E A B C (Last 2 words)
      
      
    • D,E A B C (Last 2 words with Comma)
      
      
    • E A B C D (Last word)
      
      
    • E, A B C D (Last word with Comma)
      
      
    • Generates 5 indices (no more, no less)
      
      

In the case where there are more than two words in the last name, the index based on the display name will most likely need to be leveraged to obtain the desired match.

To support practical queries based on phone numbers, a number of indices are created. By leveraging the SQL LIKE expression (that is, partial match), you can use a number of useful options for searching phone numbers.

The RFC 3966/E.164 phone number “+1.425.555.0101” will get entries with the following indexes:

• +1.425.555.0101
  
  
• 4255550101
  
  
• 5550101
  
  
• 0101
  
  
• 14255550101
  
  
• Tel:+14255550101
  
  
• 14255550101
  
  

The RFC 3966/E.164 phone number “+01 (23) 456789 x01” will get entries with the following indexes:

• +01.23.456789.01
  
  
• 012345678901
  
  
• 2345678901
  
  
• 45678901
  
  
• 01
  
  
• 0123456789
  
  
• Tel:+0123456789;ext=01
  
  

Address Book Web Query also pre-processes queries to remove any extraneous symbols. For example, the string +1(425) 555-0101 would be translated to 14255550101 before running the query.

Currently, Communicator Mobile only retrieves for the first 20 matches for a given query. The Address Book Query Server searches for the first 100 matches for any query, of which only the first 20 entries in the result set are passed back to the client (that is, based on the actual query sent by the client). For performance reasons the Address Book Query Server does not attempt to process more than 100 matches. For example, if a user tries to query “Bo”, only the first 100 matches that SQL Server finds are returned. In cases where there are more than 100 potential matches, the query does not fetch every attribute that begins with a “Bo” (for example, every user with a first name or last name that begins with a “Bo”, a SIP URI that begins with a “Bo”, and so on) and sort them, as this would take up significant database cycles. Although this is not optimal, it achieves a decent tradeoff between functionality and performance. In general, most users refine their query and re-submit it rather than scrolling through pages of query results.

There are a few issues when a user attempts to search for a common name. For example, if a user searched for “Daniel” and there were more than 100 “Daniels” in the address book, 100 random matches would be returned and subsequently sorted. The user may see “Daniel Park” and “Daniel Taylor” sequentially and assume that “Daniel Roman” (that is, alphabetically between Park and Taylor) is not in the address book. However, this is not necessarily the case because “Daniel Roman” may not have been in the set of 100 entries returned and would not be presented in the list. In this case the user would be expected to enter a more refined query.

The AbAttributeValue database table also has a column for DTMF queries. This is a special index created to support predictive text queries where telephone dial pads are used to enter queries. For example, the digit 2 could represent an “A”, “B” or “C”. Thus if a user keyed in “226”, it would match any existing entries that start with “226” in the DTMF column (for example, “Cam”, “Cameron”, “Candice”, “Bam”, etc.). Although this query is supported by the Address Book Web Query Server, there are no clients that currently leverage this interface.

Note:
Communicator Mobile performs numeric matches on office and mobile phone numbers and any SIP or e-mail address that leverages digits. However these queries do not leverage the predictive text query algorithms.

The Address Book Web Query RTCAb database is collocated as a separate SQL Server instance on the same SQL Server as the RTC database for the given pool. The database leverages the same high availability features as the RTC database. The database should also be included in any backup plan, although historical copies are not relevant and the database can be regenerated by using the ABServer –syncnowcommand.

The database is implemented by using two database partitions, where each partition contains a complete copy of the address book. At any given point in time, one partition is active, which means it is being used by Address Book Web Query Server for handling queries from clients. The other partition is then available to the ABServer.exe process for the next nightly update. After the update process is finished (that is, committed to the database), this new partition becomes active. This technique helps enable optimal performance as there are no locking contention issues in the database (that is, all queries are read-only).

The size of the RTCAb is modest and is dependent on the number of contacts in the address book and the number of fields populated. SQL Server also reserves significant space for the creation and maintenance of the database and various indices.

The Address Book Web Query RTCAb database currently uses the Latin1_General_CI_AI (that is, Case Insensitive, Accent Insensitive) database collation. In SQL Server, collations control various language-specific rules for how comparisons (that is, SQL = and LIKE) and sorts (that is, SQL ORDER BY) behave. The Latin1_General collation supports various Latin-based languages that have the same superset of order and sorting rules, including Dutch, English, German, Italian, and Portuguese/ Brazilian.

There are languages where the general rules of Latin largely apply to (for example, Modern Spanish and French) but may have some subtle issues around comparison and sorting (for example, certain ligatures may not be correctly sorted). For other languages, such as Japanese and Simplified Chinese, where the rules of Latin have no influence, sorting and comparison are dictated by the underlying characteristics of Unicode. In languages with a large number of characters, users often rely on exact match and not necessarily matches based on a partial letter match. Not having correct alphabetical ordering may not be as much of an issue as it is with languages like English.

The Address Book Web Query Server and RTCAb database generally only have a minimal impact on performance the Web Components Server (typically running on the Front-End servers) and the back-end server. Currently, only the Communicator Mobile clients use Address Book Web Query Server and queries on this device are explicitly controlled by the user when they use the Search function, as opposed to being performed automatically as a user types in a name or phone number.

The Address Book Web Query ASP.net process is relatively lightweight and the back-end database processing is all read-only queries on a database that is updated once per day. The Address Book Query service does not pose any significant performance bottleneck, and whatever impact it has can be resolved by general performance tuning on the front-end and back-end servers.