Synchronisation de la boîte aux lettres et les services EWS d'Exchange

Découvrez comment fonctionne la synchronisation de boîte aux lettres lorsque vous utilisez EWS pour accéder à Exchange.

EWS dans Exchange utilise deux types de synchronisation pour récupérer le contenu de la boîte aux lettres et les modifications apportées au contenu de la boîte aux lettres :

• Synchronisation des dossiers
• Synchronisation d’éléments

Dans cet article, vous allez découvrir les deux types de synchronisation, le fonctionnement de la synchronisation, les modèles de conception de synchronisation et les meilleures pratiques de synchronisation.

Synchronisation des dossiers et des éléments

La synchronisation de dossiers synchronise une structure de dossiers ou une hiérarchie de dossiers. La synchronisation d’éléments synchronise les éléments d’un dossier. Lorsque vous synchronisez des éléments, vous devez synchroniser chaque dossier de la boîte aux lettres indépendamment. Vous pouvez utiliser EWS ou l’API managée EWS dans votre application pour implémenter la synchronisation des dossiers et des éléments.

Tableau 1. Opérations EWS et méthodes d’API managée EWS pour la synchronisation des dossiers et des éléments

Opération EWS	Méthode d'API managée EWS
SyncFolderHierarchy	Méthode ExchangeService.SyncFolderHierarchy
SyncFolderItems	Méthode ExchangeService.SyncFolderItems

L’étendue de la synchronisation qui se produit varie selon qu’il s’agit d’une synchronisation initiale ou en cours, comme suit :

• Une synchronisation initiale synchronise tous les dossiers ou éléments du serveur avec le client. Après la synchronisation initiale, le client a un état de synchronisation qu’il stocke pour les synchronisations ultérieures. L’état de synchronisation représente toutes les modifications sur le serveur que le serveur a communiquées au client.
• Les synchronisations en cours synchronisent tous les éléments ou dossiers qui ont été ajoutés, supprimés ou modifiés depuis la synchronisation précédente. Le serveur utilise l’état de synchronisation pour calculer les modifications à signaler au client pendant chacune des boucles de synchronisation en cours.

Chaque méthode ou opération de synchronisation retourne une liste de modifications, et non le dossier ou le message réel qui a changé. Les modifications apportées aux éléments et dossiers sont signalées au moyen des types de modifications suivants :

• Créer — Indique qu’un nouvel élément ou dossier doit être créé sur le client.
• Mettre à jour — Indique qu’un élément ou un dossier doit être modifié sur le client.
• Supprimer — Indique qu’un élément ou un dossier doit être supprimé sur le client.
• ReadStateChange pour EWS ou ReadFlagChange pour l’API managée EWS — Indique que l’état de lecture de l’élément est passé de non lu à lu ou non lu.

Dans Exchange Online, Exchange Online dans le cadre d’Office 365 et les versions d’Exchange à partir d’Exchange 2010 SP2, les éléments et dossiers sont retournés dans l’ordre du plus récent au plus ancien. Dans les versions précédentes d’Exchange, les éléments et dossiers sont retournés du plus ancien au plus récent.

Comment fonctionne la synchronisation EWS ?

En bref, si vous synchronisez une boîte aux lettres pour la première fois, utilisez le processus comme indiqué dans la figure 1. Bien que vous puissiez utiliser d’autres modèles de conception de synchronisation, nous vous recommandons cette approche pour les applications scalables.

Figure 1. Modèle de conception de synchronisation initiale

Si vous utilisez un état de synchronisation existant sur le client pour synchroniser une boîte aux lettres, nous vous recommandons d’implémenter le modèle de conception comme indiqué dans la Figure 2.

Figure 2. Modèle de conception de synchronisation continue

Modèles de conception de synchronisation

Vous pouvez utiliser l’un des deux modèles de conception de synchronisation dans votre application pour maintenir vos boîtes aux lettres à jour : la synchronisation basée sur les notifications ou l’approche de synchronisation uniquement.

La synchronisation basée sur les notifications, comme illustré dans Figure 2, s’appuie sur les notifications pour avertir le client d’effectuer un appel aux méthodes SyncFolderItems ou SyncFolderHierarchy de l’API managée EWS, ou aux opérations SyncFolderHierarchy ou SyncFolderItems EWS . Ce type de synchronisation est généralement recommandé pour les applications évolutives, mais ce n’est peut-être pas la meilleure approche pour tout le monde. La synchronisation basée sur les notifications présente l’avantage suivant :

