Partager via


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

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

1*425*5550198*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

Ee303799.note(fr-fr,office.13).gifRemarque :
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).

Pa

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.

Ee303799.note(fr-fr,office.13).gifRemarque :
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