management - sql server agent configuration
Desencadenantes de eventos basados en temporizador (3)
@Vaibhav
Desafortunadamente, la arquitectura física de la solución no permitirá ninguna comunicación directa entre los componentes, aparte de la IU web a la base de datos, y la base de datos para el servicio (que luego puede llamar a los servicios web). Sin embargo, sí estoy de acuerdo en que la reutilización de las clases de comunicación sería lo ideal aquí; simplemente no puedo hacerlo dentro de los límites de nuestro negocio *
* ¿No es siempre la forma en que una solución técnicamente "mejor" se ve obstaculizada por factores externos?
Actualmente estoy trabajando en un proyecto con requisitos específicos. Una breve descripción de estos son los siguientes:
- 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 UI web interna, excepto a través de la base de datos.
- La comunicación con los servicios web debe basarse tanto en el tiempo como en la intervención del usuario en la interfaz de usuario web.
El modelo actual (prepreproducción) para la activación de la comunicación del servicio 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 desencadenadores según la hora de la llamada. Como lo veo, hay dos formas de lograr esto.
1) Adapte la tabla de disparadores para almacenar dos parámetros adicionales. Uno de ellos es "¿Está basado en el tiempo o agregado manualmente?" y un campo anulable para almacenar los detalles de tiempo (se debe determinar el formato exacto). Si se trata de un desencadenador creado por manaul, márquelo como procesado cuando se disparó el desencadenador, pero no si se trata de un desencadenador temporizado.
o
2) Cree un segundo servicio de Windows que cree los desencadenantes sobre la marcha en intervalos de tiempo.
La segunda opción me parece un insulto, pero la administración de la opción 1 podría convertirse fácilmente en una pesadilla de programación (¿cómo se puede saber si la última encuesta de la tabla arrojó el evento que debe disparar y cómo se puede detener? reactivación en la próxima encuesta)
Agradecería que alguien pudiera dedicar unos minutos para ayudarme a decidir qué ruta tomar (una de estas dos, o posiblemente una tercera, no incluida en la lista).
La forma en que lo veo es esto.
Usted tiene un Servicio de Windows, que desempeña el papel de un 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, puede usar estas clases directamente desde WebUI e importar los datos en función del desencadenador WebUI.
No me gusta la idea de almacenar una acción generada por el usuario como un indicador (disparador) en la base de datos donde algún servicio la interrogará (en un intervalo que no está bajo el control del usuario) para ejecutar esa acción.
Incluso podría convertir todo el código en un archivo ejecutable que luego puede programar con el Programador de Windows. Y llame al mismo exe siempre que el usuario active la acción desde la IU web.
¿Por qué no utilizar un trabajo SQL en lugar del servicio de Windows? Puede encapsular todo el código de "activación" de DB en Procedimientos almacenados. Luego, su UI y SQL Job pueden llamar a los mismos Procedimientos almacenados y crear los desencadenantes de la misma manera, ya sea manualmente o en un intervalo de tiempo.