diff --git a/Appunti.md b/Appunti.md index 8bd6c9a3..b3e9f627 100644 --- a/Appunti.md +++ b/Appunti.md @@ -1,17 +1,78 @@ # Appunti sviluppo - - -- [Appunti sviluppo](#appunti-sviluppo) - - [Modifiche funzionali](#modifiche-funzionali) - - [Richieste clienti](#richieste-clienti) - - [Jetco](#jetco) - - [Donati](#donati) - - +autoauto- [Appunti sviluppo](#appunti-sviluppo)auto - [Modifiche funzionali](#modifiche-funzionali)auto - [MP/MON](#mpmon)auto - [Obiettivi](#obiettivi)auto - [Schema refactoring](#schema-refactoring)auto - [MP/MON](#mpmon-1)auto - [Obiettivi](#obiettivi-1)auto - [Schema refactoring](#schema-refactoring-1)auto - [Richieste clienti](#richieste-clienti)auto - [Jetco](#jetco)auto - [Donati](#donati)auto - [ATTENZIONE LIBRERIE](#attenzione-librerie)autoauto ## Modifiche funzionali +### MP/MON + +#### Obiettivi + +Modifica comportamento MP/MON: + - rendere la pagina del MON configurabile per ogni cliente + - migiorare il carico sul DB sfruttando meglio la cache di redis + - costruire uno strato intermedio di configurazione x la visualizzazione che permetta di disaccoppiare visualizzazione cliente e recupero dati (più standard) + - avere una policy di recupero e calcolo dati da DB suddivisa per NATURA del dato in modo da eseguire meno di frequeste i task meno importanti + +#### Schema refactoring + +Si prevede di effettuare il refactoring seguendo queste linee guida: + +- uso intensivo di LUT (LookUp Table) +- definire un area PER OGNI IMPIANTO in REDIS +- definire gli elementi di ogni singolo blocco come posizioni in cui mostreremo una LABEL +- in ogni area redis avremo TUTTE le informazioni di una macchina +- ci potranno essere più HashTable / KVP per ogni macchina, per rappresentare ad es diverse sorgenti di dato rappresentabili con un HAS REDIS per venire recuperate +- creeremo una LUT chiamata **LUT_TTL** che configurerà il TTL standard per ogni BLOCCO informativo (ad esempio: PROD1 --> 2 significa che il dato di PROD1 avrà un TTL di 2 sec dopo di cui sarà ricalcolato); TTL = 0 --> nessuna scadenza, altrimenti si aspetta un TTL in sec (decimal per avere anche < 1 sec) +- associeremo una **LUT_DATA** x legare le labels posizionali agli elementi delle aree informative in REDIS (es: label1 --> PROD:CodArt) +- chiamate tramite API REST +- cercheremo per prima cosa ogni items in REDIS, non trovandolo sarà invocato il metodo di refresh della HashTable / sorgente informativa con il TTL definito nella **LUT_TTL** +- compost il dato complessivo questo sarà salvato in una cache ELABORATA di breve periodo (tipicamente <= 500ms) in modo da non rifare nemmeno letture/ricostruzioni oltre i 2Hz +- tendenzialmente ogni singolo blocco CHIAMERA' la WebApi x ottenere le proprie informazioni e mostrarle +- le LUT saranno configurate nel DB in modo differente per ogni cliente, avendo una versione standard sulla macchina **STD_IOB** (in modo da poterla usare come default ove non specificato) e avendo poi override per ogni macchina in cui fosse necessario per le sole parti differenti. Ad esempio, se ogni macchina si differenziasse solo per le etichette label3 e label4, avremo il set completo della **STD_IOB**, poi per ogni impianto avremo la definizione di come comporre laberl3/label4 sul DB; a livello REDIS questi dati saranno "fusi" per costituire le essatte LUT di ogni macchina in modo esplicito (e teoricamente immutabile sino a riavvio dei pool di esecuzione delle applicazioni /MP/MON) + +DI FATTO possiamo usare delle PARTIAL PAGE (come le attuali _StatusMapSingle.cshtml / _StatusMap.cshtml) x definire il MACRO template. + +Ogni machcina specificherà QUALE template usare (SE NON QUELLO STANDARD, ereditato) + +Ogni tempalte userà dei dati in modo diverso a partire dal datamodel COMUNE ED UNICO che espone per TUTTE le macchine lo stesos insieme COMPLETO di dati. + +### MP/MON + +#### Obiettivi + +Modifica comportamento MP/MON: + - rendere la pagina del MON configurabile per ogni cliente + - migiorare il carico sul DB sfruttando meglio la cache di redis + - costruire uno strato intermedio di configurazione x la visualizzazione che permetta di disaccoppiare visualizzazione cliente e recupero dati (più standard) + - avere una policy di recupero e calcolo dati da DB suddivisa per NATURA del dato in modo da eseguire meno di frequeste i task meno importanti + +#### Schema refactoring + +Si prevede di effettuare il refactoring seguendo queste linee guida: + +- uso intensivo di LUT (LookUp Table) +- definire un area PER OGNI IMPIANTO in REDIS +- definire gli elementi di ogni singolo blocco come posizioni in cui mostreremo una LABEL +- in ogni area redis avremo TUTTE le informazioni di una macchina +- ci potranno essere più HashTable / KVP per ogni macchina, per rappresentare ad es diverse sorgenti di dato rappresentabili con un HAS REDIS per venire recuperate +- creeremo una LUT chiamata **LUT_TTL** che configurerà il TTL standard per ogni BLOCCO informativo (ad esempio: PROD1 --> 2 significa che il dato di PROD1 avrà un TTL di 2 sec dopo di cui sarà ricalcolato); TTL = 0 --> nessuna scadenza, altrimenti si aspetta un TTL in sec (decimal per avere anche < 1 sec) +- associeremo una **LUT_DATA** x legare le labels posizionali agli elementi delle aree informative in REDIS (es: label1 --> PROD:CodArt) +- chiamate tramite API REST +- cercheremo per prima cosa ogni items in REDIS, non trovandolo sarà invocato il metodo di refresh della HashTable / sorgente informativa con il TTL definito nella **LUT_TTL** +- compost il dato complessivo questo sarà salvato in una cache ELABORATA di breve periodo (tipicamente <= 500ms) in modo da non rifare nemmeno letture/ricostruzioni oltre i 2Hz +- tendenzialmente ogni singolo blocco CHIAMERA' la WebApi x ottenere le proprie informazioni e mostrarle +- le LUT saranno configurate nel DB in modo differente per ogni cliente, avendo una versione standard sulla macchina **STD_IOB** (in modo da poterla usare come default ove non specificato) e avendo poi override per ogni macchina in cui fosse necessario per le sole parti differenti. Ad esempio, se ogni macchina si differenziasse solo per le etichette label3 e label4, avremo il set completo della **STD_IOB**, poi per ogni impianto avremo la definizione di come comporre laberl3/label4 sul DB; a livello REDIS questi dati saranno "fusi" per costituire le essatte LUT di ogni macchina in modo esplicito (e teoricamente immutabile sino a riavvio dei pool di esecuzione delle applicazioni /MP/MON) + +DI FATTO possiamo usare delle PARTIAL PAGE (come le attuali _StatusMapSingle.cshtml / _StatusMap.cshtml) x definire il MACRO template. + +Ogni machcina specificherà QUALE template usare (SE NON QUELLO STANDARD, ereditato) + +Ogni tempalte userà dei dati in modo diverso a partire dal datamodel COMUNE ED UNICO che espone per TUTTE le macchine lo stesos insieme COMPLETO di dati. + + + + ## Richieste clienti ### Jetco diff --git a/Appunti.pdf b/Appunti.pdf index f5836389..6a1734be 100644 Binary files a/Appunti.pdf and b/Appunti.pdf differ