Envoi de formulaires d'infopath par courrier électronique (en pièce jointe) à analyser par SQL Server 2005?

Question

Juste en regardant les exigences d'un nouveau projet et je voulais m'assurer que ce cas d'utilisation était valable:

• l'utilisateur remplit le formulaire InfoPath (2003) localement sur son PC
• Dans le formulaire InfoPath, un bouton intitulé "soumettre" permet d'afficher un nouveau message électronique Outlook (2003) auquel est associé le formulaire Infopath. L'utilisateur appuie sur les envois et le courrier électronique est envoyé à une boîte aux lettres d'échange.
• Le serveur SQL vérifie périodiquement cette boîte aux lettres et télécharge toute nouvelle soumission avec le formulaire d'infopath joint
• SQL Server analyse la pièce jointe et les champs du formulaire Infopath.

SQL Server est-il capable d’analyser les pièces jointes de cette manière? Des mises en garde avec cette approche?

L'intérêt d'utiliser Outlook comme technologie de soumission réside dans le fait que le processus est identique pour l'utilisateur s'il est hors connexion. Outlook se synchronisera automatiquement à leur retour en ligne. Il est essentiel que les utilisateurs aient le moyen de remplir les formulaires hors connexion, de les "soumettre", puis de les synchroniser automatiquement avec le serveur lors de leur prochaine connexion.

modifier: pour clarifier, je ne cherche pas un moyen de mettre en cache les données de formulaire à partir du serveur - > client. Je cherche à cacher le formulaire complété. La création d'une application distincte pour mettre en cache les rapports terminés sur le client n'est pas une option.

Answer 1

Les versions ultérieures de SQL Server sont capables d’exécuter du code .NET, ce qui vous permet d’interroger une boîte aux lettres à partir de SQL Server et de traiter un formulaire InfoPath. Cependant, je ne suis pas sûr que je le ferais de cette façon.

Il serait peut-être préférable d’envisager d’écrire un service Windows qui fonctionne de la sorte. Le service Windows devait démarrer, inspecter la boîte aux lettres d'un "compte de service", lire les e-mails, extraire les pièces jointes, traiter le fichier XML et, éventuellement, écrire les données dans SQL. Il est également probable que le courrier électronique répondrait à ce courrier par une confirmation ou des erreurs en cas d'erreur de règles commerciales ou de validation.

Je ne suis pas sûr que je mettrais toute la logique ci-dessus dans SQL. D'abord, je suppose que vous auriez des problèmes avec les comptes (le fait que le compte SQL était en cours d'exécution permettait d'accéder à la boîte aux lettres Exchange. compte).

Votre kilométrage peut varier, et vous devriez créer un prototype pour déterminer ce qui vous convient le mieux, mais je voudrais essayer de conserver le code utilisé par Exchange en tant que "file d'attente de travail". séparer de SQL et ne mettre que le code qui traite de l'écriture de données dans des tables en SQL.

Answer 2

Je n'utiliserais pas l'approche que vous avez décrite ci-dessus. Plusieurs approches me paraissent plus souhaitables que de laisser SQL Server examiner une boîte aux lettres Exchange. Le point principal que vous soulignez et une exigence importante est que le formulaire InfoPath soit autorisé à fonctionner en mode hors connexion. Je penserais au " mode hors connexion " et le " transfert de données " les parties de votre projet en deux parties distinctes et distinctes: 1) Le formulaire et les données doivent être stockés sur le client jusqu'à ce qu'une connexion à Internet soit disponible et 2) une fois la connexion disponible, le formulaire et les données doivent être transférés sur le serveur. .

Vous pouvez configurer votre formulaire InfoPath pour le soumettre directement à SQL Server et contourner Exchange " middleman " entièrement. La configuration dans InfoPath lors de la conception de votre formulaire est assez simple: 1) vous activez l'option "Soumettre les données". pour la connexion et 2) vous configurez les options de soumission. Cet article contient des informations détaillées sur la procédure à suivre. De plus, votre connexion à SQL Server peut être configurée pour une utilisation hors connexion, comme indiqué dans ce document article . Le seul inconvénient de cette approche est que vous devrez peut-être modifier le schéma de votre base de données pour la prendre en charge.

Une autre approche consiste à soumettre votre formulaire InfoPath à un noeud final HTTP SQL Server 2005. Le client InfoPath est simplement un éditeur XML enrichi et le noeud final HTTP est fondamentalement un nom différent pour un service Web. Vous recevez les données de formulaire sur le noeud final HTTP dans une table intermédiaire dans laquelle les données sont stockées au format XML. Vous pouvez ensuite analyser vos données à partir de cette zone intermédiaire. Vous devrez néanmoins configurer la connexion InfoPath pour une utilisation hors connexion. Le principal inconvénient de cette approche est que Microsoft désapprouvera HTTP Endpoint dans SQL Server 2008 en faveur de WCF.

L’autre approche que je voudrais suggérer consiste à utiliser WCF lui-même pour recevoir les données de formulaire XML à partir du client InfoPath. Selon cette approche, vous devez connecter la source de données du formulaire à votre service Web WCF au moment de la conception, puis configurer le formulaire pour une utilisation hors connexion.

J'espère que cela vous sera utile et vous indiquera tout au moins la bonne direction.

Answer 3

J'ai vu des projets similaires qui utilisaient une édition Express sur le client, sauvegardaient l'infopath (ou les données d'application) dans Express et utilisaient Service Broker pour livrer au centre, en raison de la sémantique de livraison garantie entre SSB et courrier. Cela vous donne une solution tout SQL plus facile à vendre au service informatique et vous n'avez pas besoin d'interrogation sur le serveur. De plus, vous n'aurez pas à traiter avec l'analyse MIME, c'est tout un traitement XML simple. Ce n’est pas pour les âmes sensibles cependant, que SSB soit opérationnel est un défi. Si vous décidez d’accepter la remise du courrier, un service externe sera sans doute plus facile à créer, à déboguer et à résoudre. Il y a quelques points plus précis pour lesquels vous devriez avoir une réponse: -Comment garderez-vous cohérentes les opérations de retrait de courrier et les opérations d'écriture de table? Votre composant doit engager la lecture / suppression Exchange et l'insertion SQL dans une transaction distribuée. - Votre logique est-elle prête à faire face aux problèmes de documentation d'infopath? le transport de courrier ne donne aucune garantie quant à l'ordre de livraison; vous pouvez donc voir un document 'order delete' avant le document 'order create' - Comment allez-vous détecter les documents manquants (non livrés par courrier)? Allez-vous implémenter un numéro de séquence d'expéditeur et réinventer le protocole TCP en plus du courrier? - Votre traitement permet-il le traitement en parallèle de documents corrélés? Si le fil 1 prend le document 1 et que le fil 2 prend le document 2 du même expéditeur et que le document 2 est en corrélation avec le document 1 (c'est-à-dire qu'il fait référence à la même transaction commerciale), que se passera-t-il lors de l'écriture de la base de données? Est-ce que cela va bloquer, va-t-il perdre une mise à jour, sera-t-il annulé?

Il y a beaucoup de dragons sous le pont devant vous ...