C'est possible, mais dans le monde réel, c'est un peu plus compliqué que l'approche naïve que vous envisagez. En premier lieu, il est inacceptable qu'un déclencheur attende une requête HTTP :
- D'une part, votre application s'arrêtera brusquement, car les déclencheurs bloqueront les ressources (principalement les verrous) en attente d'une réponse d'un service WWW éloigné.
- Deuxièmement, plus subtil mais bien pire, est la question de l'exactitude en présence de retours en arrière. Si la transaction émise pour les requêtes HTTP est annulée, il n'y a aucun moyen d'"annuler" la requête HTTP.
La solution consiste à découpler le déclencheur de la requête HTTP via une file d'attente. Le déclencheur met la requête en file d'attente dans une file d'attente locale et la valide, tandis qu'un élément de traitement distinct retire ces requêtes de la file d'attente et émet la requête HTTP. Cela résout les deux problèmes signalés ci-dessus. Vous pouvez utiliser des tables ordinaires pour les files d'attente (voir Utilisation de tables comme files d'attente) ou vous pouvez utiliser Service Broker, les deux fonctionnent bien.
Maintenant, sur la façon de retirer ces demandes et de passer l'appel HTTP, je recommande fortement d'utiliser un processus dédié (c'est-à-dire une application dédiée à cet effet). Bien qu'il soit possible d'utiliser SQLCLR, c'est un très mauvais choix. Les ressources SQL Server (en particulier les travailleurs) sont bien trop précieuses pour être gaspillées en attendant les réponses Internet.
