← Portfolio
RENTRI Interoperability Suite
Caso studio · Vetrina

RENTRI Interoperability Suite

Parlare con il registro nazionale dei rifiuti senza imparare AgID, XSD e certificati.

What it isWeb app che collega gestionali e trasportatori al registro RENTRI
RoleProgettazione, sviluppo, sicurezza, infrastruttura
StackRust · Yew · Axum · PostgreSQL · WebAssembly
StatusOnline, sull'ambiente demo del Ministero
The problem

Un registro nazionale, un'interfaccia da specialisti

Il RENTRI è il registro elettronico nazionale per la tracciabilità dei rifiuti: registri e formulari di identificazione (FIR) passano dalla carta a documenti digitali firmati. Chi produce, trasporta o intermedia rifiuti deve dialogare con le sue API.

Per farlo servono un certificato X.509, token firmati secondo le linee guida AgID, XML validi rispetto agli schemi ufficiali e un flusso asincrono a più passi. Un gestionale esistente non sa fare nessuna di queste cose, e un autista in un piazzale senza campo non ha tempo di impararle.

Ogni trasmissione è un dialogo asincrono: il registro accetta, si interroga lo stato finché non rimanda al risultato. La suite lo fa per te e ti restituisce solo l'esito.
Cosa fa

Tre strumenti, una sola base

  1. Middleware per gestionali

    Un gestionale manda un movimento in JSON semplice; la suite valida, traduce nel modello RENTRI, firma i token, trasmette e attende l'esito. Nessuna conoscenza di AgID, schemi o certificati richiesta a chi chiama.

  2. Ispettore della qualità dei dati

    Valida un movimento prima che parta: schema, coerenza semantica e, con un certificato, i controlli dal vivo sulle codifiche e sulla giacenza. Il verdetto è un semaforo; volendo, il movimento passa anche dal validatore ufficiale del Ministero.

  3. FIR digitale per chi trasporta

    Un'app da telefono per compilare il formulario sul posto. Senza rete salva la bozza in coda; al ritorno della connessione crea il FIR, guida la firma in due fasi, scarica e valida il documento.

The product decision

Un motore di validazione, compilato due volte

Le regole — enumerazioni e vincoli degli schemi ufficiali, coerenza tra codice EER, stato fisico e classi di pericolo, quantità e unità — vivono in una libreria senza rete né database. La stessa libreria gira nel browser, compilata in WebAssembly, e nel server.

Così chi compila vede l'errore mentre scrive, e il server rifiuta lo stesso errore prima di toccare il registro: due controlli, un solo codice, nessuna possibilità che divergano.

Il rapporto di validazione: ogni riga ha un codice, una gravità e lo strato che l'ha prodotta — schema, semantica o controllo dal vivo. Basta un errore e il semaforo è rosso.
Security

Le chiavi non escono mai dal server

Il certificato è la cosa più delicata che un operatore possiede: la suite lo tratta come tale.

Cifrato a riposo

Certificato e password sono salvati nel database solo cifrati (AES-256-GCM) con una chiave che vive fuori dal database: una copia dei dati, da sola, non serve a nulla.

Un token per richiesta

I token AgID vengono costruiti al momento, con identificativo unico e scadenza di due minuti, e scartati subito dopo. Il browser vede solo lo stato del proprio spazio di lavoro, mai il materiale crittografico.

Due certificati, due ruoli

Il certificato di interoperabilità autentica le chiamate; la firma del formulario richiede per legge un certificato qualificato distinto. La suite li tiene separati e lo dice chiaramente nell'interfaccia.

Niente codice in linea

La politica di sicurezza dei contenuti non ammette script o stili in linea e non carica nulla da terzi: font, icone e codice stanno sulla stessa infrastruttura.

Si prova senza registrarsi

Ogni visitatore ha uno spazio di lavoro anonimo legato a un cookie del solo sito: nessuna mail, nessun dato personale raccolto per provare gli strumenti.

Query verificate a compilazione

Ogni interrogazione al database è controllata dal compilatore contro lo schema reale: una colonna rinominata ferma la compilazione, non il servizio in produzione.

Under the hood

Costruita per reggere i cambi di regole

Un registro pubblico cambia: nuove versioni degli schemi, nuove codifiche. La suite è fatta per accorgersene prima degli utenti.

Test di allineamento agli schemi

Gli schemi ufficiali sono versionati nel progetto e un test li rilegge a ogni esecuzione: se una costante del motore non coincide più con lo schema, la suite di test fallisce prima di qualunque rilascio.

Il flusso asincrono, provato a secco

L'intero dialogo con il registro — accettazione, interrogazione dello stato, rimando, esito, ritardi richiesti dal server — è esercitato contro un server finto locale. In produzione l'attesa è di secondi; nei test, di millisecondi, senza percorsi di codice diversi.

Coda offline nel browser

Le bozze dei formulari stanno in IndexedDB, con ripresa dopo un crash e migrazione automatica dei dati salvati dalle versioni precedenti: una bozza compilata in cantina non si perde.

Documentazione ufficiale, versionata

La documentazione del portale del Ministero è stata scaricata con uno strumento dedicato e tenuta nel progetto: ogni scelta di integrazione rimanda a una pagina precisa, e un nuovo scaricamento mostra cosa è cambiato.

Server-side rendering

Le pagine arrivano già scritte dal server e poi si accendono nel browser: si leggono anche con una rete lenta e i link condivisi mostrano l'anteprima giusta.

Seven languages

L'italiano è l'originale; le altre sei lingue sono estratte, tradotte e tenute allineate dagli strumenti di casa, così una schermata nuova non resta indietro.

In numbers

Quello che si può contare

3strumenti su una base comune
7lingue dell'interfaccia
140+test automatici, schemi compresi
29pagine di documentazione ufficiale versionate
2certificati con ruoli distinti
0servizi di terzi nel browser
Limiti dichiarati

Cosa è, cosa non è ancora

La vetrina dialoga con l'ambiente dimostrativo del Ministero: si prova con un certificato demo e nessun dato finisce nel registro reale. Il passaggio all'ambiente di produzione è una configurazione, non una riscrittura.

La firma del formulario in produzione richiede un certificato qualificato dell'operatore, che questa installazione non possiede: la suite guida la firma, non la sostituisce.

Da vetrina a prodotto

Il passo successivo è già disegnato

Gli spazi di lavoro anonimi sono giusti per una demo pubblica; per un cliente diventano account con ruoli. Il controllo delle giacenze legge il registro dell'operatore e, quando la forma non è riconosciuta, lo dice invece di indovinare.

Un quarto strumento — una console per chi gestisce più clienti in delega — è progettato e non ancora costruito: è la prima cosa che chiederei a chi volesse offrire la suite ai propri clienti.

Provala con un certificato demo, o portala ai tuoi clienti

La demo è online e non chiede registrazione. Se lavori con chi produce, trasporta o intermedia rifiuti, la suite può uscire con il tuo marchio.