Ogni BPL si compila, testa e distribuisce indipendentemente, con dipendenze rigorosamente monodirezionali. Più database orchestrati dalla sincronizzazione, con PostgreSQL come hub di piattaforma. Accanto, MemoryLens, sicurezza e integrazione.
Le dipendenze sono monodirezionali. Aggiornare un modulo significa sostituire un file .bpl, senza ricompilare l'eseguibile.
La piattaforma resta multi-database — Firebird per il MES, SQL Server/COBOL per l'ERP — ma i servizi
trasversali (identità, permessi, telemetria, documentazione, AI) convergono su PostgreSQL. Il salto è
isolato dietro interfacce (IAuthProvider,
IAuthRepository): cambiare sorgente
dati significa cambiare un'implementazione e una riga di bootstrap, senza toccare i moduli.
Tabelle AUTH_* (risorse, azioni, ruoli, matrice permessi, ruoli utente) e provider di identità su PostgreSQL. FK vere, permessi e identità co-locati.
Eventi applicativi e di sicurezza consolidati in ml_app_events su PostgreSQL, con pattern outbox dal SyncEventHub.
Con pgvector, gli embedding vivono accanto ai dati: niente secondo database, ricerca semantica dove già stanno le informazioni.
// L'identità è astratta: Firebird oggi, PostgreSQL domani if HasAuthProvider then Result := CurrentAuthProvider.Authenticate(AUser, APwd) else Result := LegacyLogin2(AUser, APwd); // fallback // Cutover a PG = una riga di bootstrap: SetAuthProvider(TAuthPgProvider.Create(connPG));
Dashboard, telemetria, audit, documentazione, log e sincronizzazione non sono opzioni per singolo modulo: sono servizi del framework. Uno scaffolding conforme alle regole del server MCP (scaffold_module) li aggancia automaticamente — un modulo generato nasce già osservabile, tracciato e documentato.
Un sistema trasversale che serve tre pubblici con un'unica architettura. Ogni modulo accede via TMLHelper: una uses, zero dipendenze aggiuntive.
Cattura errori, misura performance, documenta decisioni architetturali. Browser ML per navigazione cross-modulo.
Help contestuale con pulsante ? su ogni frame. Tips, avvisi, guide. Late-binding: se ML non è caricata, fallback graceful.
Pannello diagnostica con badge eventi. Creazione ticket con contesto automatico. Viewer eventi con dettaglio.
Autenticazione e autorizzazione fatte bene: modello permessi centralizzato, enforcement dichiarativo, audit su PostgreSQL. Checklist interna OWASP ASVS L1, fondamenta pronte per verifiche future.
Risorse, azioni e ruoli in tabella. Un permesso è la coppia (risorsa, azione); un ruolo è un insieme di permessi; l'utente riceve uno o più ruoli. Complementare al modello a livelli/enti esistente.
Guardie configurate in JSON su form, menu e azioni. Rollout incrementale "uno alla volta", con fail-open finché l'enforcement non è attivo sul modulo.
Chi crea non approva. Base APPROVE già separata, controllo dinamico su azioni sensibili con override tracciato.
Eventi di sicurezza (login, accesso negato, override) su PostgreSQL. Catena hash append-only: la proprietà "non manomesso" senza blockchain.
È il punto centrale dell'architettura: SyncFramework tiene allineati database eterogenei (SQL Server/COBOL dell'ERP, Firebird del MES, PostgreSQL della piattaforma) con un engine hash-based bidirezionale che non richiede trigger né timestamp sulle tabelle sorgente. Ogni sistema resta al suo posto; i dati restano coerenti.
ERP / COBOL
Hash-based Engine
MES locale
Piattaforma · AI
Deletion tracking senza modificare le tabelle sorgente. Garbage collector per la pulizia automatica delle entry obsolete.
Esecuzione multi-profilo parallela. Ogni profilo ha source, target e transform configurabili.
Record falliti tracciati con retry. Conflitti gestiti con policy configurabile per profilo.
Console e servizio. Heartbeat su DB per il monitoraggio. Graceful shutdown.
PostgreSQL sotto, Ollama accanto, MCP come ponte verso i modelli.