Interação com o spooler MAPI

Aplica-se a: Outlook 2013 | Outlook 2016

Os métodos na interface IXPLogon : IUnknown são usados pelo spooler MAPI ao chamar o provedor de transporte. Deve ser possível para a maioria dos tipos de prestadores de serviços de transporte implementar a maioria destes métodos para que regressem rapidamente. Isso é desejável porque, se um método demorar muito para retornar, ele deverá ser interrompido com chamadas de volta ao spooler MAPI para liberar a CPU para outras tarefas.

O spooler MAPI faz seu trabalho e faz suas chamadas para provedores de transporte quando os aplicativos em primeiro plano estão ociosos. Depois de exibir opcionalmente caixas de diálogo quando o provedor de transporte faz logon pela primeira vez (regido por sinalizadores passados do MAPI para o provedor de transporte), os provedores de transporte operam em segundo plano, a menos que sejam chamados pelo cliente para liberar as filas de envio e recebimento. A liberação de filas é o único momento em que um provedor de transporte não precisa liberar a CPU e somente se o usuário for informado de que uma ação potencialmente longa está em andamento. O spooler MAPI normalmente solicita que um provedor de transporte libere suas filas em resposta a uma ação do usuário, portanto, o provedor de transporte normalmente não precisa fazer nada para garantir que o usuário seja informado.

Um provedor de transporte pode decidir independentemente liberar uma fila e usar os bits de STATUS_INBOUND_FLUSH e STATUS_OUTBOUND_FLUSH na propriedade PR_STATUS_CODE (PidTagStatusCode) de sua linha de status para informar ao spooler MAPI que ele quer atenção para que ele possa fazer o trabalho. A linha de status é atualizada usando o método IMAPISupport::ModifyStatusRow . Nesse caso, o provedor de transporte provavelmente deve exibir um indicador de progresso ou outra interface para informar ao usuário que uma ação longa está ocorrendo.

Como a atividade de rede geralmente leva mais de 0,2 segundos, os provedores de transporte devem, sempre que possível, usar solicitações de rede assíncronas. Isso permite que eles iniciem uma solicitação, liberem a CPU chamando de volta para o spooler MAPI e, quando o spooler MAPI lhes der o controle novamente, para marcar se a solicitação de rede foi concluída. Se ainda não tiver sido concluído, eles liberarão novamente a CPU chamando de volta para o spooler MAPI com o método IMAPISupport::SpoolerYield .

Durante o processamento de mensagens, entre IXPLogon::SubmitMessage e IXPLogon::EndMessage e durante IXPLogon::StartMessage, o provedor de transporte normalmente faz muitas chamadas em objetos expostos a ele pelo spooler MAPI. Como parte do manuseio desses objetos, o spooler MAPI ajuda o provedor de transporte a se comportar adequadamente como um processo em segundo plano, cedendo por conta própria quando apropriado. Um provedor de transporte que exige processamento de tempo crítico pode declarar uma seção crítica para o spooler MAPI usando o método de objeto de suporte IMAPISupport::SpoolerNotify . Nesse caso, a CPU é liberada somente em chamadas explícitas de SpoolerYield pelo provedor de transporte até que o provedor de transporte termine o processamento de seção crítica com outra chamada para SpoolerNotify.

Observação

Isso não é o mesmo que uma seção crítica do Win32. Isso só deve ser feito quando o provedor de transporte precisar de controle em tempo real de recursos externos, como a leitura de dados recebidos de uma linha de fax. Como isso gera a prioridade do processo de spooler MAPI e pode fazer com que a estação de trabalho pare de responder durante a operação, é uma boa ideia notificar o usuário de que uma ação potencialmente longa está em andamento e fornecer um indicador de progresso, se possível.