sql - Minuteur

Translate

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

  • 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 interface utilisateur Web interne, sauf via la base de données.
  • La communication avec les services Web doit être à la fois basée sur le temps et déclenchée via une intervention de l'utilisateur sur l'interface utilisateur Web.

Le modèle actuel (pré-pré-production) pour le déclenchement de communication de service Web se fait via une table de base de données qui stocke les demandes de déclenchement générées à partir de l'intervention manuelle. Je ne veux pas vraiment avoir plusieurs mécanismes de déclenchement, mais j'aimerais pouvoir remplir la table de la base de données avec des déclencheurs basés sur l'heure de l'appel. Selon moi, il y a 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 Nullable pour stocker les détails de synchronisation (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 chronométré.
or
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 être un fudge, mais la gestion de l'option 1 pourrait facilement se transformer en cauchemar de programmation (comment savoir si le dernier sondage de la table a renvoyé l'événement qui doit être déclenché, et comment l'arrêter ensuite re-déclenchement au prochain sondage)

J'apprécierais si quelqu'un pouvait consacrer quelques minutes pour m'aider à décider quelle route (l'une de ces deux, ou peut-être une troisième, non répertoriée) à prendre.

This question and all comments follow the "Attribution Required."

Toutes les réponses

Translate

Pourquoi ne pas utiliser un travail SQL au lieu du service Windows? Vous pouvez encapsuler tout votre code de «déclenchement» de base de données dans les 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 à un intervalle de temps.

La source
Translate

La façon dont je vois les choses est la suivante.

Vous avez un service Windows, qui joue le rôle d'un planificateur et il 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 de l'interface utilisateur Web 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 comme 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 tout le code en un exe que vous pouvez ensuite planifier à l'aide du planificateur Windows. Et appelez le même exe chaque fois que l'utilisateur déclenche l'action à partir de l'interface utilisateur Web.

La source
Translate

@Vaibhav

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

* N'est-ce pas toujours ainsi qu'une solution techniquement «meilleure» est contrecarrée par des facteurs externes?

La source