Может ли SQL Server отправить веб-запрос?

У меня есть база данных SQL Server и веб-приложение интрасети в локальной сети. Веб-приложение интрасети создает записи и отправляет их в базу данных. У меня есть веб-приложение в Интернете, которое я бы хотел отправить новые записи для использования базы данных SQL Server в локальной сети.

Я не могу изменить/изменить веб-приложение интрасети по разным причинам, поэтому единственный вариант, который у меня есть, - создать триггер на локальном SQL Server, который будет отправлять новые записи в интернет-приложение Интернета, используя какой-то запрос на отправку по почте или URL-адрес.

Веб-приложение INTERNET настроено с помощью RESTful api, который может получать новые записи через сообщение формы публично доступному URL-адресу (например, http://www.example.com/records/new).

Кто-нибудь знает, может ли передача данных (xml, json, plain variables в url) через URL-адрес в SQL Server?

Спасибо за любые мысли!

Ответы

Ответ 1

Возможно, но в реальном мире немного сложнее, чем наивный подход, который вы себе представляете. Прежде всего, недопустимо ожидать триггерного запроса HTTP-запроса:

  • Во-первых, ваше приложение будет сканироваться до зависания, потому что триггеры будут блокировать ресурсы (в основном блокировки), ожидающие ответа от какой-либо отдаленной WWW-службы.
  • Во-вторых, более тонкая, но намного хуже, проблема правильности при наличии откатов. Если транзакция, которая выдала HTTP-запросы, откатывается, нет способа "отменить" HTTP-запрос.

Решение состоит в том, чтобы отделить триггер от HTTP-запроса через очередь. Триггер помещает запрос в локальную очередь и совершает транзакцию, в то время как отдельная часть обработки отменяет эти запросы и выдает запрос HTTP. Это решает обе проблемы, указанные выше. Вы можете использовать обычные таблицы для очередей (см. Использование таблиц в качестве очередей), или вы можете использовать Service Broker, оба хорошо работайте.

Теперь о том, как удалить эти запросы и фактически разместить HTTP-вызов, я настоятельно рекомендую использовать выделенный процесс (то есть приложение, предназначенное для этой цели). Хотя можно использовать SQLCLR, это очень плохой выбор. Ресурсы SQL Server (в частности, рабочие) до сих пор ценны, чтобы тратить деньги на ожидание ответов в Интернете.

Ответ 2

Как хороший (достаточно надежный и масштабируемый) вариант, вы можете использовать SQL CLR для взаимодействия с веб-приложением/веб-службой.

Например, SQL CLR WebRequest или SQL CLR WCF.

Ответ 3

Чтобы добавить к хорошему ответу Ремуса Русану. И связано с комментарием Легия Санчеса. Проблема в том, что вам всегда нужно ждать HTTP-запроса. Код в триггере является пошаговым исполнением, поэтому запрос должен вернуться, чтобы триггер мог завершить свое выполнение.