Det är möjligt, men i den verkliga världen är det lite mer komplicerat än det naiva tillvägagångssätt du föreställer dig. I första hand är det oacceptabelt att en trigger väntar på en HTTP-begäran:
- För det första kommer din applikation att krypa till ett skrikande stopp, eftersom utlösare kommer att blockera resurser (främst låsningar) som väntar på ett svar från någon fjärranvänd WWW-tjänst.
- För det andra, mer subtil men mycket värre, är frågan om korrekthet i närvaro av återställningar. Om transaktionen som skickades till HTTP-begäranden återgår, finns det inget sätt att "ångra" HTTP-begäran.
Lösningen är att frikoppla triggern från HTTP-förfrågan via en kö. Utlösaren ställer begäran i en lokal kö och begår, medan en separat del av bearbetning köar dessa förfrågningar och utfärdar HTTP-begäran. Detta löser båda problemen som påpekats ovan. Du kan använda vanliga tabeller för köer (se Använda tabeller som köer) eller så kan du använda Service Broker, båda fungerar bra.
Nu när det gäller hur man ställer dessa förfrågningar i kö och faktiskt gör HTTP-anropet, rekommenderar jag starkt att du använder en dedikerad process (dvs. en applikation dedikerad för detta ändamål). Även om det är möjligt att använda SQLCLR, är det ett mycket dåligt val. SQL Server-resurser (särskilt arbetare) är alldeles för värdefulla att slösa på att vänta på internetsvar.