Les notifications sont optimisées pour réduire les appels à la base de données Exchange principale. Les files d’attente d’événements et les abonnements sont gérés par le serveur de boîtes aux lettres (ou le serveur d’accès au client dans Exchange 2010 et Exchange 2007) ; toutefois, la gestion des événements et des abonnements utilise moins de ressources que l’alternative, qui est des appels de synchronisation plus fréquents à la base de données Exchange. En outre, Exchange dispose de stratégies de limitationspécifiques pour les notifications et les abonnements, afin de protéger la consommation des ressources.

Toutefois, l’utilisation de la synchronisation basée sur les notifications présente également certains inconvénients :

• Les notifications sont bruyantes, car la plupart des scénarios impliquent plusieurs notifications pour une intention utilisateur. Cela est particulièrement vrai pour le dossier Calendrier. Par exemple, lorsqu’une demande de réunion unique est reçue, plusieurs notifications d’élément et de dossier sont créées, y compris une notification pour créer l’élément et une autre pour modifier l’élément. Une façon d’atténuer cet inconvénient consiste à générer un délai de quelques secondes dans votre Charge,LoadPropertiesForItemsLoadPropertiesForItems, GetItem ou appel GetFolder. Dans le cas d’une demande de réunion, si vous avez effectué immédiatement des appels à l’opération GetItem, vous pourriez avoir un appel pour créer l’élément et un autre pour modifier l’élément. Au lieu de cela, en retardant l’appel, vous pouvez appeler l’opération GetItem une seule fois et obtenir les modifications qui englobent la création et la modification de l’élément en même temps.
• Les notifications sont mises en file d’attente sur le serveur de boîtes aux lettres et les abonnements sont enregistrés sur le serveur de boîtes aux lettres. Si le serveur de boîtes aux lettres qui gère l’abonnement n’est pas disponible, vous perdez toutes les nouvelles notifications, votre boîte aux lettres ne se synchronise pas et vous devrez vous réabonner aux notifications.
• Vous devez planifier des stratégies d’atténuation en cas d’échec des notifications. De cette façon, la deuxième approche, le modèle de conception de synchronisation uniquement, est plus résiliente que la synchronisation basée sur les notifications, car elle nécessite uniquement que le client conserve l’état de synchronisation — il n’existe aucun problème d’affinité avec le serveur de boîtes aux lettres gérant l’abonnement.

S’il est implémenté comme recommandé, le modèle de conception d’abonnement basé sur les notifications s’appuie sur :

• Notifications pour déterminer quand les données ont changé.
• Les méthodes SyncFolderHierarchy ou SyncFolderItems de l’API managée EWS, ou les opérations SyncFolderHierarchy ou SyncFolderItems EWS pour déterminer ce qui a changé, en optimisant le nombre d’événements de synchronisation retournés. Un nouvel élément a-t-il été créé, mis à jour ou supprimé ? C’est tout ce que vous devez savoir à partir de ces méthodes, ne vous fiez pas à celles-ci pour la liste des propriétés des modifications. (N’effectuez pas d’appel GetItem ou LoadPropertiesForItems sur tous les éléments ou dossiers renvoyés).
• Utilisation des méthodes Load ou LoadPropertiesForItems dans l’API managée EWS, ou de l’opération GetItem EWS pour déterminer comment les données ont changé et pour récupérer les propriétés du serveur en fonction des besoins, en organisant les demandes par lots en fonction de la quantité de données qui seront retournées. Cette opération est suivie d’une comparaison des propriétés sur le client et celles qui viennent d’être retournées par le serveur, et enfin de la création, de la suppression ou de la modification de l’élément ou du dossier sur le client.

