С помощью технологии push сложно сделать транзакцию.
Единственный транзакционный вариант для этого - использовать мост WCF, и он требует, в свою очередь, использования SQL Server 2008, так как с 2012 года динамическая фоновая компиляция сборок на основе WSDL блокируется CLR, размещенной на SQL Server, и я никогда не разбирался, как принудительно компилировать эти сборки таким образом, чтобы избежать ссылок на сборки, запрещенные политиками CLR.
Единственный выбор, который я нашел работающим (возможно, из-за того, что я не смог найти обходной путь), - это использование сетевого клиента в стиле HttpClient RESTFull с интегрированной процедурой CLR, работающей от процедуры SQL Server Broker Activated. Он работает очень хорошо только с одной проблемой, RESTFull не поддерживает транзакционные из коробки. Таким образом, если вам нужна гарантированная доставка сообщения, вам понадобится контрольный звонок где-то в потоке сообщений.
Фактически для защиты целостности операций MSMQ я вставил транзакционную службу WCF между моим RESTFull и MSMQ, а в MSMQ использовал триггер, который, в свою очередь, управляет обработкой транзакционных данных на основе политик. Обратите внимание, что триггер MSMQ требует установки функции триггера MSMQ. Я выбрал триггер на основе exe, поскольку альтернативным подходом является использование DLL на основе COM, и я не чувствовал, что использую COM, так как свободная многопоточная DLL требует реализации сложного приложения C ++ и многоуровневой обработки, что относительно легко спроектировать в C # с CCW , накладывает ограничение на масштаб приложения. В конце концов, вызов RESTFull можно рассматривать как «почти транзакционный», поскольку он выполняется в контексте транзакции, и если у вас нет какой-либо серьезной ошибки, например, пропущения, чтобы перехватить условие ошибки (в основном, пропустить реализацию try / catch) и throw, когда требуется поднять условие ошибки, вы получите надежную фиксацию / откат. Однако для обеспечения надежности доставки сообщений желательно иметь подкрепление проверочным вызовом и разумным временем ожидания, когда пропущенные данные считаются равными отсутствию фиксации.