Serveur de carnet d’adresses : service de requête sur le Web du carnet d’adresses

Article
03/23/2012

Dernière rubrique modifiée : 2012-02-01

Les requêtes du serveur de requête sur le Web du carnet d’adresses sont transférées du client à ce dernier via HTTPs (ou HTTP si configuré). Les URL internes et externes sont configurées sur le serveur sur lequel sont exploités à la fois le serveur de requête sur le Web du carnet d’adresses et le développement de la liste de distribution. Ces URL sont alors transférées aux clients par l’intermédiaire des paramètres de mise en service de la bande entrante intradlxInternalUrl et dlxExternalUrl.

Les requêtes sont envoyées au serveur de requête sur le Web du carnet d’adresses à l’aide de HTTPS (ou HTTP si configuré via l’URL). ASP.net prétraite la requête et forme une requête SQL qui est exécutée par le serveur SQL Server (ou SQL Server Express pour SE) à l’aide de la base de données RTCAb. Le post-traitement des résultats (c’est-à-dire la construction des informations à envoyer au client) intervient alors. Les résultats de la requête sont ensuite retournés au client.

Voici des exemples d’URL pour les requêtes internes et externes du serveur de requête sur le Web du carnet d’adresses. Les attributs de recherche spécifiques ne sont pas inclus.

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

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

Le tableau suivant répertorie les champs de la base de données RTCAb qui sont extraits de la base de données RTC par ABServer.exe.

Tableau 1. Champs de la base de données RTCAb

Nom	Nom Active Directory	ID d’attribut	Exemple
Nom complet	displayName	4	« Sara Davis », « Dan G Fennell »
Numéro du bureau	telephoneNumber	10	1.425.555.0101
Numéro de portable	Mobile	13	1.425.555.0198
Adresse SIP	msRTCSIP_PrimaryUserAddress	9	sarad@contoso.com
Adresse de messagerie principale	proxyAddress	18	sarad@contoso.com , sara.davis@contoso.com

La base de données RTCAb est conçue de sorte que les champs de recherche supplémentaires puissent être facilement ajoutés à la base de données (la fonction d’ajout de champs supplémentaires n’est pas prise en charge actuellement). Ce tableau fournit des exemples de données figurant dans la table AbAttributeValue, qui est la table principale de la base de données RTCAb utilisée pour les requêtes. La colonne UserID mappe sur une entrée de carnet d’adresses (par exemple, un utilisateur ou un objet contact). La colonne AttrID identifie l’attribut (voir le tableau précédent), la colonne Value affiche la valeur alphanumérique de l’attribut (par exemple, « Bill Malone ») et la colonne DTMF encode la valeur de chaîne dans un format numérique pour un pavé de numérotation de prédiction de texte.

Tableau 2. Exemple de table AbAttributeValue

Ptrn	UserId	AttrId	Valeur	DTMF (index du pavé de numérotation)
1	365649	10	+1 (425) 5550198 X50198	14255550198*50198
1	365649	10	14255550198	14255550198
1	365649	10	4255550198	4255550198
1	365649	10	5550198	5550198
1	365649	10	0198	0198
1	365649	4	Bill Malone	2455*42837
1	365649	9	Billm	24556
1	365649	9	billm@contoso.com	24556126686761266
1	365649	17	billm@contoso.com	24556126686761266
1	365649	18	billm@contoso.com	24556126686761266
1	365649	18	billm@msg.Contoso.com	245561674126686761266
1	365649	18	billm@titanium.contoso.com	24556184826486126686761266
1	365649	18	billmcontoso.com	2455626686761266
1	365649	18	2455626686761266	24556674126686761266
1	365649	18	billmtitanium.contoso.com	2455684826486126686761266

Remarque :
Le chiffre 1 de l’interface DTMF (dual-tone multifrequency) est utilisé pour divers caractères (par exemple, !, @, ., -) et pour les chiffres 0 et 1. Le symbole * est utilisé pour représenter un espace ou d’autres séparateurs.

Requêtes du carnet d’adresses Office Communicator

Actuellement, Office Communicator est le seul client qui exploite le service de requête sur le Web du carnet d’adresses. Ce service prend en charge un large éventail d’options de requête.

