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

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

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

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

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

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

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

6.08.2008 10:43:16
3 ОТВЕТА
РЕШЕНИЕ

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

3
7.08.2008 18:24:09

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

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

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

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

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

0
6.08.2008 10:53:15

@Vaibhav

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

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

0
6.08.2008 11:03:12