Trigger di eventi basati su timer

Question

Attualmente sto lavorando a un progetto con requisiti specifici.Una breve panoramica di questi è la seguente:

• I dati vengono recuperati da servizi web esterni
• I dati vengono archiviati in SQL 2005
• I dati vengono manipolati tramite una GUI web
• Il servizio Windows che comunica con i servizi Web non ha alcun accoppiamento con la nostra interfaccia utente Web interna, se non tramite il database.
• La comunicazione con i servizi Web deve essere basata sul tempo e attivata tramite l'intervento dell'utente sull'interfaccia utente Web.

L'attuale modello (pre-pre-produzione) per l'attivazione della comunicazione del servizio Web avviene tramite una tabella di database che memorizza le richieste di attivazione generate dall'intervento manuale.Non voglio davvero avere più meccanismi di trigger, ma vorrei essere in grado di popolare la tabella del database con trigger in base all'ora della chiamata.Per come la vedo io ci sono due modi per raggiungere questo obiettivo.

1) Adattare la tabella di trigger per memorizzare due parametri aggiuntivi.Uno è "questo è basato sul tempo o aggiunto manualmente?" e un campo annullabile per archiviare i dettagli di temporizzazione (formato esatto da determinare).Se si tratta di un trigger creato manualmente, contrassegnalo come elaborato quando il trigger è stato attivato, ma non se è un trigger a tempo.
O
2) Creare un secondo servizio Windows che crei i trigger al volo a intervalli prestabiliti.

La seconda opzione mi sembra una truffa, ma la gestione dell'opzione 1 potrebbe facilmente trasformarsi in un incubo di programmazione (come fai a sapere se l'ultimo sondaggio della tabella ha restituito l'evento che deve attivarsi, e come poi fermarlo? riattivata al prossimo sondaggio)

Apprezzerei se qualcuno potesse dedicare qualche minuto per aiutarmi a decidere quale percorso (uno di questi due, o eventualmente un terzo, non elencato) prendere.

Answer 1

Perché non utilizzare un processo SQL anziché il servizio Windows?Puoi incapsulare tutto il codice "trigger" db nelle procedure memorizzate.Quindi l'interfaccia utente e il processo SQL possono chiamare le stesse procedure memorizzate e creare i trigger nello stesso modo, sia manualmente che a intervalli di tempo.

Answer 2

Per come la vedo io è questa.

Hai un servizio Windows, che svolge il ruolo di uno scheduler e in esso ci sono alcune classi che chiamano semplicemente i servizi web e inseriscono i dati nei tuoi database.

Pertanto, puoi utilizzare queste classi anche direttamente dalla WebUI e importare i dati in base al trigger WebUI.

Non mi piace l'idea di archiviare un'azione generata dall'utente come flag (trigger) nel database in cui alcuni servizi la effettueranno il polling (a un intervallo che non è sotto il controllo dell'utente) per eseguire quell'azione.

Potresti anche convertire l'intero codice in un file exe che potrai quindi pianificare utilizzando l'Utilità di pianificazione di Windows.E chiama lo stesso exe ogni volta che l'utente attiva l'azione dall'interfaccia utente Web.

Answer 3

@Vaibhav

Sfortunatamente, l'architettura fisica della soluzione non consentirà alcuna comunicazione diretta tra i componenti, oltre all'interfaccia utente Web con il database e tra il database e il servizio (che può quindi richiamare i servizi Web).Sono tuttavia d'accordo sul fatto che il riutilizzo delle lezioni di comunicazione sarebbe l'ideale in questo caso: semplicemente non posso farlo entro i confini della nostra attività*

*Non è sempre così che una soluzione tecnicamente "migliore" viene ostacolata da fattori esterni?