Activadores de eventos basados ​​en temporizador

Question

Actualmente estoy trabajando en un proyecto con requisitos específicos.Una breve descripción de estos es la siguiente:

• Los datos se recuperan de servicios web externos.
• Los datos se almacenan en SQL 2005.
• Los datos se manipulan a través de una GUI web.
• El servicio de Windows que se comunica con los servicios web no tiene acoplamiento con nuestra interfaz de usuario web interna, excepto a través de la base de datos.
• La comunicación con los servicios web debe basarse en el tiempo y activarse mediante la intervención del usuario en la interfaz de usuario web.

El modelo actual (prepreproducción) para la activación de la comunicación de servicios web se realiza a través de una tabla de base de datos que almacena las solicitudes de activación generadas a partir de la intervención manual.Realmente no quiero tener múltiples mecanismos de activación, pero me gustaría poder completar la tabla de la base de datos con activadores según el momento de la llamada.A mi modo de ver, hay dos formas de lograr esto.

1) Adapte la tabla de activación para almacenar dos parámetros adicionales.Un ser "¿Está basado en el tiempo o se agrega manualmente?" y un campo anulable para almacenar los detalles de tiempo (formato exacto a determinar).Si se trata de un disparador creado manualmente, márquelo como procesado cuando se haya activado el disparador, pero no si es un disparador cronometrado.
o
2) Cree un segundo servicio de Windows que cree los activadores sobre la marcha a intervalos de tiempo.

La segunda opción me parece una chapuza, pero la gestión de la opción 1 podría convertirse fácilmente en una pesadilla de programación (¿cómo saber si la última encuesta de la tabla arrojó el evento que debe activarse y cómo detenerlo? reactivación en la próxima encuesta)

Le agradecería que alguien pudiera dedicar unos minutos para ayudarme a decidir qué ruta (una de estas dos, o posiblemente una tercera, que no figura en la lista) tomar.

Answer 1

¿Por qué no utilizar un trabajo SQL en lugar del servicio de Windows?Puede encapsular todo el código "activador" de su base de datos en Procedimientos almacenados.Luego, su UI y su trabajo SQL pueden llamar a los mismos procedimientos almacenados y crear los activadores de la misma manera, ya sea manualmente o en un intervalo de tiempo.

Answer 2

La forma en que lo veo es esta.

Tiene un servicio de Windows, que desempeña el papel de programador y en él hay algunas clases que simplemente llaman a los servicios web y colocan los datos en sus bases de datos.

Por lo tanto, también puede usar estas clases directamente desde WebUI e importar los datos según el activador de WebUI.

No me gusta la idea de almacenar una acción generada por el usuario como un indicador (activador) en la base de datos donde algún servicio la sondeará (en un intervalo que no está bajo el control del usuario) para ejecutar esa acción.

Incluso podría convertir el código completo en un archivo ejecutable que luego podrá programar utilizando el Programador de Windows.Y llame al mismo exe cada vez que el usuario active la acción desde la interfaz de usuario web.

Answer 3

@vaibhav

Desafortunadamente, la arquitectura física de la solución no permitirá ninguna comunicación directa entre los componentes, aparte de la interfaz de usuario web con la base de datos y la base de datos con el servicio (que luego puede llamar a los servicios web).Sin embargo, estoy de acuerdo en que lo ideal sería reutilizar las clases de comunicación; simplemente no puedo hacerlo dentro de los límites de nuestro negocio*

*¿No es siempre así que una solución técnicamente "mejor" se ve obstaculizada por factores externos?