Le tableau suivant contient les paramètres et les valeurs par défaut qui peuvent être traités par le service de requête sur le Web du carnet d’adresses. Bien que les utilisateurs ou les administrateurs ne puissent pas modifier cette requête, ce tableau permet de démontrer comment fonctionne la requête du carnet d’adresses et en quoi les requêtes peuvent être différentes pour des clients futurs susceptibles d’exploiter ce service.

Tableau 3. Paramètres et valeurs par défaut

Paramètre	Type	Par défaut	Remarques
QueryString	Chaîne		Expression pour la requête
Dial	Booléen	True	Détermine si une requête de recherche de prédiction est effectuée (par exemple, les requêtes du pavé de numérotation qui exploitent l’index DTMF)
PrefixQueryAttributes	Chaîne	displayName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, mobile	Attributs pour lesquels l’opérateur de comparaison SQL LIKE est utilisé (par exemple, « Cam » correspond à « Cameroun »)
ExactQueryAttributes	Chaîne	displayName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, mobile	Attributs pour lesquels l’opérateur de comparaison SQL = est utilisé (par exemple, « Cam » ne correspond pas à « Cameroun »)
RequestTimeout			Délai d’expiration de la requête
MaxResult	Int	50	Nombre maximal de résultats à retourner
ReturnAttributes	Chaîne	givenName, sn, displayName, mailNickName, physicalDeliveryOfficeName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, homePhone, otherHomePhone, mobile, otherMobile, otherTelephone, ipPhone, mail, manager	Ensemble d’attributs par défaut à être retournés à l’utilisateur. Bon nombre de ces attributs ne peuvent pas être utilisés dans l’expression de la chaîne de requête

Le tableau suivant répertorie les paramètres que Communicator Mobile utilise. Ces derniers sont programmés dans Communicator Mobile et ne peuvent pas être modifiés.

Tableau 4. Paramètres de Communicator Mobile

Paramètre	Type	Par défaut	Notes
QueryString	Chaîne		Expression pour la requête
Dial	Booléen	False	Ne prend pas en charge les requêtes de pavé de numérotation
PrefixQueryAttributes	String	displayName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, mobile	Utilise une correspondance de préfixe (SQL LIKE)
ExactQueryAttributes	String
RequestTimeout			Délai d’expiration de la requête
MaxResult	Int	20	Économise de la bande passante réseau
ReturnAttributes	String	givenName, sn, displayName, mailNickName, physicalDeliveryOfficeName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, homePhone, otherHomePhone, mobile, otherMobile, otherTelephone, ipPhone, mail, manager	Ensemble d’attributs par défaut à être retournés à l’utilisateur. Bon nombre de ces attributs ne peuvent pas être utilisés dans l’expression de la chaîne de requête

Requêtes sur le nom d’affichage

Actuellement, le serveur de carnet d’adresses prend uniquement en charge les requêtes de noms fondées sur le nom complet. Il ne prend pas en charge les requêtes fondées sur les entrées Active Directory pour le nom de famille (c’est-à-dire, SN), le prénom (c’est-à-dire, givenName), etc. Il peut également correspondre au composant utilisateur de l’URI (Uniform Resource Identifier) SIP (Session Initiation Protocol) ou à l’adresse de messagerie. Pour prendre en charge les noms tapés dans des ordres différents (par exemple, « Sara Davis », « Davis, Sara » et « Davis Sara ») et les utilisateurs qui ont plusieurs prénoms ou noms de famille (par exemple, « Pablo Rovira Diez »), plusieurs entrées sont placées dans la table AbAttributeValue pour le nom complet. À titre d’exemple, les entrées suivantes sont placées dans la table pour Pablo Rovira Diez :

Pablo Rovira Diez

Diez Pablo Rovira

Diez, Pablo Rovira

Rovira Diez Pablo

Rovira Diez, Pablo

Dans la mesure où le service de requête sur le Web du carnet d’adresses exploite l’expression de correspondance de la chaîne SQL LIKE, toutes les chaînes suivantes correspondront à l’une des entrées de table, et retourneront « Diez Pablo Rovira » en tant que correspondance (en plus des autres correspondances possibles).

Pablo

Pablo Rovira

Diez Pablo

Diez, P

Rovira

Rovira Diez P

Rovira Diez, P

Cependant, les chaînes suivantes ne créent pas de correspondance :

Rovira Pablo

Pablo Diez

Typiquement, la génération d’index de nom complet est la suivante :

Cas simple
- DisplayName = « A B » seront pris en charge
  - A B
  - B a (inversés)
  - B,A (inversés avec une virgule)
  - Génère 3 index
