Основанные на таймере триггеры событий

Question

Я сейчас работаю над проектом с особыми требованиями. Краткий обзор этого:

• Данные извлекаются из внешних веб-сервисов
• Данные хранятся в SQL 2005
• Данные обрабатываются через веб-интерфейс
• Служба Windows, которая взаимодействует с веб-службами, не связана с нашим внутренним веб-интерфейсом, кроме как через базу данных.
• Связь с веб-службами должна быть основана на времени и инициироваться с помощью вмешательства пользователя в веб-интерфейсе пользователя.

Текущая (предпроизводственная) модель для запуска связи через веб-сервис осуществляется через таблицу базы данных, в которой хранятся запросы на запуск, сгенерированные из ручного вмешательства. Я действительно не хочу иметь несколько механизмов триггера, но хотел бы иметь возможность заполнять таблицу базы данных триггерами, основанными на времени вызова. На мой взгляд, есть два способа сделать это.

1) Адаптируйте таблицу триггеров для хранения двух дополнительных параметров. Один из них "Это основано на времени или добавлено вручную?" и обнуляемое поле для хранения временных данных (точный формат должен быть определен). Если это триггер, созданный вручную, пометьте его как обработанный при срабатывании триггера, но не если это синхронизированный триггер.
или
2) Создайте вторую службу Windows, которая создает триггеры на лету через определенные интервалы времени.

Второй вариант мне кажется выдумкой, но управление вариантом 1 может легко превратиться в кошмар программирования (откуда вы знаете, если последний опрос таблицы возвратил событие, которое нужно запустить, и как вы затем остановите его повторно при следующем опросе)

Я был бы признателен, если бы кто-нибудь мог выделить несколько минут, чтобы помочь мне решить, какой маршрут (один из этих двух или, возможно, третий, не включенный в список) выбрать.

Answer 1

Почему бы не использовать задание SQL вместо службы Windows? Вы можете инкапсулировать код «триггера» БД в хранимых процедурах. Тогда ваш пользовательский интерфейс и задание SQL могут вызывать одни и те же хранимые процедуры и создавать триггеры одинаково, будь то вручную или через определенный промежуток времени.

Answer 2

@ Vaibhav

К сожалению, физическая архитектура решения не позволяет осуществлять прямую связь между компонентами, кроме веб-интерфейса пользователя к базе данных, и базы данных к сервису (который затем может обращаться к веб-сервисам). Я, однако, согласен, что повторное использование классов общения было бы идеальным здесь - я просто не могу сделать это в рамках нашего бизнеса *

* Не всегда ли технически «лучшее» решение блокируется внешними факторами?

Answer 3

Я вижу это так.

У вас есть служба Windows, которая играет роль планировщика, и в ней есть несколько классов, которые просто вызывают веб-сервисы и помещают данные в ваши базы данных.

Таким образом, вы также можете использовать эти классы непосредственно из WebUI и импортировать данные на основе триггера WebUI.

Мне не нравится идея сохранения сгенерированного пользователем действия в виде флага (триггера) в базе данных, где какая-либо служба будет опрашивать его (с интервалом, который не находится под контролем пользователя), чтобы выполнить это действие. *

Вы можете даже преобразовать весь код в исполняемый файл, который затем можно запланировать с помощью планировщика Windows. И вызывать один и тот же исполняемый файл всякий раз, когда пользователь запускает действие из веб-интерфейса.