Informationen über den Replikationszustandsautomaten
Gilt für: Outlook 2013 | Outlook 2016
Dieses Thema enthält eine Übersicht über den Zustandscomputer für Microsoft Outlook 2013 und Microsoft Outlook 2010 Datenreplikation.
Hinweis
Die Replikations-API muss gemäß den Anweisungen in diesem Thema vollständig implementiert werden, um nützlich oder unterstützt zu werden. Die Replikations-API steht ausschließlich zum Replizieren von Outlook 2013- oder Outlook 2010-Änderungen auf und von einem Server zur Verfügung.
IOSTX und der Zustandsautomat
Ein Client ruft IOSTX::SyncBeg, IOSTX::SyncEnd, IOSTX::SyncHdrBeg und IOSTX::SyncHdrEnd in einer Sequenz auf, um Outlook 2013- oder Outlook 2010-Ordner und -Elemente zwischen einem lokalen Speicher und einem Server zu synchronisieren. Die tatsächliche Reihenfolge der Aufrufe hängt von den Daten ab, die repliziert werden müssen (z. B. einer Hierarchie von Outlook 2013- oder Outlook 2010-Ordnern, einem Outlook 2013- oder Outlook 2010-Ordner, E-Mail-Elementen, Kalenderelementen usw.) und der Synchronisierungsrichtung (ob das Hochladen aus dem lokalen Speicher auf den Server oder das Herunterladen vom Server in den lokalen Speicher). Hier sehen Sie eine typische Sequenz von Aufrufen:
Der Client ruft IOSTX::SyncBeg auf, um mit der Replikation zu beginnen, indem er einen Zustandsbezeichner und einen Zeiger auf eine Adresse einer entsprechenden Datenstruktur angibt.
Outlook 2013 oder Outlook 2010 ordnet die Datenstruktur zu und initialisiert die Datenstruktur mit den erforderlichen Informationen für den Client.
Der Client führt die Replikation durch und aktualisiert die Datenstruktur, um alle erforderlichen Informationen zur Replikation an den lokalen Speicher zu übermitteln.
Nach der Durchführung der Replikation ruft der Client IOSTX::SetSyncResult und IOSTX::SyncEnd auf, um den lokalen Speicher über den Abschluss der spezifischen Replikation zu benachrichtigen.
Hinweis
Der Client ruft immer IOSTX::SyncEnd auf, um eine Replikation zu beenden, die der Client für einen bestimmten Zustand begonnen hat. Abhängig von den Gesamtdaten, die der Client synchronisieren muss, kann der Client das Paar der Aufrufe IOSTX::SyncBeg und IOSTX::SyncEnd mehrmals aufrufen.
Zustandstabelle
Hinweis
In der folgenden Tabelle sind alle gültigen Zustände auf dem Replikationszustandscomputer zusammen mit den entsprechenden Zustandsbezeichnern und Datenstrukturen aufgeführt. In der Spalte Datenrepliziert umfasst der Begriff "Elemente" E-Mail-, Kalender-, Kontakt-, Notiz-, Journal- und Aufgabenelemente. Verwenden Sie beim Replizieren von Änderungen vom lokalen Speicher auf den Server Zustandsbezeichner, die "UPLOAD" und Datenstrukturen mit dem Präfix "UP" angeben (z. B. LR_SYNC_UPLOAD_HIERARCHY und UPHIER ). Verwenden Sie beim Replizieren von Änderungen vom Server in den lokalen Speicher Zustandsbezeichner, die "DOWNLOAD" und Datenstrukturen mit dem Präfix "DN" angeben (z. B. LR_SYNC_DOWNLOAD_HIERARCHY und DNHIER ).
|
Status |
Replizierte Daten |
Zustandsbezeichner |
Datenstruktur |
|---|---|---|---|
|
Zustand „Leerlauf“ |
Keine |
LR_SYNC_IDLE |
Keine |
|
Zustand „Synchronisieren“ |
Ordner oder Elemente |
LR_SYNC |
SYNC |
|
Uploadhierarchiestatus |
Ordner |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
|
Ordnerstatus hochladen |
Ordner |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
|
Inhaltsstatus synchronisieren |
Elemente |
LR_SYNC_CONTENTS |
SYNCCONT |
|
Tabellenzustand hochladen |
Elemente |
LR_SYNC_UPLOAD_TABLE |
UPTBL |
|
Nachrichtenstatus hochladen |
Element |
LR_SYNC_UPLOAD_MESSAGE |
UPMSG |
|
Lese-status-Zustand hochladen |
Elemente |
LR_SYNC_UPLOAD_MESSAGE_READ |
UPREAD |
|
Upload delete status state |
Elemente |
LR_SYNC_UPLOAD_MESSAGE_DEL |
UPDEL |
|
Hierarchiestatus herunterladen |
Ordner |
LR_SYNC_DOWNLOAD_HIERARCHY |
DNHIER |
|
Tabellenstatus herunterladen |
Elemente |
LR_SYNC_DOWNLOAD_TABLE |
DNTBL |
|
Status des Nachrichtenheaders herunterladen |
Nachrichtenkopf |
LR_SYNC_DOWNLOAD_HEADER |
HDRSYNC |
Beispiel: Hochladen einer Ordnerhierarchie
Beim Hochladen einer Ordnerhierarchie erfolgt die folgende Abfolge von Schritten:
|
Schritt |
Aktion |
Status |
Zugehörige Datenstruktur |
|---|---|---|---|
| 1. | Der Client initiiert den Hierarchieupload mit IOSTX::SyncBeg. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 2. | Outlook 2013 oder Outlook 2010 füllt UPHIER mit Informationen für den Client auf. Dies schließt das Initialisieren der [out]-Parameter ein: iEnt ist auf 0 und cEnt auf die Anzahl der Ordner in der Hierarchie festgelegt, die hochgeladen werden müssen. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 3. | Der Client führt den eigentlichen Hierarchieupload durch. Wenn cEnt beispielsweise 10 ist, ruft der Client für jeden der 10 Ordner IOSTX::SyncBeg auf und gibt den entsprechenden Zustandsbezeichner und die Datenstruktur für das Hochladen eines Ordners an. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 4. | Outlook 2013 oder Outlook 2010 füllt UPFLD auf, indem die Parameter [out] initialisiert werden, einschließlich des Grunds für den Ordnerupload, des Zeigers auf das Ordnerobjekt und der Eintrags-ID für den Ordner. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 5. | Der Client lädt den angegebenen Ordner hoch. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 6. | Der Client benachrichtigt den lokalen Speicher über den Abschluss des Ordneruploads: Bei Erfolg legt der Client den [in]-Parameter ulFlags in UPFLD mit UPF_OK fest und ruft dann IOSTX::SetSyncResult (S_OK) und IOSTX::SyncEnd auf. Bei einem Fehler würde der Client ulFlags nicht mit dem UPF_OK-Flag festlegen. Es ruft IOSTX::SetSyncResult auf und übergibt den HRESULT-Wert und IOSTX::SyncEnd. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 7. | Wenn UPF_OK festgelegt ist, löscht Outlook 2013 oder Outlook 2010 die interne Anforderung zum Hochladen des Ordners. Unabhängig vom Zustand von ulFlags werden dann alle internen Buchhaltungsinformationen sauber. Obwohl in der Hierarchie noch Ordner zum Hochladen vorhanden sind (iEnt ist immer noch kleiner als cEnt), wiederholen der Client und Outlook 2013 oder Outlook 2010 die Schritte 3 bis 7. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 8. | Der Client benachrichtigt den lokalen Speicher über den Abschluss des Hierarchieuploads: Bei Erfolg legt der Client das Flag "[in]" in UPHIER mit UPH_OK fest und ruft dann IOSTX::SetSyncResult (S_OK) und IOSTX::SyncEnd auf. Bei einem Fehler würde der Client das UPH_OK-Flag nicht festlegen. Es ruft IOSTX::SetSyncResult auf und übergibt den HRESULT-Wert und IOSTX::SyncEnd. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 9. | Wenn UPH_OK festgelegt ist, löscht Outlook 2013 oder Outlook 2010 die interne Anforderung zum Hochladen der Hierarchie. Unabhängig vom Zustand von ulFlags werden dann alle internen Buchhaltungsinformationen sauber. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
Siehe auch
Informationen über die Replikations-API
MAPI-Konstanten
SYNCSTATE