Cas complet
- Nom complet = « A B C D E » seront pris en charge
  - A B C D E
  - D E A B C (les deux derniers mots)
  - D,E A B C (les deux derniers mots avec une virgule)
  - E A B C D (le dernier mot)
  - E, A B C D (le dernier mot avec une virgule)
  - Génère 5 index (ni plus, ni moins)

Dans le cas où le nom de famille contient plus de deux mots, il conviendra certainement d’exploiter l’index fondé sur le nom complet afin d’obtenir la correspondance souhaitée.

Requêtes sur les numéros de téléphone

Pour prendre en charge les requêtes pratiques fondées sur les numéros de téléphone, un numéro d’index est créé. En exploitant l’expression SQL LIKE (c’est-à-dire, correspondance partielle), vous pouvez utiliser un nombre d’options utiles pour rechercher des numéros de téléphone.

Le numéro de téléphone RFC 3966/E.164 « +1.425.555.0101 » obtiendra les entrées avec les index suivants :

+1.425.555.0101
4255550101
5550101
0101
14255550101
Tel:+14255550101
14255550101

Le numéro de téléphone RFC 3966/E.164 « +01 (23) 456789 x01 » obtiendra les entrées avec les index suivants :

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

La requête sur le Web du carnet d’adresses prétraite également les requêtes afin de supprimer tout symbole étranger. Par exemple, la chaîne +1(425) 555-0101 serait traduite par 14255550101 avant l’exécution de la requête.

Tri des résultats de la requête

Actuellement, Communicator Mobile extrait uniquement les 20 premières correspondances pour une requête donnée. Le serveur de requête sur le Web du carnet d’adresses recherche les 100 premières correspondances pour toute requête, desquelles seules 20 entrées de l’ensemble de résultats sont retransférées au client (c’est-à-dire, en fonction de la requête réelle envoyée par le client). Pour des raisons de performance, le serveur de requête sur le Web du carnet d’adresses n’essaie pas de traiter plus de 100 correspondances. Par exemple, si un utilisateur essaie d’effectuer la requête sur « Bo », seules sont retournées les 100 premières correspondances trouvées par SQL Server. Dans les cas où il existe plus de 100 correspondances potentielles, la requête ne cherche pas chaque attribut qui commence par « Bo » (par exemple, chaque utilisateur dont le prénom ou le nom de famille commence par « Bo », un URI SIP qui commence par « Bo », etc.) et les trie, car cela impliquerait des cycles de bases de données significatifs. Bien que cette solution ne soit pas optimale, elle permet d’atteindre un certain équilibre entre fonctionnalité et performance. En général, la plupart des utilisateurs affinent leur requête et la soumettent à nouveau au lieu de faire défiler les pages de résultats.

Lorsqu’un utilisateur essaie de rechercher un nom courant, il rencontre quelques problèmes. À titre d’exemple, si un utilisateur recherche « Daniel » et qu’il existe plus de 100 « Daniel » dans le carnet d’adresses, 100 correspondances aléatoires seraient retournées et triées de manière aléatoire. L’utilisateur pourrait voir « Daniel Park » et « Daniel Taylor » à la suite et en conclure que « Daniel Roman » (c’est-à-dire, alphabétiquement situé entre Park et Taylor) n’est pas dans le carnet d’adresses. Toutefois, cela n’est pas nécessairement le cas car « Daniel Roman » n’est peut-être pas dans le jeu des 100 entrées retournées et ne serait pas présenté dans la liste. Dans ce cas, l’utilisateur devrait affiner davantage sa requête.

Requêtes de prédiction de texte

La table de base de données AbAttributeValue dispose également d’une colonne pour les requêtes DTMF. Il s’agit d’un index spécial créé pour prendre en charge les requêtes de prédiction de texte pour lesquelles les pavés de numérotation de téléphone sont utilisés pour entrer des requêtes. Par exemple, le chiffre 2 peut représenter un « A », « B » ou « C ». Ainsi dans le cas où un utilisateur a tapé « 226 », cela correspondrait à toutes les entrées existantes commençant par « 226 » dans la colonne DTMF (par exemple, « Cam », « Cameron », « Candice », « Bam », etc.). Bien que cette requête soit prise en charge par le serveur de requête sur le Web du carnet d’adresses, aucun client n’exploite actuellement cette interface.

