Console simulatori e regole di sicurezza#
La console simulatori è un’area tecnica destinata a esercitare indisponibilità, ritardi, fixing e avanzamento delle evidenze. Non è una normale pagina operativa e non deve essere disponibile in un ambiente reale salvo una sandbox segregata.
Accesso#
La pagina è disponibile solo quando la configurazione consente esplicitamente i simulatori. L’utente deve inoltre avere il ruolo e il permesso previsti per l’area tecnica.
Cosa mostra la console#
La console comprende:
- stato dei sistemi esterni;
- rapporti cash simulati;
- conferme cash generate nello scenario;
- fixing di indici;
- livelli T0/T1/T2;
- messaggi scambiati con i gateway.
La pagina Gateway esterni serve invece alla lettura operativa. La console serve a modificare il comportamento dell’esercitazione.
Cambiare lo stato di un sistema#
Per ogni sistema esterno sono disponibili i comandi:
- Online;
- Degradato;
- Avaria.
Non cambiare più sistemi contemporaneamente nella prima esecuzione del test: renderebbe difficile attribuire l’errore alla causa corretta.
Stato degradato#
degraded non ha lo stesso significato per tutti i provider. Nel simulatore rappresenta una condizione da osservare; l’effetto effettivo dipende dal servizio che interroga lo stato.
Per una prova realistica definire in anticipo quale capability è degradata, per esempio:
- lettura disponibile, scrittura indisponibile;
- istruzioni accettate ma ricevute ritardate;
- fixing non aggiornato;
- polling disponibile ma webhook assente;
- rail leggibile ma signer non disponibile.
Annotare il comportamento atteso nel verbale di esercitazione.
Rapporti cash simulati#
La tabella mostra saldi mantenuti nello store del simulatore. Questi saldi:
- non sono conti bancari;
- non rappresentano moneta reale;
- servono a verificare riserva, insufficienza di fondi e trasferimento simulato;
- vengono aggiornati dal provider cash simulato.
L’operatore non dovrebbe correggerli direttamente nel database durante una prova, perché perderebbe la tracciabilità dell’evento che ha causato la variazione.
Pubblicare un fixing#
La console consente di inserire un valore per gli indici ammessi nell’interfaccia, come EURIBOR_3M o HICP_EX_TOBACCO.
Un fixing pubblicato nel simulatore non deve essere confuso con un dato di mercato acquisito e licenziato da un provider reale.
Avanzare le evidenze#
Il comando Simula webhook T1/T2 porta le attestazioni simulate al livello successivo:
T0 → T1 → T2Il comando Rileggi stato provider esegue invece la sincronizzazione dello stato già presente nel provider.
Queste funzioni verificano il workflow di aggiornamento e la visibilità nell’Exchange. Non producono una marca temporale qualificata né una transazione Bitcoin reale.
Messaggistica osservabile#
La tabella dei messaggi è utile per verificare:
- sistema destinatario;
- tipo di messaggio;
- riferimento;
- data;
- payload sintetico.
Il payload mostrato è materiale di esercitazione. In un’integrazione reale i log devono essere minimizzati e non devono contenere segreti, dati personali non necessari o documenti completi.
Sequenza raccomandata dei test#
- Happy path con tutti i sistemi online.
- Indisponibilità prima dell’invio.
- Timeout dopo l’invio ma prima della ricevuta.
- Ricevuta tardiva.
- Duplicazione della stessa richiesta.
- Payload incoerente.
- Importo o quantità discordante.
- Ripresa e riconciliazione.
- Eccezione successiva alla finalità.
Reset dell’ambiente#
Non esiste un “reset innocuo” di una singola schermata se gli oggetti sono già entrati nel registro o nel settlement. Per ripetere lo scenario:
- usare l’ambiente dedicato all’esercitazione;
- ricaricare il preset solo con la procedura amministrativa prevista;
- non cancellare manualmente eventi autoritativi;
- conservare il report della prova prima del reset;
- verificare che nessun dato reale sia presente.