À propos de la machine à états de réplication
S’applique à : Outlook 2013 | Outlook 2016
Cette rubrique contient une vue d’ensemble de la machine à états pour la réplication de données Microsoft Outlook 2013 et Microsoft Outlook 2010.
Remarque
L’API de réplication doit être entièrement implémentée conformément aux instructions de cette rubrique afin d’être utile ou prise en charge. L’API de réplication est disponible exclusivement pour répliquer les modifications apportées à Outlook 2013 ou Outlook 2010 vers et à partir d’un serveur.
IOSTX et la machine à états
Un client appelle IOSTX ::SyncBeg, IOSTX ::SyncEnd, IOSTX ::SyncHdrBeg et IOSTX ::SyncHdrEnd dans une séquence pour synchroniser les dossiers et les éléments Outlook 2013 ou Outlook 2010 entre un magasin local et un serveur. La séquence réelle d’appels dépend des données qui doivent être répliquées (par exemple, une hiérarchie de dossiers Outlook 2013 ou Outlook 2010, un dossier Outlook 2013 ou Outlook 2010, des éléments de courrier, des éléments de calendrier, etc.) et du sens de la synchronisation (qu’il s’agisse du chargement à partir du magasin local vers le serveur ou du téléchargement du serveur vers le magasin local). Voici une séquence classique d’appels :
Le client appelle IOSTX ::SyncBeg pour commencer la réplication, en spécifiant un identificateur d’état et un pointeur vers l’adresse d’une structure de données correspondante.
Outlook 2013 ou Outlook 2010 alloue la structure de données et initialise la structure de données avec les informations nécessaires pour le client.
Le client effectue la réplication, en mettant à jour la structure de données pour transmettre au magasin local toutes les informations nécessaires sur la réplication.
Après avoir effectué la réplication, le client appelle IOSTX ::SetSyncResult et IOSTX ::SyncEnd pour informer le magasin local de la fin de la réplication spécifique.
Remarque
Le client appelle toujours IOSTX ::SyncEnd pour mettre fin à une réplication que le client a commencée pour un certain état. En fonction des données globales que le client doit synchroniser, il peut appeler plusieurs fois la paire d’appels IOSTX ::SyncBeg et IOSTX ::SyncEnd .
Table d’état
Remarque
Le tableau suivant répertorie tous les états valides dans la machine à état de réplication, ainsi que les identificateurs d’état et les structures de données correspondants. Dans la colonne Données répliquées , le terme « éléments » inclut les éléments courrier, calendrier, contact, note, journal et tâche. Lors de la réplication des modifications du magasin local vers le serveur, utilisez des identificateurs d’état spécifiant « UPLOAD » et des structures de données avec le préfixe « UP » (par exemple, LR_SYNC_UPLOAD_HIERARCHY et UPHIER ). Lors de la réplication des modifications du serveur vers le magasin local, utilisez des identificateurs d’état spécifiant « DOWNLOAD » et des structures de données avec le préfixe « DN » (par exemple, LR_SYNC_DOWNLOAD_HIERARCHY et DNHIER ).
|
État |
Données répliquées |
Identificateur d’état |
Structure de données |
|---|---|---|---|
|
État inactif |
Aucune |
LR_SYNC_IDLE |
Aucune |
|
Synchronisation de l’état |
Dossiers ou éléments |
LR_SYNC |
SYNCHRONISATION |
|
Charger l’état de la hiérarchie |
Folders |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
|
État du dossier de chargement |
Folder |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
|
Synchroniser l’état du contenu |
Éléments |
LR_SYNC_CONTENTS |
SYNCCONT |
|
État de chargement de la table |
Éléments |
LR_SYNC_UPLOAD_TABLE |
UPTBL |
|
Charger l’état du message |
Élément |
LR_SYNC_UPLOAD_MESSAGE |
UPMSG |
|
Charger l’état de status de lecture |
Éléments |
LR_SYNC_UPLOAD_MESSAGE_READ |
UPREAD |
|
Charger l’état status supprimer |
Éléments |
LR_SYNC_UPLOAD_MESSAGE_DEL |
UPDEL |
|
Télécharger l’état de la hiérarchie |
Folders |
LR_SYNC_DOWNLOAD_HIERARCHY |
DNHIER |
|
État du téléchargement de la table |
Éléments |
LR_SYNC_DOWNLOAD_TABLE |
DNTBL |
|
Télécharger l’état de l’en-tête de message |
En-tête de message |
LR_SYNC_DOWNLOAD_HEADER |
HDRSYNC |
Exemple : chargement d’une hiérarchie de dossiers
Lors du chargement d’une hiérarchie de dossiers, la séquence d’étapes suivante a lieu :
|
Étape |
Action |
État |
Structure de données associée |
|---|---|---|---|
| 1. | Le client lance le chargement de hiérarchie avec IOSTX ::SyncBeg. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 2. | Outlook 2013 ou Outlook 2010 remplit UPHIER avec des informations pour le client. Cela inclut l’initialisation des paramètres [out] : iEnt est défini sur 0 et cEnt sur le nombre de dossiers dans la hiérarchie qui doivent être chargés. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 3. | Le client effectue le chargement de la hiérarchie réelle. Par exemple, si cEnt a la valeur 10, pour chacun des 10 dossiers, le client appelle IOSTX ::SyncBeg, en spécifiant l’identificateur d’état et la structure de données appropriés pour charger un dossier. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 4. | Outlook 2013 ou Outlook 2010 remplit UPFLD en initialisant ses paramètres [out], y compris la raison du chargement du dossier, le pointeur vers l’objet dossier et l’ID d’entrée du dossier. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 5. | Le client charge le dossier spécifié. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 6. | Le client informe le magasin local de la fin du chargement du dossier : en cas de réussite, le client définit le paramètre [in] ulFlags dans UPFLD avec UPF_OK, puis appelle IOSTX ::SetSyncResult (S_OK) et IOSTX ::SyncEnd. En cas d’échec, le client ne définit pas ulFlags avec l’indicateur UPF_OK . Il appelle IOSTX ::SetSyncResult, en passant la valeur HRESULT et IOSTX ::SyncEnd. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 7. | Si UPF_OK est défini, Outlook 2013 ou Outlook 2010 efface la demande interne de chargement du dossier. Ensuite, quel que soit l’état des ulFlags, il propre toutes les informations de comptabilité internes. Bien qu’il existe encore des dossiers dans la hiérarchie à charger (iEnt est toujours inférieur à cEnt), le client et Outlook 2013 ou Outlook 2010 répètent les étapes 3 à 7. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 8. | Le client informe le magasin local de la fin du chargement de la hiérarchie : en cas de réussite, le client définit l’indicateur [in] dans UPHIER avec UPH_OK, puis appelle IOSTX ::SetSyncResult (S_OK) et IOSTX ::SyncEnd. En cas d’échec, le client ne définit pas l’indicateur UPH_OK . Il appelle IOSTX ::SetSyncResult, en passant la valeur HRESULT et IOSTX ::SyncEnd. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 9. | Si UPH_OK est défini, Outlook 2013 ou Outlook 2010 efface la demande interne de chargement de la hiérarchie. Ensuite, quel que soit l’état des ulFlags, il propre toutes les informations de comptabilité internes. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |