Senden von Infopath-Formularen per E-Mail (als Anhang), die von SQL Server 2005 geparst werden sollen?

Question

Ich sehe mir gerade die Anforderungen für ein neues Projekt an und wollte sicherstellen, dass dieser Anwendungsfall fundiert ist:

• der Benutzer füllt das InfoPath (2003)-Formular lokal auf seinem PC aus
• eine Schaltfläche im InfoPath-Formular mit dem Titel "Absenden" öffnet eine neue Outlook (2003)-E-Mail-Nachricht mit dem angehängten InfoPath-Formular. Der Benutzer drückt auf "Senden" und die E-Mail wird an ein Exchange-Postfach gesendet.
• Der Sql-Server prüft dieses Postfach regelmäßig und lädt alle neuen Eingaben mit dem angehängten Infopath-Formular herunter.
• Sql-Server analysiert den Anhang und die Felder im Infopath-Formular.

Ist SQL Server in der Lage, E-Mail-Anhänge auf diese Weise zu analysieren? Gibt es bei diesem Ansatz irgendwelche Vorbehalte?

Der Vorteil der Verwendung von Outlook als Übermittlungstechnologie besteht darin, dass der Prozess für den Benutzer derselbe ist, auch wenn er offline ist. Outlook wird dann automatisch synchronisiert, wenn sie wieder online sind. Es ist wichtig, dass die Benutzer eine Möglichkeit haben, die Formulare offline auszufüllen, sie "einzureichen" und sie dann automatisch mit dem Server zu synchronisieren, wenn sie das nächste Mal online sind.

Bearbeiten: um zu klären, ich bin nicht auf der Suche nach einer Möglichkeit, Formular-Daten vom Server->Client zu cachen. Ich möchte das ausgefüllte Formular zwischenspeichern. Der Aufbau einer separaten Anwendung zum Zwischenspeichern der ausgefüllten Berichte auf dem Client ist keine Option.

Answer 1

Ich würde nicht so vorgehen, wie Sie es oben beschrieben haben. Es gibt mehrere Ansätze, die mir wünschenswerter erscheinen, als dass SQL Server auf ein Exchange-Postfach zugreift. Der wichtigste Punkt, den Sie ansprechen, und eine wichtige Anforderung ist, dass das InfoPath-Formular im Offline-Modus arbeiten kann. Ich würde den "Offlinemodus" und den "Datentransfer" als zwei unterschiedliche und getrennte Teile Ihres Projekts betrachten: 1) Das Formular und die Daten sollten auf dem Client gespeichert werden, bis eine Verbindung zum Internet verfügbar ist, und 2) sobald die Verbindung verfügbar ist, sollten das Formular und die Daten auf den Server übertragen werden.

Sie können Ihr InfoPath-Formular so einrichten, dass es direkt an den SQL-Server übermittelt wird und den Exchange-Zwischenhändler völlig umgeht. Die Einrichtung in InfoPath, wenn Sie Ihr Formular entwerfen, ist ziemlich einfach: 1) Sie aktivieren "Daten übermitteln" für die Verbindung und 2) Sie konfigurieren die Übermittlungsoptionen. Diese Artikel finden Sie die Einzelheiten dazu. Außerdem kann Ihre Verbindung zum SQL Server für die Offline-Nutzung eingerichtet sein, wie in diesem Artikel beschrieben Artikel . Der einzige Nachteil dieses Ansatzes ist, dass Sie möglicherweise Ihr Datenbankschema ändern müssen, um ihn zu unterstützen.

Ein anderer Ansatz besteht darin, Ihr InfoPath-Formular an einen SQL Server 2005 HTTP-Endpunkt zu übermitteln. Der InfoPath-Client ist nur ein besserer XML-Editor und der HTTP-Endpunkt ist im Grunde ein anderer Name für einen Webdienst. Sie empfangen die Formulardaten am HTTP-Endpunkt in einer Staging-Tabelle, in der die Daten als XML gespeichert sind, und können dann die Daten von diesem Staging-Bereich aus analysieren. Dennoch müssen Sie die InfoPath-Verbindung für die Offline-Nutzung einrichten. Der größte Nachteil dieses Ansatzes ist, dass Microsoft den HTTP-Endpunkt in SQL Server 2008 zugunsten von WCF verwerfen wird.

