Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a: Outlook 2013 | Outlook 2016
Este tópico contém uma visão geral da máquina de estado para replicação de dados do Microsoft Outlook 2013 e do Microsoft Outlook 2010.
Observação
A API de Replicação deve ser totalmente implementada de acordo com as instruções neste tópico para ser útil ou ter suporte. A API de Replicação está disponível exclusivamente para replicar alterações do Outlook 2013 ou do Outlook 2010 de e para um servidor.
IOSTX e a máquina de estado
Um cliente chama IOSTX::SyncBeg, IOSTX::SyncEnd, IOSTX::SyncHdrBeg e IOSTX::SyncHdrEnd em uma sequência para sincronizar as pastas e os itens do Outlook 2013 ou do Outlook 2010 entre um repositório local e um servidor. A sequência real de chamadas depende dos dados que precisam ser replicados (por exemplo, uma hierarquia de pastas do Outlook 2013 ou do Outlook 2010, uma pasta do Outlook 2013 ou do Outlook 2010, itens de email, itens de calendário e assim por diante) e a direção da sincronização (seja carregando do repositório local para o servidor ou baixando do servidor para o repositório local). Aqui está uma sequência típica de chamadas:
O cliente chama IOSTX::SyncBeg para iniciar a replicação, especificando um identificador de estado e um ponteiro para um endereço de uma estrutura de dados correspondente.
O Outlook 2013 ou Outlook 2010 aloca a estrutura de dados e inicializa a estrutura de dados com as informações necessárias para o cliente.
O cliente executa a replicação, atualizando a estrutura de dados para transmitir ao repositório local as informações necessárias sobre a replicação.
Depois de executar a replicação, o cliente chama IOSTX::SetSyncResult e IOSTX::SyncEnd para notificar o repositório local sobre a conclusão da replicação específica.
Observação
O cliente sempre chama IOSTX::SyncEnd para encerrar uma replicação que o cliente iniciou para um determinado estado. Dependendo dos dados gerais que o cliente precisa sincronizar, o cliente pode chamar o par de chamadas IOSTX::SyncBeg e IOSTX::SyncEnd mais de uma vez.
Tabela de Estado
Observação
A tabela a seguir lista todos os estados válidos na máquina de estado de replicação, juntamente com os identificadores de estado e estruturas de dados correspondentes. Na coluna Dados Replicados , o termo "itens" inclui email, calendário, contato, anotação, diário e itens de tarefa. Ao replicar alterações do repositório local para o servidor, use identificadores de estado que especificam "UPLOAD" e estruturas de dados com o prefixo "UP" (por exemplo, LR_SYNC_UPLOAD_HIERARCHY e UPHIER ). Ao replicar alterações do servidor para o repositório local, use identificadores de estado que especificam "DOWNLOAD" e estruturas de dados com o prefixo "DN" (por exemplo, LR_SYNC_DOWNLOAD_HIERARCHY e DNHIER ).
|
Estado |
Dados replicados |
Identificador de Estado |
Estrutura de dados |
|---|---|---|---|
|
Estado Ocioso |
Nenhum |
LR_SYNC_IDLE |
Nenhum |
|
Estado Sincronizar |
Pastas ou itens |
LR_SYNC |
SINCRONIZAÇÃO |
|
Estado da hierarquia de upload |
Folders |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
|
Carregar estado da pasta |
Pasta |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
|
Sincronizar o estado do conteúdo |
Itens |
LR_SYNC_CONTENTS |
SYNCCONT |
|
Carregar estado da tabela |
Itens |
LR_SYNC_UPLOAD_TABLE |
UPTBL |
|
Carregar estado da mensagem |
Item |
LR_SYNC_UPLOAD_MESSAGE |
UPMSG |
|
Carregar estado de status de leitura |
Itens |
LR_SYNC_UPLOAD_MESSAGE_READ |
UPREAD |
|
Carregar excluir estado de status |
Itens |
LR_SYNC_UPLOAD_MESSAGE_DEL |
UPDEL |
|
Baixar estado da hierarquia |
Folders |
LR_SYNC_DOWNLOAD_HIERARCHY |
DNHIER |
|
Baixar estado da tabela |
Itens |
LR_SYNC_DOWNLOAD_TABLE |
DNTBL |
|
Baixar o estado do cabeçalho da mensagem |
Cabeçalho da mensagem |
LR_SYNC_DOWNLOAD_HEADER |
HDRSYNC |
Exemplo: carregando uma hierarquia de pastas
Ao carregar uma hierarquia de pastas, ocorre a seguinte sequência de etapas:
|
Etapa |
Ação |
Estado |
Estrutura de dados relacionada |
|---|---|---|---|
| 1. | O cliente inicia o upload da hierarquia com IOSTX::SyncBeg. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 2. | O Outlook 2013 ou Outlook 2010 preenche UPHIER com informações para o cliente. Isso inclui inicializar os parâmetros [out]: iEnt é definido como 0 e cEnt para o número de pastas na hierarquia que precisa ser carregada. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 3. | O cliente faz o upload da hierarquia real. Por exemplo, se cEnt for 10, para cada uma das 10 pastas, o cliente chamará IOSTX::SyncBeg, especificando o identificador de estado apropriado e a estrutura de dados para carregar uma pasta. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 4. | O Outlook 2013 ou Outlook 2010 preenche o UPFLD inicializando seus parâmetros [out], incluindo o motivo do upload da pasta, o ponteiro para o objeto da pasta e a ID de entrada da pasta. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 5. | O cliente carrega a pasta especificada. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 6. | O cliente notifica o repositório local sobre a conclusão do carregamento da pasta: Em caso de êxito, o cliente define o parâmetro [in] ulFlags no UPFLD com UPF_OK e, em seguida, chama IOSTX::SetSyncResult (S_OK) e IOSTX::SyncEnd. Em caso de falha, o cliente não definiria ulFlags com o sinalizador UPF_OK . Ele chama IOSTX::SetSyncResult, passando o valor HRESULT e IOSTX::SyncEnd. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 7. | Se UPF_OK estiver definido, o Outlook 2013 ou o Outlook 2010 limpará a solicitação interna para carregar a pasta. Em seguida, independentemente do estado de ulFlags, ele irá limpar qualquer informação interna de contabilidade. Embora ainda haja pastas na hierarquia para carregar (iEnt ainda é menor que cEnt), o cliente e o Outlook 2013 ou Outlook 2010 repetem as etapas 3 a 7. |
LR_SYNC_UPLOAD_FOLDER |
UPFLD |
| 8. | O cliente notifica o repositório local sobre a conclusão do upload da hierarquia: Em caso de êxito, o cliente define o sinalizador [in] no UPHIER com UPH_OK e, em seguida, chama IOSTX::SetSyncResult (S_OK) e IOSTX::SyncEnd. Em caso de falha, o cliente não definiria o sinalizador UPH_OK . Ele chama IOSTX::SetSyncResult, passando o valor HRESULT e IOSTX::SyncEnd. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |
| 9. | Se UPH_OK estiver definido, o Outlook 2013 ou o Outlook 2010 limpará a solicitação interna para carregar a hierarquia. Em seguida, independentemente do estado de ulFlags, ele irá limpar qualquer informação interna de contabilidade. |
LR_SYNC_UPLOAD_HIERARCHY |
UPHIER |