L’approche de synchronisation uniquement s’appuie entièrement sur les méthodes SyncFolderItems et SyncFolderHierarchy de l’API Managée EWS, ou les opérations SyncFolderHierarchy ou SyncFolderItems EWS, que vous pouvez appeler en continu ou en tant qu’événement chronométré. Cette option présente également des avantages et des inconvénients. L’approche de synchronisation uniquement est plus résiliente, car l’état de synchronisation est stocké sur le client au niveau de la boîte aux lettres et une relation unique entre l’état de synchronisation et tout serveur de boîtes aux lettres qui gère l’abonnement aux notifications n’est pas nécessaire. L’approche de synchronisation peut survivre à un basculement de boîte aux lettres en raison de son indépendance vis-à-vis du serveur de boîtes aux lettres. Toutefois, l’approche de synchronisation augmente la latence pour l’utilisateur, car les éléments sont synchronisés sur une base chronométrée ou intermittente — pas en temps réel lorsque des éléments arrivent. Cette approche est également plus coûteuse, car vous effectuez des appels à la base de données Exchange lorsqu’il est possible qu’aucune modification n’ait eu lieu.

Meilleures pratiques de synchronisation

Pour les applications hautement évolutives, nous vous recommandons d’appliquer les meilleures pratiques suivantes pour synchroniser les boîtes aux lettres dans votre application :

• Lorsque vous appelez la méthode SyncFolderItems ou SyncFolderHierarchy de l’API managée EWS, utilisez la valeur IdOnly pour le paramètre propertySet, ou lorsue vous utilisez les opérations SyncFolderHierarchy ou SyncFolderItems EWS utilisez la valeur IdOnly pour la valeur BaseShape pour réduire les appels à la base de données Exchange. Plus vous demandez de propriétés dans l’ensemble de propriétés de l’appel SyncFolderItems ou SyncFolderHierarchy, plus les appels principaux sont créés. Un nouvel appel RPC est effectué pour chaque valeur de propriété demandée, tandis qu’un seul appel RPC est effectué pour récupérer tous les ItemIds pour une demande, quel que soit le nombre de résultats à signaler. Par conséquent, une demande de IdOnly entraîne un appel de base de données, tandis qu’une demande de conteneur de propriétés pour l’objet et l’expéditeur génère trois appels de base de données : un pour l'Objet, un pour l'Expéditeur et un pour le ItemId.

• N’appelez pas les méthodes Charger ou LoadPropertiesForItems de l’API managée EWS, ni les opérations GetItem ou GetFolder EWS, sur chaque élément d’une réponse de synchronisation. Au lieu de cela, analysez les résultats ; recherchez les modifications qui ne nécessitent pas la récupération de toutes les propriétés, telles que les modifications d’état de lecture. Si une réponse inclut un changement d’état de lecture, mettez simplement à jour l’indicateur sur le client et vous avez terminé . inutile d’obtenir toutes les propriétés de l’élément. Assurez-vous de ne pas dupliquer les efforts en apportant des modifications provenant du même client. Par exemple, si la réponse de synchronisation inclut la suppression d’un élément et que la suppression s’est produite sur le client local, vous n’avez pas besoin de supprimer à nouveau le message ou d’obtenir toutes les propriétés de cet élément.

• Évitez d’être limité en procédant comme suit :

  • Lorsque vous appelez la méthode LoadPropertiesForItemsde l’API managée EWS ou l’opération GetItem EWS pour obtenir les éléments dans un lot, ne traitez pas trop d’éléments dans votre demande. sinon, vous risquez d’être limité. Nous vous recommandons d’inclure 10 éléments par lot.
  • N’effectuez pas trop de demandes dans un délai trop court. Cela entraîne également une limitation et augmente le temps de réponse, au lieu de le raccourcir.
  • Si vous traitez des éléments par lot, traitez tous les éléments avec les mêmes valeurs pour les attributs IDet ChangeKey de l’élément FolderId.
  • Si vous êtes limité, arrêtez l’envoi de demandes. Le fait de renvoyer des demandes prolongera l’effort de récupération. Au lieu de cela, attendez l’expiration du temps de congé, puis réessayez d’envoyer vos demandes de synchronisation.

