test

Sun Java System Communications Services 2005Q4 Release Notes

Setting up International Searches

Whether using Communications Express or Connector for Microsoft Outlook, performing search in your personal contacts or the public address book for a particular string is a locale-specific operation. For example, a French user searching for “Gaelle” expects to get back entries containing the string “Gaelle” but also any entry containing the string “Gaëlle.”

The various rules driving the way entries are presented to a user based on locale are called collation rules or collation order. The collation order provides language and cultural-specific information about how the characters of a given language are to be sorted. It identifies things like the sequence of the letters in the alphabet, how to compare letters with accents to letters without accents, and if there are any characters that can be ignored when comparing strings. The collation order also takes into account culture-specific information about a language, such as the direction in which the language is read (left to right, right to left, or up and down).

The Sun Java System Directory Server supports a large variety of locales and collation rules (See “Identifying Supported Locales” in the Sun Java System Directory Server 5 2005Q1 Administration Reference). Depending on your user base, you first need to choose the locale that makes the most sense in your environment. In the following, we will use the English (US) locale (OID = 1.3.6.1.4.1.42.2.27.9.4.34.1) as an example.

To specify which locale to use when performing a search, use the matching rule filter syntax, described in “Searching an Internationalized Directory” in the Sun Java System Directory Server 5 2005Q1 Administration Reference. This syntax lets you to specify the locale as well as the type of search (equality, substring, and so on).

For example, the following filter will perform a substring comparison (.6) on the CN attribute, using the English (US) collation rules (1.3.6.1.4.1.42.2.27.9.4.34.1). The filter looks at the CN for strings starting with “Gae”

cn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=Gae*

Updating the Indexes

When performing an LDAP search, most performance problems are due to the fact that indexes are not present or are not properly configured. By default, the Directory Server is configured so that lookups issued by Communications Express or by Connector for Microsoft Outlook are indexed and should return in a reasonable amount of time. Nevertheless, the Directory Server is not set up for international searches. So one need to alter the existing indexes so that they take into account the collation rules that have been chosen. This is described in the “Managing Indexes” section in the Sun Java System Directory Server 5 2005Q1 Administration Guide.

For example, the CN attribute is indexed by default in the userRoot suffix:

# ldapsearch -D "cn=Directory manager" -b 
"cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" 
"objectclass=*" 
cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config 
objectClass=top objectClass=nsIndex 
cn=cn 
nsSystemIndex=false 
nsIndexType=pres 
nsIndexType=eq 
nsIndexType=sub

To enable it for international searches using the English (US) collation rules, add one nsMatchingRule attribute with the English (US) OID. The clients perform substring searches so it is necessary to add the substring suffix (“.6”) to the OID :

#ldapmodify -D "cn=Directory manager"
dn: cn=cn,cn=index,cn=userRoot,cn=ldbm database, 
 cn=plugins,cn=config
changetype: modify
add: nsMatchingRule
nsMatchingRule: 1.3.6.1.4.1.42.2.27.9.4.34.1.6
Note –

Do not add any space, tab, or other non-visible characters at the beginning or at the end of the value.

Note –

The nsMatchingRule is a multivalued attribute. Different types of searches for the same OID, or different OIDs can be added.

One must then run the db2index.pl script located under serverroot/slapd-instance:

# perl db2index.pl -D "cn=Directory Manager" -w \ 
secret -n userRoot -t cn

This operation is run online and may take some time to finish. Alternatively the suffix can be reinitialized. See “Reinitializing a Suffix” in the Sun Java System Directory Server 5 2005Q1 Administration Guide.

The console can also be used to add the nsMatchingRule (see the “Managing Indexes” section in the Sun Java System Directory Server 5 2005Q1 Administration Guide).

In the following sections, the list of indexes that need to be modified is provided. Ensure that no non-indexed searches are performed. This can be done by looking at the Directory Server access log file (and looking for a notes=U in the search results entries).

Setting up the Search Filter in Communications Express

The search filter used by Communications Express needs to be changed to accommodate the matching rule syntax. This is achieved by enabling the collation rule parameters specified in the db_config.properties file (which resides under deployed-path/WEB-INF/ldappstore (for personal store) and deployed-path/WEB-INF/corp-dir (for corporate directory).

The parameters are:

# Collation Rule
# Uncomment below to apply collation rule

# collation_rule=en-US

# Search Fields for which collation rule should be applied.
# The fields provided here should be disambiguator formatted fields
# e.g. entry/displayname, person/givenname etc.
# Uncomment below to supply the comma-separated fields

# search_fields=entry/displayname

Uncomment the collation_rule and search_fields parameters to enable the collation rule. In order to specify a separate set of field or fields in the search, change the value of search_fields to the desired values. The collation_rule can contain either the language tag or the OID corresponding to that language (in the example 1.3.6.1.4.1.42.2.27.9.4.34.1) without the suffix specifying the type of search. The Web Container Instance needs to be started after making the change.

The following attributes should be indexed on the LDAP Server for international search against Communications Express: