Es ist möglich, aber in der realen Welt ist es ein bisschen komplizierter als der naive Ansatz, den Sie sich vorstellen. In erster Linie ist es nicht akzeptabel, einen Trigger auf eine HTTP-Anfrage warten zu lassen:
- Zum einen wird Ihre Anwendung mit Vollbremsung zum Stillstand kommen, da Trigger Ressourcen (hauptsächlich Sperren) blockieren, die auf eine Antwort von einem weit entfernten WWW-Dienst warten.
- Zweitens, subtiler, aber viel schlimmer, ist das Problem der Korrektheit bei Rollbacks. Wenn die Transaktion, die HTTP-Anforderungen ausgegeben hat, zurückgesetzt wird, gibt es keine Möglichkeit, die HTTP-Anforderung rückgängig zu machen.
Die Lösung besteht darin, den Trigger über eine Warteschlange vom HTTP-Request zu entkoppeln. Der Trigger reiht die Anforderung in eine lokale Warteschlange ein und schreibt sie fest, während ein separater Verarbeitungsteil diese Anforderungen aus der Warteschlange entfernt und die HTTP-Anforderung ausgibt. Dies löst beide oben aufgezeigten Probleme. Sie können gewöhnliche Tabellen für Warteschlangen verwenden (siehe Verwenden von Tabellen als Warteschlangen) oder Sie können Service Broker verwenden, beides funktioniert gut.
Nun, wie Sie diese Anfragen aus der Warteschlange entfernen und den HTTP-Aufruf tatsächlich platzieren, empfehle ich dringend, einen dedizierten Prozess zu verwenden (dh eine Anwendung, die für diesen Zweck dediziert ist). Obwohl es möglich ist, SQLCLR zu verwenden, ist es eine sehr schlechte Wahl. SQL Server-Ressourcen (insbesondere Worker) sind viel zu kostbar, um sie mit dem Warten auf Antworten aus dem Internet zu verschwenden.
