[Vari] Evitare di controllare periodicamente dei dati

[tomminno]

Il titolo è un pò strano ma dovevo mantenermi sul breve.
Fondamentalmente il mio problema nasce con delle date su un database le quali comandano dei processi di elaborazione.
Essendo dati statici in un database non ho un evento o una qualunque segnalazione che mi possa dare il via all'elaborazione.
Lavoro con una infrastruttura ad eventi con ESB e Workflow Engine pertanto è tutto molto fluido e configurabile, tranne questo tipo di elaborazioni.

Ad esempio arriva un ordine e questo mi rappresenta un evento e posso far partire delle operazioni in seguito a questo.
Poi però devo controllare gli ordini che non sono stati pagati da più di X giorni e annullarli.
Ovviamente l'operazione di annullamento non si conclude con un semplice cambio di stato sul database perchè in tal caso potrei semplicemente avere un job schedulato su db.
Con SqlServer potrei inserire del codice managed nelle procedure per eseguire anche task più complessi, ma limitazioni di sicurezza e di topologia della rete non consentono tale implementazione, e soprattutto con MySql questo non sarebbe possibile a prescindere.

L'unica soluzione che riesco a trovare è ovviamente schedulare qualcosa che ogni giorno mi controlli gli ordini non pagati e faccia partire il flusso opportuno.
Il problema è che questi controlli schedulati sono troppi, ogni giorno c'è qualcuno che chiede una qualche nuova procedura che prevede elaborazioni tipo la precedente, con richieste tipo: "Ho bisogno di essere avvisato 3 giorni prima della scadenza", ecc...
Insomma la situazione è diventata caotica.

Esiste qualche tecnica, pattern, best practice in un qualunque linguaggio che mi consenta l'elaborazione che non sia lo schedulare un applicativo che esegua delle query ogni sera per controllare queste date?

Se proprio non ci fosse esiste sempre un qualche best practice per evitare di essere sommersi da migliaia di applicativi schedulati?

[ally]

...bel cruccio...nei limiti del possibile risolvo con crontab e con un applicativo con buon numero di argomenti di lancio...

[PGI-Bis]

Messa così sembra sa un po' di visitor (più che altro perchè visita), nel senso che c'è una parte costante del problema che riguarda l'esecuzione di un ciclo sui dati contenuti nel database ed una parte variabile che riguarda il tipo di funzione applicata ad ogni elemento che appare nel ciclo. In sintesi:

dato un insieme di funzioni determinato all'avvio del programma
per ogni record r del database
-per ogni funzione f
--f(r)

Le funzioni potrebbero essere rappresentate come script, salvati in una posizione nota - che potrebbe essere un database o una tabella del database esistente o una cartella quel che è.

A questo punto potresti soddisfare vecchie e nuove richieste aggiungendo delle funzioni-script in questo percorso automaticamente analizzato dal programma.

[tomminno]

Originariamente inviato da PGI-Bis

A questo punto potresti soddisfare vecchie e nuove richieste aggiungendo delle funzioni-script in questo percorso automaticamente analizzato dal programma.

Avevo pensato a qualcosa tipo plugin, ovvero il processo parte (ma potrebbe anche essere un demone o servizio) carica tutti i plugin presenti in una cartella e li esegue.

Solo che così facendo mi sono reso conto che devo replicare quello che Linux o Windows mi forniscono già gratis ovvero un sistema per schedulare applicativi, perchè non tutti gli applicativi devono girare di notte, magari qualcuno deve girare di giorno, oppure ancora più volte al giorno, ogni X ore e magari devo pure gestire il tempo massimo di esecuzione ecc...

Preso dalla disperazione avevo anche pensato un qualcosa che mi mandi una specie di "segnale orario" sull'ESB, in modo da avere la libertà di sottoscrivere l'evento sui singoli applicativi, ma anche questo mi pare tanto una enorme complicazione.

Insomma tutto facilmente risolvibile con cron o pianificazione dei processi, solo che mi ritrovo con un aumento esponenziale di console con il passare del tempo, di cui tra l'altro è difficile anche tenere traccia, l'ultimo tentativo di conteggio di queste schedulazioni aveva superato quota 2000

Con tutti i problemi che questo comporta a livello di controllo e gestione.