O envio de formulários InfoPath via email (como anexo) a ser analisado pelo SQL Server 2005?

Question

Basta olhar para os requisitos de um novo projeto e eu queria ter certeza que este caso de uso foi de som:

• preenchimentos de usuários no InfoPath (2003) forma localmente no seu PC
• um botão dentro do formulário InfoPath intitulado 'enviar' traz uma mensagem de e-mail nova perspectiva (2003) com a forma infopath anexado. usuário pressiona envia e-mail é enviado para uma caixa de correio do Exchange.
• sql server preiodically verifica esta caixa de correio, o download de novas observações com o formulário do InfoPath anexado
• SQL Server analisa o anexo e os campos dentro do formulário do InfoPath.

é SQL Server capaz de analisar anexos de correio desta forma? Quaisquer ressalvas com esta abordagem?

A atração de usar o Outlook como a tecnologia submissão é que o processo para o usuário é o mesmo se eles estiverem off-line. Outlook irá então sincronizar automaticamente quando eles voltam online. É essencial que os usuários têm alguma forma de preencher os formulários em desligada, 'enviar'-los, e, em seguida, ter então sincronizados automaticamente com o servidor quando chegar próximo online.

Edit: Para esclarecer, eu não estou procurando uma maneira de dados do formulário de cache do servidor-> cliente. Eu estou olhando para armazenar em cache o formulário preenchido. Construindo um aplicativo separado para armazenar em cache os relatórios preenchidos no cliente não é uma opção.

Answer 1

As versões posteriores do SQL Server são capazes de executar código .NET dentro deles, e como tal, você pode ser capaz de pesquisar uma caixa de correio a partir do SQL Server e processar um formulário do InfoPath. No entanto, não estou certo de que iria fazê-lo desta forma.

Talvez seja melhor considerar escrever um serviço do Windows que faz este trabalho. O serviço Windows iria iniciar-se, inspecionar a caixa de correio de uma "conta de serviço", ler os e-mails, extrair os anexos, processar o xml e, finalmente, gravar os dados em SQL. Poderia também, presumivelmente, responder a esse e-mail com a confirmação ou erros se regras de negócios ou erros de validação ocorreu.

Eu não tenho certeza que eu ia colocar toda a lógica acima em SQL - para uma coisa, eu suspeito que você teria problemas com contas (que têm que ter a conta SQL foi executado sob acessar a caixa de correio Exchange conta).

Sua milhagem pode variar, e você deve protótipo isso para determinar o que funciona melhor para você, mas eu tentar manter o código dos usos de câmbio como uma "fila de trabalho" separado do SQL e só colocar o código que lida com gravação de dados em tabelas em SQL.

Answer 2

Eu não usaria a abordagem que você descrito acima. Existem várias abordagens que me parecem ser mais desejável do que ter SQL Server olhando para uma caixa de correio Exchange. O principal ponto que você faz e um requisito importante é que a forma InfoPath ser autorizados a trabalhar no modo offline. Gostaria de pensar do "modo off-line" e "transferência de dados" partes do seu projeto como duas distintas e separadas peças: 1) A forma e os dados devem ser armazenados no cliente até que uma conexão à Internet está disponível e 2) uma vez que a conexão está disponível o formulário e os dados devem ser transferidos para o servidor.

Você pode configurar o seu formulário do InfoPath para enviar diretamente para o SQL Server e ignorar a Bolsa "intermediário" inteiramente. A configuração no InfoPath quando você está projetando seu formulário é bastante simples: 1) você ativar "Enviar dados" para a conexão e 2) você configurar as opções de enviar. Este artigo tem os detalhes sobre como fazer isso. Além disso, a conexão com o SQL Server pode ser configurado para uso offline, como é discutido neste artigo . A única ressalva com esta abordagem é que você pode precisar de mudar seu esquema de banco de dados para apoiá-lo.

Outra abordagem é ter seu formulário InfoPath submeter a um SQL Server 2005 HTTP Endpoint. O cliente InfoPath é apenas um editor XML glorificado e o HTTP Endpoint é basicamente um nome diferente para um serviço web. Você recebe os dados do formulário no HTTP ponto final em uma tabela de preparação onde os dados são armazenados como XML e, em seguida, você pode fazer sua análise de que os dados de que a área de preparo. Ainda assim você terá que configurar a conexão InfoPath para uso offline. A ressalva importante dessa abordagem é que a Microsoft vai deprecate HTTP Endpoint no SQL Server 2008 em favor da WCF.

E a outra abordagem que eu gostaria de sugerir é usar WCF-se para receber os dados do formulário XML do cliente InfoPath. Esta abordagem exigiria que você se conectar fonte de dados do formulário para você WCF serviço web em tempo de design e, em seguida, também configurar o formulário para utilização offline.

Espero que este será útil para você e, no mínimo, você aponte na direção certa.

Answer 3

Já vi projetos semelhantes que recorreram a uma edição Express no cliente, senão o InfoPath (ou dados app) in expresso e utilizar Service Broker para entregar ao centro, por causa da semântica de entrega garantida de SSB correio vs.. Isto dá-lhe uma solução all SQL mais fácil vender para ele e você não precisa de votação no servidor. Além disso, você não terá que lidar com MIME análise, é todo o processamento de XML para a frente. Não é para os fracos de coração, porém, ficando SSB instalado e funcionando é um desafio. Se você decidir ir com entrega de correio, um serviço externo será sem dúvida mais fácil de construir, depurar e solucionar problemas. Há algumas questões pontuais mais fino que você deve ter uma resposta para: -Como você vai manter consistente as operações de correio dequeue e as operações mesa de escrita? O seu componente deve envolver a troca de leitura / exclusão e inserção SQL em uma transação distribuída. - É a sua lógica preparado para lidar com docs InfoPath saindo de ordem? transporte de correio faz absolutamente nenhuma garantia sobre a ordem de entrega, para que você pode ver um doc 'fim delete' antes do 'fim criar' doc - Como você está indo para detectar documentos em falta (não entregues por correio)? Você está indo para implementar um número de seqüência remetente e acabam reinventar TCP em cima de e-mail? - Será que o seu processamento permitem processo paralelo de documentos correlacionados? Se rosca 1 pega doc 1 e linha 2 pega doc 2 do mesmo remetente e doc 2 está correlacionada com doc 1 (ie. Referem-se a mesma transação comercial), o que vai acontecer na gravação de banco de dados? Será que vai impasse, vai perder uma atualização, um será revertida?

Existem muitas dragões debaixo da ponte em frente ...