Piattaforma di elaborazione dati e documenti

Problema

I dati arrivano da fonti diverse, ciascuna con un proprio formato Excel, e da questi vanno prodotti documenti, calcoli e comunicazioni. Gestire ogni formato e ogni documento con codice dedicato rende il sistema rigido: ogni variazione richiede uno sviluppo e un rilascio.

Soluzione

Un gestionale web in Spring Boot organizzato in cinque moduli, costruiti attorno a un principio comune: il comportamento è descritto da configurazioni e template, il codice fornisce motori generici.

Normalizzazione dati (Excel → CSV)

• Conversione di file Excel eterogenei in un unico tracciato standard, tramite Strategy Pattern: un elaboratore per ogni formato e un registro che li risolve a runtime.
• Ogni elaboratore dichiara la propria organizzazione dei dati (un foglio o un file per entità), così un unico motore gestisce tutti i formati.
• Per i formati sconosciuti, una mappatura manuale guidata: l’utente sceglie il foglio, consulta un’anteprima e associa le colonne al tracciato, con suggerimenti automatici basati su sinonimi.
• Normalizzazione di codici, quantità e date, verifica dei totali sui file a più blocchi e segnalazione delle righe dubbie.
• Caricamento in due fasi (upload multiplo e conferma delle entità rilevate, poi elaborazione), con output in CSV singolo o archivio ZIP.

Generazione di documenti (Excel → Word)

• Produzione di documenti Word a partire da fogli Excel con celle calcolate da formule.
• Mappatura guidata da configurazioni JSON modificabili senza ricompilare: celle associate ai segnaposto del template, campi calcolati e blocchi condizionali.
• Parser di espressioni scritto ad hoc, con operatori aritmetici, confronti e operatori logici && / || con precedenza: le condizioni variano le frasi e mostrano o nascondono interi paragrafi del template.

Calcoli su Excel (Excel → Excel)

• Lettura dell’input secondo regole JSON, calcolo dei valori derivati e scrittura su un template Excel di output.

Rubrica e invio email massivo

• Rubrica con gruppi, liste di distribuzione salvate, azioni su selezioni multiple e disattivazione dei contatti senza cancellazione.
• Campagne eseguite da un worker asincrono, con una sola sessione SMTP per campagna, intervalli tra gli invii, nuovi tentativi con backoff esponenziale e un circuit breaker sui rifiuti consecutivi, che distingue il superamento della quota del provider da un indirizzo errato.
• Ripresa delle campagne interrotte anche dopo un riavvio: gli allegati sono persistiti su database e le campagne rimaste a metà vengono riconciliate all’avvio.

Piattaforma comune

• Autenticazione con ruoli, password cifrate con BCrypt, sessione unica per utente, protezione CSRF, HSTS e blocco temporaneo dopo ripetuti tentativi di login falliti.
• Audit log asincrono su database, con pulizia automatica.
• Archivio dei file temporanei su due livelli (cache in memoria e disco), con proprietà per utente e pulizia programmata.
• Thread pool dedicati per i lavori asincroni e per quelli programmati.

Scelte tecniche

• Refactoring architetturale: tre flussi di elaborazione paralleli unificati in un unico motore parametrico.
• Robustezza: errori espliciti invece di risultati vuoti dati per validi, validazioni con messaggi comprensibili e gestione delle anomalie presenti nei dati reali.
• Ottimizzazioni misurate: ogni ottimizzazione è stata valutata sul volume di dati effettivo; quelle che aggiungevano complessità senza un guadagno misurabile sono state scartate.
• Configurazione al posto del codice: nuovi documenti e nuovi calcoli si aggiungono scrivendo JSON e template, senza nuovi deploy.

In numeri

Circa 125 classi Java (~9.400 righe), ~2.400 righe di JavaScript senza framework, 5 moduli funzionali e 47 test automatici.

Il mio contributo

Progetto realizzato interamente da me: architettura, sviluppo backend e front-end, sicurezza e test automatici.

Risultato

Nuovi formati, documenti e calcoli si aggiungono con configurazioni JSON e template, senza modificare il codice né rilasciare una nuova versione.