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
O spooler MAPI usa o método IXPLogon::FlushQueues para baixar e carregar todas as mensagens pendentes de e para um provedor de transporte. Normalmente, o spooler MAPI liberará as filas para todos os provedores de transporte que estão conectados à sessão, começando com o primeiro provedor de transporte, conforme definido na seção ordem de transporte do perfil do usuário. A liberação de filas é quase sempre o resultado de uma solicitação direta do usuário, portanto, o envio e o recebimento de mensagens enquanto as filas estão sendo liberadas são síncronos com o spooler MAPI. Como essas chamadas são síncronas, o provedor de transporte deve processá-las o mais rápido possível.
Os provedores de transporte devem lidar com a chamada FlushQueues conforme descrito na seguinte sequência de etapas para habilitar o processamento adequado de mensagens e permitir que recursos externos, como modems, sejam usados por outros provedores de transporte como parte da operação FlushQueues do spooler MAPI.
| Etapa | Componente | Implementação |
|---|---|---|
| 1. | Spooler MAPI |
Chama o método FlushQueues para o primeiro provedor de transporte listado na ordem de transporte do perfil do usuário, passando os sinalizadores solicitados no parâmetro ulFlags . FlushQueues é chamado uma vez com todos os sinalizadores definidos para toda a operação de upload e download. |
| 2. | Provedor de Transporte |
Precisa fazer várias coisas antes de retornar da chamada FlushQueues . Se as mensagens enviadas anteriormente estiverem sendo adiadas, o método IMAPISupport::SpoolerNotify deverá ser chamado com o sinalizador NOTIFY_SENT_DEFERRED definido. Observe que é possível que o spooler MAPI cancele uma mensagem que foi adiada antes que o provedor de transporte tenha a oportunidade de concluir o processamento da mensagem. Se o provedor de transporte usar um recurso externo, como um modem, a conexão com o recurso externo deverá ser estabelecida. O bit de STATUS_OUTBOUND_FLUSH na propriedade PR_STATUS_CODE (PidTagStatusCode) da linha de status do provedor de transporte deve ser definido usando o método IMAPISupport::ModifyStatusRow . O provedor de transporte deve retornar S_OK para a chamada FlushQueues . |
| 3. | Spooler MAPI |
Verifica a linha de status do provedor de transporte para o bit STATUS_OUTBOUND_FLUSH e chama IXPLogon::SubmitMessage para a primeira mensagem na fila. |
| 4. | Provedor de transporte |
Manipula a mensagem e retorna da chamada SubmitMessage . |
| 5. | Spooler MAPI |
Se o provedor de transporte retornar S_OK de SubmitMessage, o spooler MAPI chamará IXPLogon::EndMessage para a mensagem como faz com o envio normal de mensagens. Se o provedor de transporte retornar um valor diferente de S_OK de SubmitMessage, o spooler MAPI manipulará o valor adequadamente antes de chamar EndMessage ou antes de chamar SubmitMessage novamente. |
| 6. | Provedor de transporte |
Retorna de EndMessage com seu status de processamento de mensagens no parâmetro lpulFlags. |
| 7. | Spooler MAPI e provedor de transporte |
O loop SubmitMessage- EndMessage continua até que todas as mensagens na fila tenham sido baixadas. |
| 8. | Spooler MAPI |
Notifica o provedor de transporte de que terminou de baixar mensagens chamando o método IXPLogon::TransportNotify do provedor de transporte com o sinalizador NOTIFY_END_OUTBOUND_FLUSH definido. |
| 9. | Provedor de transporte |
Libera todos os recursos externos usados no envio de mensagens de saída para que possam ser usados por outros provedores de transporte para liberar suas filas. O bit STATUS_INBOUND_FLUSH na propriedade PR_STATUS_CODE da linha de status do provedor de transporte deve ser definido usando ModifyStatusRow. |
| 10. | Spooler MAPI |
Verifica a linha de status do provedor de transporte para o bit STATUS_INBOUND_FLUSH e chama IXPLogon::StartMessage se estiver definido. |
| 11. | Provedor de transporte |
Processa a mensagem e retorna de StartMessage. Se o provedor de transporte tiver outras mensagens para carregar, ele deverá chamar SpoolerNotify com o sinalizador NOTIFY_NEWMAIL definido. Se o provedor de transporte não tiver mensagens para carregar, ele deverá chamar IMAPIProp::SaveChanges na mensagem que o spooler MAPI passou em StartMessage e retornar. |
| 12. | Spooler MAPI |
Continua chamando StartMessage até que SaveChanges seja chamado em uma mensagem. Depois que o provedor de transporte termina de carregar, o spooler MAPI chama TransportNotify com o sinalizador NOTIFY_END_INBOUND_FLUSH definido. |
| 13. | Provedor de transporte |
Limpa o bit de STATUS_INBOUND_FLUSH na propriedade PR_STATUS_CODE de sua linha de status usando ModifyStatusRow e libera todos os recursos externos para que estejam disponíveis para uso por outros provedores de transporte. |
| 14. | Spooler MAPI |
Chama FlushQueues para o próximo provedor de transporte listado na ordem de transporte do perfil do usuário. |
Se um aplicativo cliente chamar IMAPIStatus::FlushQueues no objeto de status de um provedor de transporte, o provedor de transporte deverá definir o bit apropriado em sua linha de status com ModifyStatusRow. Em seguida, o spooler MAPI chama o método IXPLogon::FlushQueues do provedor de transporte conforme a conveniência do spooler MAPI. Quando o método IXPLogon::FlushQueues do provedor de transporte é chamado como resultado da chamada IMAPIStatus::FlushQueues de um aplicativo cliente, a operação ocorre de forma assíncrona com o aplicativo cliente. Caso contrário , IXPLogon::FlushQueues funciona de forma síncrona com o spooler MAPI.
Por motivos de desempenho, o spooler MAPI só chamará o método FlushQueues de um provedor de transporte se os sinalizadores de STATUS_INBOUND_FLUSH e STATUS_OUTBOUND_FLUSH estiverem definidos na linha status do provedor de transporte. Consequentemente, um provedor de transporte pode interromper a operação FlushQueues a qualquer momento limpando os sinalizadores STATUS_OUTBOUND_FLUSH e STATUS_INBOUND_FLUSH em sua linha status. Se o spooler MAPI estiver sendo desligado e precisar encerrar a operação FlushQueues , ele chamará TransportNotify com os sinalizadores NOTIFY_END_INBOUND_FLUSH e NOTIFY_END_OUTBOUND_FLUSH definidos. O provedor de transporte deve liberar todos os recursos externos e retornar.