• Selon le type d’événement de notification reçu :

  • Pour les événements NewMail ou Modifiés, appelez la méthodeSyncFolderItems de l’API managée ou l’opération SyncFolderItems EWS, car les notifications ne fournissent pas de ChangeKey, et les notifications n’appellent pas de modifications d’état de lecture.
  • Pour les événements supprimés, si l’abonnement aux notifications était actif avant la synchronisation précédente, supprimez simplement l’événement localement. Vous n’avez pas besoin d’appeler la méthode SyncFolderItems de l’API managée ou l’opérationSyncFolderItems EWS immédiatement après la suppression.
  • Si un événement Modifié a été provoqué par une modification d’état de lecture, n’appelez pas l méthode LoadPropertiesForItems de l’API managée ni l’opération GetItem EWS, modifiez simplement l’indicateur sur l’élément.

• Lors de la synchronisation des données de calendrier, procédez comme suit :

  • Utilisez une approche similaire à la synchronisation basée sur les notifications. Étant donné que SyncFolderItem n’inclut aucune logique de calendrier, utilisez la méthode FindAppointments de l’API managée EWS ou l’opération FindItem EWS avec l’élément CalendarView pour afficher les rendez-vous entre deux dates, puis appelez la méthode LoadPropertiesForItems de l’API managée EWS ou l’opération GetItem EWS pour récupérer les propriétés de l’élément de calendrier.

  • Ne faites pas de sondage à l’aide de la méthode FindAppointments de l’API managée EWS, ni de l’opération FindItem EWS avec un élément CalendarView.

• Lors de la synchronisation des dossiers de recherche :

  • Utilisez une approche similaire à la synchronisation basée sur les notifications.

  • Utilisez des notifications pour déterminer quand les données changent.

  • Étant donné que vous ne pouvez pas utiliser SyncFolderItem dans un dossier de recherche, utilisez une méthode FindItems de l’API managée EWS triée et paginée, ou une opération FindItem EWS avec l'élément FractionalPageItemView et SortOrderdéfini, pour déterminer ce qui a changé.

  • Utilisez la méthode LoadPropertiesForItems de l’API managée EWS ou l’opération GetItem EWS pour récupérer des données.

Synchronisation filtrée

La méthode SyncFolderItems de l’API managée EWS et l’opération SyncFolderItems EWS vous permettent d’ignorer des éléments spécifiques, en fonction de leurs ItemIds, en définissant le paramètre IgnoreItemIds dans l’API managée EWS ou l’élément Ignorer dans EWS. C’est idéal lorsque, par exemple, des personnes commencent à répondre à un e-mail envoyé à tous les membres de l’entreprise.

Vous vous demandez peut-être, puis-je filtrer mes notifications (et donc déclencher uniquement la synchronisation) si des propriétés spécifiques changent ? Bien que cela semble raisonnable, étant donné que les abonnements aux notifications sont basés sur le type de modification (créer, mettre à jour, supprimer) et non sur la propriété en cours de mise à jour, vous ne pouvez pas filtrer les notifications de cette façon. Vous pouvez plutôt procéder comme suit :

• Utilisez le modèle de conception d’abonnement basé sur les notifications.
• Appelez les méthodes SyncFolderItems et SyncFolderHierarchy de l’API managée EWS à plusieurs reprises avec le paramètre propertySet défini sur IdOnly pour que votre état de synchronisation soit actif. Si vous utilisez EWS, appelez les opérations SyncFolderHierarchy et SyncFolderItems à plusieurs reprises avec la valeur BaseShape définie sur IdOnly.
• Ignorez la réponse (ne l’analysez pas ou n’effectuez aucune comparaison de propriétés).
• Utilisez la méthode FindItems de l’API managée EWS ou l’opération FindItem pour trier et paginer afin de préremplir les éléments dans l’étendue filtrée qui vous intéresse.
• Utilisez votre état de synchronisation pour continuer à appeler la méthode SyncFolderItems de l’API managée EWS ou l’opération SyncFolderItems EWS, mais surveillez uniquement les modifications apportées à l’élément filtré défini.. Si de nouveaux éléments sont créés, vous devez voir si ces nouveaux éléments se trouvent dans votre étendue filtrée.

Dans cette section

• Synchroniser des dossiers à l’aide d’EWS dans Exchange
• Synchroniser des éléments à l’aide d’EWS dans Exchange
• Gestion des erreurs liées à la synchronisation dans EWS dans Exchange

Voir aussi

• Développer des clients de service web pour Exchange
• Méthode SyncFolderItems
• Méthode SyncFolderHierarchy
• Opération SyncFolderHierarchy
• Opération SyncFolderItems