2

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

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

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

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

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

4

3 に答える 3

2

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

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

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

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

于 2009-05-12T15:53:44.967 に答える
2

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

InfoPath フォームをセットアップして、SQL Server に直接送信し、Exchange の「仲介者」を完全にバイパスすることができます。フォームをデザインするときの InfoPath でのセットアップは非常に簡単です。1) 接続の [データの送信] を有効にし、2) 送信オプションを構成します。この記事には、その方法の詳細が記載されています。さらに、この記事で説明されているように、SQL Server への接続がオフラインで使用できるように設定されている場合があります。このアプローチの唯一の注意点は、それをサポートするためにデータベース スキーマを変更する必要がある場合があることです。

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

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

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

于 2009-05-11T04:21:12.643 に答える
0

SSB とメールの配信セマンティクスが保証されているため、クライアントで Express エディションに頼り、infopath (またはアプリ データ) を Express に保存し、Service Broker を使用してセンターに配信する同様のプロジェクトを見てきました。これにより、すべての SQL ソリューションを IT 部門に販売しやすくなり、サーバーでのポーリングは不要になります。また、MIME 解析を扱う必要はなく、すべて単純な XML 処理です。ただし、気弱な人向けではありませんが、SSB を起動して実行するのは困難です。メール配信を利用する場合は、外部サービスの方が構築、デバッグ、およびトラブルシューティングが容易になることはほぼ間違いありません。あなたが答えなければならないいくつかのより細かい点の問題があります：-メールのデキュー操作とテーブル書き込み操作の一貫性をどのように維持しますか? コンポーネントは、Exchange の読み取り/削除と SQL の挿入を 1 つの分散トランザクションに組み込む必要があります。- ロジックは、順不同になってくる InfoPath ドキュメントに対処する準備ができていますか? メール トランスポートは配送の順序についてまったく保証しないため、「注文の作成」ドキュメントの前に「注文の削除」ドキュメントが表示される場合があります - 紛失したドキュメント (メールで配信されない) をどのように検出しますか 送信者シーケンス番号を実装して、メールに加えて TCP を再発明するつもりですか? - あなたの処理は、相関文書の並列処理を可能にしますか? スレッド 1 がドキュメント 1 を取得し、スレッド 2 がドキュメント 2 を同じ送信者から取得し、ドキュメント 2 がドキュメント 1 と関連付けられている (つまり、同じビジネス トランザクションを参照している) 場合、データベースの書き込み時に何が起こるか? デッドロックになるか、アップデートが失われるか、ロールバックされるか?

この先の橋の下にはドラゴンがたくさん…

于 2009-05-17T20:32:52.010 に答える