Implementando o método FlushQueues
Aplica-se a: Outlook 2013 | Outlook 2016
O spooler MAPI usa o método IXPLogon::FlushQueues para baixar e carregar mensagens pendentes de e para um provedor de transporte. Normalmente, o spooler MAPI libera as filas para todos os provedores de transporte conectados à sessão, começando com o primeiro provedor de transporte conforme definido na seção de 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íncrono para 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 sequência de etapas a seguir para habilitar o processamento de mensagens adequado e permitir que recursos externos, como modems, sejam usados por outros provedores de transporte como parte da operação FlushQueues do carreador 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 . O 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 conjunto de sinalizadores NOTIFY_SENT_DEFERRED. Observe que é possível que o spooler MAPI cancele uma mensagem que foi adiada antes que o provedor de transporte tenha a chance 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 STATUS_OUTBOUND_FLUSH na propriedade PR_STATUS_CODE (PidTagStatusCode) da linha status do provedor de transporte deve ser definido usando o método IMAPISupport::ModifiStatusRow. Em seguida, o provedor de transporte deve retornar S_OK para a chamada FlushQueues . |
| 3. | Spooler MAPI |
Verifica a linha 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 do SubmitMessage, o spooler MAPI chamará IXPLogon::EndMessage para a mensagem como faz com o envio regular de mensagens. Se o provedor de transporte retornar um valor diferente de S_OK do SubmitMessage, o spooler MAPI manipulará o valor adequadamente antes de chamar EndMessage ou antes de chamar SubmitMessage novamente. |
| 6. | Provedor de transporte |
Retorna do EndMessage com seu status de processamento de mensagens no parâmetro lpulFlags. |
| 7. | Provedor de transporte e spooler MAPI |
O loop SubmitMessage- EndMessage continua até que todas as mensagens na fila sejam baixadas. |
| 8. | Spooler MAPI |
Notifica o provedor de transporte que terminou de baixar mensagens chamando o método IXPLogon::TransportNotify do provedor de transporte com o conjunto de sinalizadores NOTIFY_END_OUTBOUND_FLUSH. |
| 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 status do provedor de transporte deve ser definido usando ModifiStatusRow. |
| 10. | Spooler MAPI |
Verifica a linha status do provedor de transporte para o bit STATUS_INBOUND_FLUSH e chama IXPLogon::StartMessage se ele estiver definido. |
| 11. | Provedor de transporte |
Processa a mensagem e retorna do StartMessage. Se o provedor de transporte tiver outras mensagens para carregar, ele deve chamar SpoolerNotify com o conjunto de sinalizadores NOTIFY_NEWMAIL. Se o provedor de transporte não tiver mensagens para carregar, ele deve 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 terminar de carregar, o spooler MAPI chama TransportNotify com o conjunto de sinalizadores NOTIFY_END_INBOUND_FLUSH. |
| 13. | Provedor de transporte |
Limpa o bit STATUS_INBOUND_FLUSH na propriedade PR_STATUS_CODE de sua linha status usando ModifiStatusRow e libera todos os recursos externos para que eles 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 status de um provedor de transporte, o provedor de transporte deverá definir o bit apropriado em sua linha status com ModifiStatusRow. O spooler MAPI então chama o método IXPLogon::FlushQueues do provedor de transporte na 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 para 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 STATUS_INBOUND_FLUSH e STATUS_OUTBOUND_FLUSH forem 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 o conjunto de sinalizadores NOTIFY_END_INBOUND_FLUSH e NOTIFY_END_OUTBOUND_FLUSH. O provedor de transporte deve liberar todos os recursos externos e retornar.