MSSQLトリガーでPOSTメソッドを使用します。

Question

私はPOSTが必要です。（HTTPメソッド）トリガーが実行されるときに外部URLにいくつかの情報があります。 トリガーを使用すると、セキュリティとパフォーマンスに多くの影響があることがわかります。この種の処理を行う場所ではないのではないかと心配しています。しかし、とにかく私はこれを投稿して、問題に近づく方法に関するフィードバックやアイデアを得る。いくつかの考慮事項：

• トリガーで起動されたトランザクションは、非同期である可能性があります。
• プロセスは承認を得なければなりません
• エンドURLはインターネット上のPHPスクリプトです。

本当にこの実行をトリガーするのは、テーブルへのレコードの挿入または更新である必要があります。したがって、（第三者の）アプリケーションに触れることができないため、このトリガーを使用する必要があります。

サービスブローカーはお考えですか？ アイデアは大歓迎です。

Answer 1

あなたは正しいです、これはあなたがトリガでしたいことではありません。アプリケーションで最後に望むのは、更新/挿入/削除のたびにHTTPリクエストの待ち時間を導入することです。状況がうまくいっていても非常に目に見えます。しかし、状況が悪ければ、それは動作します非常に悪い：追加されたカップリングは、HTTPリソースが可用性の問題を抱えているときにアプリケーションを失敗させ、ロールバックに関連する正確性の問題がさらに悪化しますHTTP呼び出しは既に行われています）。

これは、トリガーをHTTP呼び出しから切り離すレイヤーを導入するために重要なことです。これはキューを介して行われます。キューとして使用されるテーブル、Service Brokerキュー、MSMQキューのいずれを使用するかは、呼び出しに応じて異なります。最も簡単な解決策はuse a table as a queueにある：

• トリガエンキュー（挿入）が行われるHTTP呼び出しの要求
• トリガーを実行するトランザクションがコミットした後、要求が
• ANをデキューするために利用され（ポーリング）を監視し、外部アプリケーションキューが要求をピックアップし、HTTP呼び出し

を置くカスタムテーブル-AS-キューオーバーのService Brokerの利点がオンに実行するために、あなたのHTTP処理コードを可能にするInternal Activation、あります要求wェントリには、ポーリングの代わりにキュー内で処理される項目があります。しかし、SQLCLRを介してエンジンの内部からHTTPコールを発信することは、かなり不都合なことです。外部プロセスはHTTPのようなものにアクセスする方がはるかに優れているため、Service Brokerの複雑さは保証されません。