Déclencheurs d'événements basés sur une minuterie

Question

Je travaille actuellement sur un projet avec des exigences spécifiques.Un bref aperçu de ceux-ci est le suivant :

• Les données sont récupérées à partir de services Web externes
• Les données sont stockées dans SQL 2005
• Les données sont manipulées via une interface graphique Web
• Le service Windows qui communique avec les services web n'a aucun couplage avec notre UI web interne, sauf via la base de données.
• La communication avec les services Web doit être à la fois temporelle et déclenchée via l'intervention de l'utilisateur sur l'interface utilisateur Web.

Le modèle actuel (pré-pré-production) pour le déclenchement de la communication du service Web s'effectue via une table de base de données qui stocke les demandes de déclenchement générées par l'intervention manuelle.Je ne veux pas vraiment avoir plusieurs mécanismes de déclenchement, mais j'aimerais pouvoir remplir la table de base de données avec des déclencheurs en fonction de l'heure de l'appel.À mon avis, il existe deux façons d'y parvenir.

1) Adaptez la table de déclenchement pour stocker deux paramètres supplémentaires.L'un étant "Est-ce basé sur le temps ou ajouté manuellement?" et un champ nul pour stocker les détails temporels (format exact à déterminer).S'il s'agit d'un déclencheur créé manuellement, marquez-le comme traité lorsque le déclencheur a été déclenché, mais pas s'il s'agit d'un déclencheur temporisé.
ou
2) Créez un deuxième service Windows qui crée les déclencheurs à la volée à intervalles réguliers.

La deuxième option me semble une farce, mais la gestion de l'option 1 pourrait facilement se transformer en un cauchemar de programmation (comment savoir si le dernier sondage de la table a renvoyé l'événement qui doit se déclencher, et comment l'arrêter ensuite redéclenchement au prochain sondage)

J'apprécierais que quelqu'un puisse consacrer quelques minutes pour m'aider à décider quel itinéraire (l'un de ces deux, ou éventuellement un troisième, non répertorié) emprunter.

Answer 1

Pourquoi ne pas utiliser un Job SQL au lieu du Service Windows ?Vous pouvez encapsuler tout votre code "déclencheur" de base de données dans des procédures stockées.Ensuite, votre interface utilisateur et votre travail SQL peuvent appeler les mêmes procédures stockées et créer les déclencheurs de la même manière, que ce soit manuellement ou à intervalle de temps.

Answer 2

La façon dont je le vois est la suivante.

Vous disposez d'un service Windows, qui joue le rôle d'un planificateur et contient des classes qui appellent simplement les services Web et mettent les données dans vos bases de données.

Ainsi, vous pouvez également utiliser ces classes directement à partir du WebUI et importer les données en fonction du déclencheur WebUI.

Je n'aime pas l'idée de stocker une action générée par l'utilisateur sous forme d'indicateur (déclencheur) dans la base de données où un service l'interrogera (à un intervalle qui n'est pas sous le contrôle de l'utilisateur) pour exécuter cette action.

Vous pouvez même convertir l'intégralité du code en un exe que vous pourrez ensuite planifier à l'aide du planificateur Windows.Et appelez le même exe chaque fois que l’utilisateur déclenche l’action depuis l’interface utilisateur Web.

Answer 3

@Vaibhav

Malheureusement, l'architecture physique de la solution ne permettra aucune communication directe entre les composants, autres que Web UI vers Base de données, et base de données vers service (qui pourra alors faire appel aux services web).Je suis cependant d'accord que la réutilisation des cours de communication serait ici l'idéal - je ne peux tout simplement pas le faire dans les limites de notre entreprise*

*N'est-il pas toujours vrai qu'une solution techniquement « meilleure » est entravée par des facteurs externes ?