Възможно е, но в реалния свят е малко по-сложно от наивния подход, който си представяте. Предимно е неприемливо тригерът да чака за HTTP заявка:
- От една страна, приложението ви ще пълзи до рязко спиране, защото тригерите ще блокират ресурси (предимно заключвания), чакащи отговор от някоя далечна WWW услуга.
- Вторият, по-фин, но далеч по-лош, е въпросът за коректността при наличие на връщане назад. Ако транзакцията, издадена към HTTP заявките, се върне назад, няма начин да „отмените“ HTTP заявката.
Решението е да отделите тригера от HTTP заявката чрез опашка. Тригерът поставя заявката в опашка в локална опашка и извършва ангажименти, докато отделна част от обработката изключва тези заявки и издава HTTP заявката. Това решава и двата проблема, посочени по-горе. Можете да използвате обикновени таблици за опашки (вижте Използване на таблици като опашки) или можете да използвате Service Broker, и двете работят добре.
Сега относно това как да извадите тези заявки от опашката и всъщност да поставите HTTP повикването, силно препоръчвам да използвате специален процес (т.е. приложение, предназначено за тази цел). Въпреки че е възможно да се използва SQLCLR, това е много лош избор. Ресурсите на SQL Server (по-специално работниците) са много ценни, за да ги губите в чакане на интернет отговори.
