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

В настоящее время я работаю над проектом с особыми требованиями. Ниже приводится их краткий обзор:

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

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

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

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

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

Ответов (3)

Решение

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

@Vaibhav

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

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

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

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

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

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

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