Вставка сообщения Rebus в SQL Server с помощью T-SQL

Я хотел бы использовать Rebus для интеграции со сторонним приложением, добавив триггеры в базу данных этого приложения, чтобы триггеры вставляли записи в формате сообщения Rebus, содержащие информацию об изменениях в базе данных (тип операции: вставка, обновление, удаление, имя таблицы и идентификатор строки). Скажите, пожалуйста, есть ли способ сделать это легко, или мне нужно будет создать хранимую процедуру самостоятельно, заглянув в https://github.com/rebus-org/Rebus/blob/master/src/Rebus/Transports/Sql/SqlServerMessageQueue.cs Метод отправки?

В качестве альтернативы я мог бы просто запустить exe с параметрами из триггера, но это не транзакционный.

Также я видел эту проблему https://github.com/rebus-org/Rebus/issues/119, но я думаю, что это мертвая идея.

Может быть, есть другой рекомендуемый подход?

Обновление: я только что понял, что тело сообщения Rebus сериализовано, поэтому было бы безумием делать это в SQL (и даже невозможно без SQL-CLR), поэтому, возможно, единственный способ — создать собственный транспорт с помощью Метод ReceiveMessage принимает сообщения в моем собственном формате?

Заранее спасибо :)


rebus
person user1121956    schedule 21.10.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

У меня были отличные результаты интеграции с тем, что «происходит в SQL Server», с помощью SQL Server Service Broker — не напрямую (т. е. как реализация транспорта Rebus), а как очередь сообщений, которую я мог опрашивать извне.

Всякий раз, когда в базе данных происходило что-то интересное, триггер запрашивал некоторые таблицы и выбирал набор результатов for xml auto в XML-сообщение, которое будет отправлено в очередь брокера служб.

Затем у меня была конечная точка Rebus с System.Timers.Timer, которая опрашивала очередь брокера, и bus.SendLocal полученный XML в виде строки — таким образом, все, от синтаксического анализа XML и так далее, будет основано на сообщениях Rebus, повторных попытках и очередях ошибок, а также на обычном дальше надежность :)

person mookid8000    schedule 21.10.2014
comment
классная идея :) как выглядит этот xml для обновления и удаления? Я имею в виду, что в случае вставки у вас действительно есть новые данные для выбора, но в случае обновления будет ли это просто разница с исходным состоянием, а в случае удаления только информация о том, что удаление произошло? - person user1121956; 22.10.2014
comment
Данные были транзакциями, связанными с торговлей, поэтому они никогда не удалялись, и мы просто использовали поле статуса, чтобы указать, были ли они отменены. Вставки/обновления обрабатывались таким же образом, поэтому мы в основном делали полное обновление каждый раз, когда что-то менялось. - person mookid8000; 22.10.2014
comment
Мне интересно, почему вы решили использовать Timer вместо создания транспорта, как вы описали в выпуске 119? - person user1121956; 24.10.2014
comment
Подумав об этом и обнаружив, что ребус может использовать разные сериализаторы, я думаю, что мог бы использовать обычный транспорт sql, поскольку моя пропускная способность низкая, поэтому этого должно быть достаточно. Мне просто нужно добавить сериализатор xml в ребус и использовать его, чтобы позволить БД создавать сообщения. Звучит разумно? :) - person user1121956; 24.10.2014
comment
Я выбрал System.Timers.Timer, потому что мне просто нужно было опросить БД на наличие новых сообщений брокера, и я знаю, сколько работы уходит на создание полноценного транспорта Rebus ;) - person mookid8000; 24.10.2014
comment
Нет, серьезно - делать вид, что мой коннектор брокера был настоящим транспортом Ребуса, было бы неправильно, потому что либо а) мне пришлось бы приложить много усилий, чтобы сделать его настоящим транспортом, либо б) он не был бы способен работать как реальный транспорт - person mookid8000; 24.10.2014
comment
#119 был посвящен созданию полноценного транспорта, но в моем случае характер проблемы был скорее проблемой интеграции - person mookid8000; 24.10.2014
comment
Кроме того, оказалось, что сервис-брокер заставляет вас иметь очередь отправителя и получателя, а затем - когда / если возникает ошибка, например. при отправке сообщений, которые не являются XML и т. д., сообщение помещается в очередь отправителя. Другими словами, будет лучше, если вы также будете периодически качать эту очередь отправителя для сообщений об ошибках в дополнение к получению реальных сообщений. - person mookid8000; 24.10.2014
comment
Что касается вашего плана использования SQL Server и сериализатора XML - это, вероятно, будет работать нормально :) не мой предпочтительный подход, но я почти всегда использую MSMQ в качестве транспорта, поэтому я рассматриваю все взаимодействия с другими видами транспорта как сценарий интеграции. - person mookid8000; 24.10.2014
comment
спасибо за еще один отличный вклад :) Просто чтобы оправдать свое решение, я хочу избежать кривой обучения и потенциальных проблем SB. Опрос вручную и SendLocal из таблицы были бы более интегрированными, но поскольку транспорт sql делает это за меня, кажется разумным использовать его :) - person user1121956; 24.10.2014