Abonnements à des notifications, événements de boîte aux lettres et EWS dans Exchange
Découvrez les abonnements à des notifications et les événements de boîte aux lettres dans les services EWS dans Exchange.
Vous pouvez utiliser l'API managée des services EWS et les services web Exchange (EWS) pour vous abonner et recevoir des notifications lorsque des événements se produisent dans une boîte aux lettres, ou dans un ou plusieurs des dossiers d'une boîte aux lettres. Trois types d'abonnements sont disponibles : notifications de diffusion en continu, notifications de type pull et notifications Push. Chacun de ces types d'abonnements utilise différentes techniques pour recevoir ou récupérer les notifications.
Obtenir des notifications - quelles sont les options dont je dispose ?
EWS inclut trois types d'abonnements qui fonctionnent indépendamment pour informer le client de modifications sur le serveur. Quel que soit le type d'abonnement choisi, en fin de compte, vous aurez accès aux mêmes événements de notification - tout dépend de comment vous les obtenez.
Tableau 1. Types d’abonnements
| Option | Description | Me convient-il ? |
|---|---|---|
| Notifications de diffusion en continu |
Notifications envoyées par le serveur via une connexion qui reste ouverte pendant une période de temps spécifiée. |
Les notifications de diffusion en continu sont généralement recommandées pour la plupart des applications. Elles sont semblables aux notifications Push et offrent le meilleur des deux mondes. Une fois que vous avez établi votre abonnement aux notifications, la connexion reste ouverte pendant 30 minutes pour permettre au serveur de renvoyer les notifications au client. Vous n 'avez pas à demander de mises à jour, comme vous le feriez avec un abonnement par extraction, et vous n'avez pas à créer d'application d'écouteur de service web, comme vous le feriez avec un abonnement Push. |
| Notifications de type pull |
Notifications qui sont demandées (ou extraites) par le client. |
Les notifications de type pull sont généralement plus appropriées pour les clients à faible couplage, lorsque le client n'est pas connecté au réseau de manière fiable. Les notifications de type pull peuvent créer un trafic excessif entre le client et le serveur car le client envoie des demandes fréquentes au serveur pour récupérer des notifications, et toutes les demandes n'entraînent pas des notifications récupérées. |
| Notifications push |
Notifications envoyées (ou poussées) par le serveur vers un service web côté client via une adresse de rappel. |
En règle générale, les notifications Push fournissent une latence de notification plus faible que les notifications pull et sont adaptées aux clients à couplage étroit auxquels le serveur dispose d'un accès fiable, et il est possible d'accéder au client par le biais d'une adresse IP. Toutefois, les notifications Push ont été laissées de côté depuis l'arrivée des notifications de diffusion en continu dans Exchange 2010. Si possible, nous vous recommandons d'utiliser des notifications de diffusion en continu à la place des notifications Push par la suite. Les notifications Push exigent que vous écriviez une application d'écouteur vers laquelle les notifications sont envoyées. Cela a un léger avantage sur les notifications pull dans la mesure où cela permet de réduire le trafic réseau, mais cela ajoute de la surcharge car une application distincte est requise. |
À quels événements EWS puis-je m’abonner ?
Les types d'événements EWS auxquels les clients peuvent s'abonner sont définis par l'énumération EventType pour l'API managée EWS ou l'élément EventType pour EWS. Les événements EWS suivants sont disponibles pour l'abonnement :
NewMail : un nouveau message est arrivé dans la boîte de réception.
Deleted : un message a été supprimé définitivement de la boîte de réception. Pour en savoir plus sur les notifications des éléments supprimés, voir Suppression d'éléments à l'aide de EWS dans Exchange et Extraction des notifications pour les événements liés à la suppression des boîtes aux lettres EWS dans Exchange.
Modified : un élément ou un dossier a été modifié.
Moved : un élément ou un dossier a été déplacé.
Copied : un élément ou un dossier a été copié.
Created : Un élément ou un dossier a été créé.
FreeBusyChanged : les informations de disponibilité d'un utilisateur a été modifiées.
Un autre type d'événement EWS, l'événement Status, est défini par l'élément EventType, mais vous ne vous abonnez pas à cet événement. Au lieu de cela, il est envoyé par le serveur pour vérifier l'état du client pour les notifications Push et de diffusion en continu uniquement. Le client doit répondre à cet événement ou le client expirera.
Une seule action de l'utilisateur entraîne souvent la création de plusieurs notifications. Pour illustrer cela, la figure suivante illustre quelques scénarios courants et les notifications créées pour chacun d'eux. Les paramètres du client ont un impact sur les notifications reçues, donc il ne s'agit pas d'une liste exhaustive de toutes les options de configuration et des notifications qui en résultent.
Figure 1. Types d’événements renvoyés par les abonnements à des notifications
La Figure 1 simplifie le processus de notification. En réalité, plusieurs notifications (même plusieurs notifications du même type) peuvent être créées pour une seule action de l'utilisateur. Par exemple, dans le cas d'une opération de déplacement de dossier, trois événements de dossier sont créés : un pour le dossier en cours de modification, un pour l'ancien dossier parent et un pour le nouveau dossier parent. Étant donné qu'un grand nombre d'événements peut être déclenché pour une seule opération, nous vous recommandons de générer un délai d'attente de quelques secondes dans vos opérations de synchronisation, afin d'effectuer la synchronisation uniquement lorsque l'action est terminée, plutôt qu'en cours d'opération.
Il est également important de savoir que les paramètres de configuration choisis par chaque utilisateur affectent les notifications qui sont créées. Par exemple, les données de disponibilité de certains utilisateurs sont mises à jour automatiquement et l'événement FreeBusyChanged est créé à la réception d'une nouvelle demande de réunion, même avant d'avoir lu l'élément. Pour d'autres utilisateurs, les données de disponibilité ne sont pas mises à jour et l'événement FreeBusyChanged n'est pas créé tant que la réunion n'a pas été acceptée. Ces paramètres peuvent avoir un impact considérable sur les notifications créées par le serveur.
Comment fonctionnent les notifications EWS ?
Les notifications EWS sont gérées par abonnement. En règle générale il existe un abonnement par boîte aux lettres et, dans l'abonnement à la boîte aux lettres, vous pouvez vous abonner à une partie ou à l'intégralité des dossiers. Vous choisissez le type de notification auquel vous souhaitez vous abonner (diffusion en continu, pull ou Push) et le type d'événement que vous souhaitez recevoir (NewMail, Created, Deleted, Modified, etc.) puis vous créez un abonnement. Les événements EWS sont ensuite envoyés de manière asynchrone du serveur de boîte aux lettres au client. (Leçon d'histoire : les événements sont synchrones dans Exchange 2007, et les événements sont stockés sur le serveur d'accès au client dans Exchange 2010, mais pas plus !).
La manière dont les notifications sont envoyées au client varie selon le type d'abonnement. Cette section décrit le fonctionnement de chaque type d’abonnement de façon plus détaillée.
Notifications de diffusion en continu EWS
Les notifications de diffusion en continu reposent sur une demande GET en attente sur le serveur pour maintenir une connexion d'abonnement de diffusion en continu ouverte, afin que tous les événements qui se produisent lorsque la connexion est active soient diffusés en continu au client immédiatement. Plusieurs notifications peuvent être envoyées au cours d'une seule connexion et la connexion reste ouverte jusqu'à l'expiration de l'intervalle, ou pendant une période maximale de 30 minutes. Après expiration de la connexion, le client renvoie la demande GET en attente. La Figure 2 illustre le fonctionnement des abonnements de diffusion en continu et des notifications de diffusion en continu.
Figure 2. Vue d’ensemble des notifications de diffusion en continu
Pour plus d'informations sur la création de notifications de diffusion en continu, voir Notifications de flux concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange.
Notifications de type pull EWS
Les notifications de type pull reposent sur le client qui fait la demande de notifications sur un intervalle qu'il gère. Cela peut entraîner des réponses GetEvents sans notifications. La Figure 3 illustre le fonctionnement des abonnements et des notifications de type pull.
Figure 3. Vue d’ensemble des notifications de type pull
Pour plus d'informations sur la création des notifications de type pull, voir Notifications de type pull concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange.
Notifications Push EWS
Les notifications Push reposent sur le serveur qui renvoie les notifications au client. Le trafic existe uniquement s'il existe une notification. La Figure 4 illustre le fonctionnement des abonnements et des notifications Push.
Figure 4. Vue d’ensemble des notifications Push
Si vous utilisez des notifications Push avec Exchange 2010, envisagez de mettre votre application à niveau pour utiliser des notifications de diffusion en continu. Ainsi, vous n'avez pas besoin d'une application distincte pour recevoir les événements.
Comment s’abonner à des notifications ?
Selon le type d'abonnement que vous souhaitez créer, vous disposez de plusieurs options pour vous abonner à des notifications.
Tableau 2. Opérations et méthodes permettant de s’abonner à des notifications
Comment obtenir des événements EWS ?
Une fois que l’abonnement est créé, la façon dont les événements réels sont envoyés au client dépend du type d’abonnement.
Pour les notifications de diffusion en continu, une connexion d’abonnement de diffusion en continu doit être créée puis l’abonnement est ajouté à la connexion. Vous pouvez en savoir plus sur ce processus dans Notifications de flux concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange.
Pour les notifications de type pull, l’objet de l’abonnement a été initialisé lors de la création de l’abonnement. Par conséquent, il vous suffit d’appeler l’opération ou la méthode GetEvent pour récupérer les événements à partir du serveur. Vous pouvez en savoir plus sur ce processus dans Notifications de type pull concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange.
Le tableau suivant répertorie les opérations et les classes nécessaires pour récupérer des événements.
Tableau 3. Éléments et classes pour créer une connexion et obtenir des événements
| Type d'abonnement | Opération EWS | Méthode d'API managée EWS | Fonction |
|---|---|---|---|
| Diffusion en continu |
Opération de GetStreamingEvents |
Méthode StreamingSubscriptionConnection.AddSubscription |
Crée une demande GET en attente sur le serveur, à laquelle une réponse est donnée lorsque des événements se produisent. |
| Pull |
Opération de GetEvents |
Méthode PullSubscription.GetEvents |
Obtient des événements de notification de type pull à partir du serveur. |
| Push |
Non applicable. |
Non applicable. |
Les notifications Push sont envoyées automatiquement à l'écouteur de service web (l'URL de rappel spécifiée dans la demande d'abonnement). Aucune opération ni méthode supplémentaire ne doit être appelée. |
Comment résilier des abonnements à des notifications ?
Le tableau suivant répertorie les différentes façons de résilier chaque type d’abonnement.
Tableau 4. Opérations et méthodes de résiliation d’abonnement aux notifications
| Type d'abonnement | EWS | API managée EWS |
|---|---|---|
| Diffusion en continu |
Opération de résiliation d'abonnement |
Méthode StreamingSubscription.BeginUnsubscribe Méthode StreamingSubscription.EndUnsubscribe Méthode StreamingSubscription.Unsubscribe |
| Pull |
Opération de résiliation d'abonnement |
Méthode PullSubscription.BeginUnsubscribe Méthode PullSubscription.EndUnsubscribe Méthode PullSubscription.Unsubscribe |
| Push |
Renvoie Unsubscribe dans l'élément StatusFrequency de SendNotificationResponseMessage |
Non applicable. Laissez plutôt expirer l'abonnement. |
Autrement, vous pouvez laisser expirer chacun des abonnements.
Tableau 5. Délais d’expiration de l’abonnement
| Type d'abonnement | Valeur du délai d'expiration dans EWS | Valeur du délai d'expiration dans l'API managée EWS | Gestion des délais d'expiration |
|---|---|---|---|
| Diffusion en continu |
Élément ConnectionTimeout |
paramètre lifetime du constructeur StreamingSubscriptionConnection |
Pour l'API managée EWS, une fois le délai d'expiration passé, l'événement OnDisconnect se produit. Si la méthode StreamingSubscriptionConnection.Open n'est pas appelée, la connexion est fermée. Pour EWS, une fois le délai expiration écoulé, le message GetUserConfigurationResponse renvoie une valeur ConnectionStatus Closed. |
| Pull |
Élément Timeout |
paramètre timeout de la méthode SubscribeToPullNotification |
Une fois que le délai d’expiration s’est écoulé, le serveur supprime l’abonnement. |
| Push |
Élément StatusFrequency |
paramètre frequency de la méthode SubscribeToPushNotification |
Si le serveur ne reçoit pas de réponse à une notification Push ou à un statut ping, il réessaie d'envoyer la notification plusieurs fois avant de cesser d'envoyer les notifications. Pour plus d'informations, voir StatusFrequency. |
Est-il possible de limiter les abonnements ?
Dans un déploiement local, vous pouvez limiter le nombre d'abonnements par utilisateur avec le paramètre de limitation EwsMaxSubscriptions de la stratégie de limitation. Cette stratégie peut être appliquée à tous les utilisateurs ou à des utilisateur spécifiques uniquement. La stratégie de limitation EwsMaxSubscriptions n'est pas configurable pour Exchange Online.
Dans cette section
- Notifications de flux concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange
- Notifications de type pull concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange
- Conserver l’affinité entre un groupe d'abonnements et le serveur de boîtes aux lettres dans Exchange
- Gestion des erreurs liées à la notification dans EWS dans Exchange
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour