トリガーの実行時に外部URLに情報をPOST （HTTPメソッド）する必要があります。トリガーを使用すると、セキュリティとパフォーマンスに多くの影響があることを知っているので、この種の処理を行う場所ではないのではないかと思います。しかしとにかく、私はこれを投稿して、問題への取り組み方に関するフィードバックやアイデアを得ています。いくつかの考慮事項：
この実行を実際にトリガーするのは、テーブルへの1つのレコードの挿入または更新である必要があります。したがって、（サードパーティの）アプリケーションに触れることができないため、このトリガーを使用する必要があります。
ちなみに、サービスブローカーは考慮すべきものでしょうか？どんなアイデアでも大歓迎です。
そうです、これはトリガーでやりたいことではありません。アプリケーションで最も避けたいことは、すべての更新/挿入/削除で HTTP リクエストのレイテンシーを導入することです。これは、うまく機能している場合でも非常に目に見えるものです。しかし、物事がうまくいかない場合、それは非常にうまく機能しません: HTTP リソースに可用性の問題がある場合、カップリングが追加されるとアプリケーションが失敗し、さらに悪いことに、ロールバックに関連する正確性の問題が発生します (トリガーを実行したトランザクションはロールバックする可能性がありますが、 HTTP 呼び出しは既に行われています)。
これが、トリガーを HTTP 呼び出しから分離するレイヤーを導入することが最も重要である理由であり、これはキューを介して行われます。テーブルをキューとして使用するか、Service Broker キューとして使用するか、または MSMQ キューとして使用するかは、呼び出しを行うユーザー次第です。最も簡単な解決策は、テーブルをキューとして使用することです。
カスタム キューとしてのテーブルに対する Service Broker の利点は、内部アクティベーションです。これにより、キューに処理するアイテムがある場合に、ポーリングではなく、HTTP 処理コードをオンデマンドで実行できます。しかし、SQLCLR を介してエンジン内から HTTP 呼び出しを行うことは、あまりお勧めできません。HTTP のようなものにアクセスするには、外部プロセスの方がはるかに優れているため、Service Broker の追加の複雑さは保証されません。