From 689717e30a64b875e3b24537ffe29a09a8655a4e Mon Sep 17 00:00:00 2001
From: "Samuele E. Locatelli" <samuele@steamware.net>
Date: Tue, 2 Apr 2019 22:35:16 +0200
Subject: [PATCH] Appunti x modifica eventuale di MP/MON (Vue.js?)

---
 Appunti.md | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Appunti.md b/Appunti.md
index 8bd6c9a3..83a51d95 100644
--- a/Appunti.md
+++ b/Appunti.md
@@ -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