Appunti x modifica eventuale di MP/MON (Vue.js?)

This commit is contained in:
Samuele E. Locatelli
2019-04-02 22:35:16 +02:00
parent bcdb7b2d20
commit 689717e30a
+39
View File
@@ -4,14 +4,53 @@
- [Appunti sviluppo](#appunti-sviluppo)
- [Modifiche funzionali](#modifiche-funzionali)
- [MP/MON](#mpmon)
- [Obiettivi](#obiettivi)
- [Schema refactoring](#schema-refactoring)
- [Richieste clienti](#richieste-clienti)
- [Jetco](#jetco)
- [Donati](#donati)
- [ATTENZIONE LIBRERIE](#attenzione-librerie)
<!-- /TOC -->
## 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.
## Richieste clienti
### Jetco