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
Como outros provedores de serviços MAPI, os repositórios de mensagens são bibliotecas de vínculo dinâmico (DLLs) que apresentam os serviços de um mecanismo de armazenamento subjacente para aplicativos cliente MAPI e o spooler MAPI. O provedor do repositório de mensagens apresenta o mecanismo de armazenamento subjacente como um conjunto hierárquico de pastas e mensagens que os clientes MAPI e o spooler MAPI podem usar.
A ilustração a seguir mostra a arquitetura básica do repositório de mensagens MAPI.
Message store architecture
É possível implementar um provedor de repositório de mensagens usando qualquer tipo de mecanismo de armazenamento subjacente que desejar. No entanto, você precisa estar ciente das preocupações de desempenho. Além disso, o mecanismo de armazenamento subjacente deve ser apresentado como uma coleção hierárquica de objetos MAPI. Esses requisitos significam que os armazenamentos de mensagens são normalmente implementados usando um produto de banco de dados existente que suporta o armazenamento hierárquico de objetos no banco de dados e que possui uma interface de programação ou estrutura de arquivos bem definida. Por exemplo, os bancos de dados SQL e Oracle do Microsoft Office Access podem ser usados como o mecanismo de armazenamento subjacente. Alguns produtos de banco de dados têm conjuntos de recursos que facilitam a implementação de recursos MAPI, portanto, sua escolha de produto de banco de dados pode ser afetada pelos recursos que o provedor de repositório de mensagens precisa suportar.
Usar um banco de dados existente como o mecanismo de armazenamento subjacente economiza seu trabalho, pois geralmente é mais fácil apresentar objetos de banco de dados a clientes MAPI como objetos MAPI do que implementar seu próprio mecanismo de armazenamento hierárquico. Isso permite que você trate as operações MAPI em um nível mais alto do que se você implementasse seu próprio mecanismo de armazenamento hierárquico. Por exemplo, pesquisar uma mensagem com uma linha de assunto específica torna-se uma questão bastante simples de construir e enviar uma consulta de banco de dados apropriada, em vez de implementar rotinas complexas para pesquisar seu mecanismo de armazenamento hierárquico.
Os provedores do repositório de mensagens se comunicam com clientes MAPI e com o spooler MAPI para executar operações em pastas e objetos. O provedor do repositório de mensagens converte essas operações em operações de nível inferior no mecanismo de armazenamento subjacente. O spooler MAPI normalmente se comunica com o provedor do repositório de mensagens ao enviar e receber mensagens. Os clientes MAPI normalmente se comunicam com provedores de repositório de mensagens para manipular a hierarquia de pastas e ler, editar, excluir e enviar mensagens.
O spooler MAPI e os clientes MAPI se comunicam com o provedor do repositório de mensagens para criar novas mensagens. Os aplicativos cliente fazem isso quando os usuários escrevem uma mensagem. O spooler MAPI faz isso quando recebe uma mensagem de entrada. Em ambos os casos, a nova mensagem geralmente é criada na pasta Caixa de Entrada do repositório de mensagens, se houver uma.
Os provedores de repositório de mensagens fazem uso intensivo de tabelas, pastas, mensagens e propriedades MAPI. Os detalhes de implementação para esses objetos estão documentados em Tabelas MAPI, Pastas MAPI, Mensagens MAPI e Visão Geral de Propriedades MAPI. Você deve se familiarizar com esse material antes de tentar implementar um provedor de repositório de mensagens.
Existem dois tipos importantes de provedores de repositório de mensagens: aqueles que podem atuar como o repositório de mensagens padrão de um usuário e aqueles que não podem. Um repositório de mensagens padrão é aquele em que os aplicativos cliente e o spooler MAPI podem realizar qualquer tarefa de messaging, como receber mensagens ou criar pastas. Um provedor de repositório de mensagens padrão deve dar suporte a vários outros recursos do que o número mínimo necessário para todos os provedores de repositório de mensagens.