SQL Server 2005で解析される情報パスフォームを（添付ファイルとして）メールで送信しますか？

Question

新しいプロジェクトの要件を見て、このユースケースが適切であることを確認したかった：

• ユーザーがPCでローカルにInfoPath（2003）フォームに入力する
• 「submit」というタイトルのInfoPathフォーム内のボタンは、infopathフォームが添付された新しいOutlook（2003）電子メールメッセージを表示します。ユーザーが送信を押すと、メールが交換メールボックスに送信されます。
• sqlサーバーはこのメールボックスを事前にチェックし、infopathフォームが添付された新しい送信をダウンロードします
• sqlサーバーは、添付ファイルとinfopathフォーム内のフィールドを解析します。

SQL Serverはこの方法でメールの添付ファイルを解析できますか？このアプローチには注意点がありますか？

Outlookを送信テクノロジとして使用する魅力は、ユーザーがオフラインの場合でもユーザーのプロセスが同じであることです。 Outlookは、オンラインに戻ったときに自動的に同期します。ユーザーがフォームをオフラインで入力して「送信」し、次にオンラインになったときにサーバーと自動的に同期する方法があることが不可欠です。

編集：明確にするために、サーバーとクライアントからのフォームデータをキャッシュする方法を探していません。完成したフォームをキャッシュしたいと思っています。完成したレポートをクライアントにキャッシュするために別のアプリケーションを構築することはオプションではありません。

Answer 1

SQL Serverの最新バージョンでは、.NETコードを実行できます。そのため、SQL Serverからメールボックスをポーリングし、InfoPathフォームを処理できる場合があります。ただし、この方法で行うかどうかはわかりません。

この作業を行うWindowsサービスの作成を検討することをお勧めします。 Windowsサービスが起動し、「サービスアカウント」のメールボックスを調べ、メールを読み取り、添付ファイルを抽出し、xmlを処理し、最終的にデータをSQLに書き込みます。また、おそらく、ビジネスルールまたは検証エラーが発生した場合、確認またはエラーでそのメールに応答する可能性があります。

上記のすべてのロジックをSQLに入れたかどうかはわかりません。1つには、アカウントに問題があると思われます（SQLが実行されていたアカウントがExchangeメールボックスにアクセスできる必要があります）アカウント）。

マイレージは異なる場合がありますので、これをプロトタイプ化して最適なものを判断する必要がありますが、「ワークキュー」としてExchangeを使用するコードを維持しようと思います。 SQLとは別に、SQLのテーブルへのデータの書き込みを処理するコードのみを配置します。

Answer 2

上記で説明したアプローチは使用しません。 SQL ServerでExchangeメールボックスを調べるよりも望ましいと思われるアプローチがいくつかあります。主なポイントと重要な要件は、InfoPathフォームがオフラインモードで動作できることです。 「オフラインモード」を思い浮かべます。および「データ転送」プロジェクトの2つの別個の部分としての部分：1）インターネットへの接続が利用可能になるまでフォームとデータをクライアントに保存する必要があります。2）接続が利用可能になると、フォームとデータをサーバーに転送する必要があります。

InfoPathフォームをセットアップして、SQL Serverに直接送信し、Exchange＆quot; middleman＆quot;をバイパスできます。完全に。フォームを設計するときのInfoPathのセットアップは非常に簡単です。1）「データの送信」を有効にします。接続の場合、2）送信オプションを設定します。この記事には、その方法の詳細が記載されています。さらに、SQL Serverへの接続は、この記事。このアプローチの唯一の注意点は、データベーススキーマを変更してサポートする必要がある場合があることです。

別のアプローチは、InfoPathフォームをSQL Server 2005 HTTPエンドポイントに送信することです。 InfoPathクライアントは単なるXMLエディターであり、HTTPエンドポイントは基本的にWebサービスの別の名前です。 HTTPエンドポイントでフォームデータをステージングテーブルに受け取り、そこでデータがXMLとして保存されます。その後、そのステージングエリアからそのデータを解析できます。それでも、オフラインで使用するにはInfoPath接続をセットアップする必要があります。このアプローチの主な注意点は、MicrosoftがSQL Server 2008のHTTPエンドポイントを廃止してWCFを支持することです。

私が提案したいもう1つのアプローチは、WCF自体を使用して、InfoPathクライアントからXMLフォームデータを受信することです。このアプローチでは、設計時にフォームのデータソースをWCF Webサービスに接続し、オフラインで使用するためにフォームを設定する必要があります。

これがあなたにとって有用であり、少なくとも正しい方向に向けられることを願っています。

Answer 3

SSBとメールの配信セマンティクスが保証されているため、クライアントでExpressエディションに頼り、Expressで情報パス（またはアプリデータ）を保存し、Service Brokerを使用してセンターに配信する同様のプロジェクトを見てきました。これにより、ITへの販売が容易なすべてのSQLソリューションが提供され、サーバーでポーリングする必要がなくなります。また、MIME解析を処理する必要はありません。すべて単純なXML処理です。気弱な人向けではありませんが、SSBを立ち上げて実行することは困難です。 メール配信を選択した場合、外部サービスの構築、デバッグ、トラブルシューティングが間違いなく簡単になります。回答が必要な細かい点の問題がいくつかあります。 -メールのデキュー操作とテーブル書き込み操作の一貫性をどのように維持しますか？コンポーネントは、Exchangeの読み取り/削除とSQL挿入を1つの分散トランザクションに関与させる必要があります。 -故障したinfopathドキュメントを処理するためのロジックは準備されていますか？メール転送では、配信の順序についてはまったく保証されないため、「order create」ドキュメントの前に「order delete」ドキュメントが表示される場合があります -不足しているドキュメント（メールで配信されない）をどのように検出しますか？送信者のシーケンス番号を実装し、メールの上にTCPを再発明することになりますか？ -あなたの処理は、相関文書の並列処理を可能にしますか？スレッド1がドキュメント1を取得し、スレッド2が同じ送信者からドキュメント2を取得し、ドキュメント2がドキュメント1と関連付けられている（つまり、同じビジネストランザクションを参照している）場合、データベースの書き込みはどうなりますか？デッドロックしますか、更新を失いますか、ロールバックしますか？

前の橋の下には多くのドラゴンがいます...