Und der andere Ansatz, den ich vorschlagen möchte, ist die Verwendung von WCF selbst, um die XML-Formulardaten vom InfoPath-Client zu empfangen. Bei diesem Ansatz müssten Sie die Datenquelle des Formulars zur Entwurfszeit mit dem WCF-Webdienst verbinden und dann das Formular für die Offline-Nutzung einrichten.

Ich hoffe, dass diese Informationen für Sie nützlich sind und Ihnen zumindest die richtige Richtung weisen.

Answer 2

Spätere Versionen von SQL Server sind in der Lage, .NET-Code auszuführen, und so können Sie möglicherweise ein Postfach von SQL Server aus abrufen und ein InfoPath-Formular verarbeiten. Ich bin mir jedoch nicht sicher, ob ich es auf diese Weise tun würde.

Es wäre vielleicht besser, einen Windows-Dienst zu schreiben, der diese Arbeit erledigt. Der Windows-Dienst würde starten, die Mailbox eines "Dienstkontos" untersuchen, die Mails lesen, die Anhänge extrahieren, die XML-Daten verarbeiten und schließlich die Daten in SQL schreiben. Er könnte vermutlich auch auf diese Mail mit einer Bestätigung oder mit Fehlern reagieren, wenn Geschäftsregeln oder Validierungsfehler auftreten.

Ich bin mir nicht sicher, ob ich die gesamte obige Logik in SQL umsetzen würde - zum einen vermute ich, dass Sie Probleme mit Konten haben würden (das Konto, unter dem SQL ausgeführt wird, muss auf das Exchange-Postfachkonto zugreifen können).

Ich würde jedoch versuchen, den Code, der Exchange als "Arbeitswarteschlange" verwendet, von SQL zu trennen und nur den Code, der sich mit dem Schreiben von Daten in Tabellen befasst, in SQL zu speichern.

Answer 3

Ich habe ähnliche Projekte gesehen, bei denen auf eine Express-Edition auf dem Client zurückgegriffen wurde, die Infopath- (oder Anwendungsdaten) in Express gespeichert wurden und der Service Broker für die Zustellung an das Zentrum verwendet wurde, da die Semantik von SSB im Vergleich zu Mail eine garantierte Zustellung ermöglicht. Auf diese Weise erhalten Sie eine All-SQL-Lösung, die sich leichter an die IT-Abteilung verkaufen lässt, und Sie benötigen kein Polling auf dem Server. Außerdem müssen Sie sich nicht mit MIME-Parsing befassen, sondern können ganz einfach XML verarbeiten. Es ist jedoch nichts für schwache Nerven, denn SSB zum Laufen zu bringen, ist eine Herausforderung. Wenn Sie sich für die E-Mail-Zustellung entscheiden, ist ein externer Dienst zweifellos einfacher zu erstellen, zu debuggen und Fehler zu beheben. Es gibt einige Detailfragen, auf die Sie eine Antwort haben sollten: -Wie werden Sie die Mail-Dequeue-Operationen und die Tabellen-Schreiboperationen konsistent halten? Ihre Komponente muss die Exchange-Lese-/Löschoperationen und die SQL-Einfügeoperationen in einer verteilten Transaktion zusammenfassen. - Ist Ihre Logik darauf vorbereitet, mit Infopath-Dokumenten umzugehen, die nicht in der richtigen Reihenfolge ankommen? Der Mail-Transport bietet keinerlei Garantie für die Reihenfolge der Zustellung, so dass ein "Order Delete"-Dokument vor einem "Order Create"-Dokument erscheinen kann. - Wie wollen Sie fehlende (nicht per Post zugestellte) Dokumente erkennen? Werden Sie eine Absender-Sequenznummer einführen und damit TCP auf der Mail neu erfinden? - Erlaubt Ihre Verarbeitung eine parallele Verarbeitung von korrelierten Dokumenten? Wenn Thread 1 Dokument 1 und Thread 2 Dokument 2 vom gleichen Absender abholt und Dokument 2 mit Dokument 1 korreliert ist (d.h. sich auf den gleichen Geschäftsvorgang bezieht), was passiert dann beim Schreiben in die Datenbank? Kommt es zu einer Verklemmung, geht eine Aktualisierung verloren, wird ein Rollback durchgeführt?

Es liegen viele Drachen unter der Brücke vor uns...