Progetto di un bilanciatore applicativo documentale
Marzo 12, 2024Il metodo process_document della classe BilanciatoreApplicativo: il gestore del flusso.
Il metodo process_document risulta molto importante nella gestione del flusso dei documenti e come tale nel progetto del bilanciatore applicativo documentale. Nel seguito, ho pensato, che un diagramma delle attività potrebbe essere di supporto alla comprensione di tale oggetto.
(Il metodo process_document del bilanciatore applicativo documentale).
La gestione dei messaggi di errore
Tale argomento è abbastanza importante e merita un approfondimento. Essendo complesso il processo del bilanciatore, bisogna gestire in maniera chiara e precisa l’applicazione della firma al documento, la famosa FEQ applicata dal fiduciario esterno. In caso di errore, in qualche metodo, e in qualche modo, il bilanciatore deve rispondere con dei messaggi di errore.
Nella tabella seguente ho organizzato i vari messaggi di errore in modo semplificato.
| Codice Errore | Descrizione |
|---|---|
| 10 | Non è presente il record cercato nella coda del bilanciatore |
| 11 | Impossibile salvare il documento nella coda del bilanciatore |
| 88 | Errore nella trasmissione del documento |
| 89 | Errore nella chiamata ai server attivi |
| 90 | Il documento ha dimensioni zero, per cui non può essere processato! |
| 91 | Il documento è stato firmato correttamente ma non eliminato dalla coda del bilanciatore |
(Gestione semplificata degli errori)
La gestione degli errori è stata attuata in ambiente di produzione sulla base della tabella due. Nell’ambiente di simulazione la visualizzazione degli errori è stata risolta solamente con dei semplici messaggi (dei “print”) in risposta alle richieste http ai vari nodi middleware del provider (anche quest’ultimi simulati). Per cui, in questo articolo non vi sarà il codice per la gestione degli errori.
Test di integrazione
Per quanto concerne i test di integrazione e quindi le chiamate agli n server dello strato middleware che poi si occuperanno di inviare i documenti al provider di firma, sono stati implementati dei logs per il monitoraggio della coda di elaborazione e del buon funzionamento del bilanciatore applicativo. Le due immagini seguenti vi restituiscono degli esempi di logs.
(Log del server di restituzione del documento firmato in base64 dal server 1)
(Log del server di restituzione del documento firmato in base64 dal server 0)
Come si vede nelle due immagini precedenti, il bilanciatore nella prima sceglie il server 1 (primo server di invio) e poi sceglie il server 0 (secondo server di invio) in base al carico sulla coda di elaborazione. Il resto del codice è il documento in bas64 contenente anche la firma o firme digitali applicate dal server di firma.