Remarque :
Communicator Mobile effectue des correspondances numériques sur les numéros de bureau et de téléphones portables et toutes les adresses SIP ou de messagerie électronique qui exploitent des chiffres. Cependant, ces requêtes n’exploitent pas les algorithmes.

Base de données de requête sur le Web du carnet d’adresses

La base de données RTCAb de requête sur le Web du carnet d’adresses est colocalisée en tant qu’instance SQL Server distincte sur le même serveur SQL Server que la base de données RTC pour un pool donné. La base de données exploite les mêmes fonctionnalités à haute disponibilité que la base de données RTC. Celle-ci doit également faire partie d’un plan de sauvegarde, même si les copies historiques ne sont pas pertinentes et que la base de données peut être générée à nouveau avec la commande ABServer –syncnow.

La base de données est mise en œuvre à l’aide de deux partitions de base de données où chaque partition contient une copie complète du carnet d’adresses. À tout moment, une partition est active, ce qui signifie qu’elle est utilisée par le serveur de requête sur le Web du carnet d’adresses pour traiter les requêtes émanant des clients. L’autre partition est alors disponible pour le processus ABServer.exe en vue de la prochaine mise à jour nocturne. Une fois le processus de mise à jour terminé (c’est-à-dire, validé dans la base de données), cette nouvelle partition devient active. Cette technique permet une performance optimale car il n’existe aucun problème de conflit de verrouillage dans la base de données (c’est-à-dire, toutes les requêtes sont en lecture seule).

La taille de RTCAb est modeste et dépend du nombre de contacts dans le carnet d’adresses et du nombre de champs renseignés. SQL Server réserve également un espace significatif pour la création et la maintenance de la base de données et des nombreux index.

Prise en charge de la langue de la base de données de requête sur le Web du carnet d’adresses

La base de données RTCAb de requête sur le Web du carnet d’adresses utilise actuellement le classement de base de données Latin1_General_CI_AI (c’est-à-dire, ne tenant compte ni de la casse, ni des accents). Dans SQL Server, les classements contrôlent plusieurs règles propres à la langue qui déterminent le comportement des comparaisons (c’est-à-dire, SQL = et LIKE) et des tris (c’est-à-dire, SQL ORDER BY). Le classement Latin1_General prend en charge de nombreuses langues d’origine latine qui ont le même sur-ensemble de règles de classement et de tri, notamment, l’allemand, l’anglais, l’italien, le néerlandais et le portugais du Brésil.

Il existe d’autres langues auxquelles s’appliquent largement les règles générales du latin (par exemple, l’espagnol moderne et le français) mais qui présentent quelques problèmes mineurs en termes de comparaison et de tri (par exemple, certains diagrammes groupés peuvent ne pas être triés correctement. Dans le cas d’autres langues, telles que le japonais et le chinois simplifié sur lesquelles les règles latines n’ont aucune influence, le tri et la comparaison sont dictées par les caractéristiques sous-jacentes de l’Unicode. Pour les langues comportant un grand nombre de caractères, les utilisateurs comptent sur une correspondance parfaite et pas nécessairement sur des correspondances fondées sur une correspondance partielle de lettres. L’absence de classement alphabétique correct pose moins de problème qu’avec une langue comme l’anglais.

Performance du serveur de requête sur le Web du carnet d’adresses

Le serveur de requête sur le Web du carnet d’adresses et la base de données RTCAb ont généralement un impact limité sur la performance du serveur de composants Web (qui s’exécute le plus souvent sur les serveurs principaux) et le serveur principal. Actuellement, seuls les clients Communicator Mobile utilisent le serveur de requête sur le Web du carnet d’adresses ; les requêtes sur l'appareil sont explicitement contrôlées par l’utilisateur lorsqu’il se sert de la fonction de recherche par opposition à l’exécution automatique au fil de la saisie par l’utilisateur d’un nom ou d’un numéro de téléphone.

Le processus ASP.net de requête sur le Web du carnet d’adresses est relativement léger et le traitement de la base de données principale consiste en requêtes en lecture seule effectuées sur une base de données qui est mise à jour une fois par jour. Le service de requête sur le Web du carnet d’adresses ne pose pas de problème de goulots d’étranglement significatifs, et quel que soit leur impact, ils peuvent être résolus par un réglage général de la performance sur les serveurs frontaux et principaux.

Voir aussi

Concepts

Address Book Server Drilldown

Partager via