Gestione code messaggi

Per la gestione delle code messaggi è stato deciso di utilizzare Azure Service Bus, strumento di messaggistica di Azure.

I messaggi sono inviati/ricevuti tramite:

1. Argomenti con sottoscrizioni (topics).

Argomenti e sottoscrizioni

Al momento, è necessario creare gli argomenti e le sottoscrizioni manualmente.

Gli standard di nomenclatura sono:

• Argomenti: hanno il nome della classe contratto che andranno a trasmettere (es. eansingolovariazione).
• Topic: seguono la nomenclatura {nome-applicazione}_{nome-argomento} (es. anagrafiche_eansingolovariazione)

Utilizzo code messaggi

Pubblicazione

Tutti i metodi di pubblicazione hanno la seguente logica comune:

1. Connessione: recupera la stringa di connessione dall’appsettings.json
2. Nome coda: calcola il nome della coda dal tipo di evento che deve essere inviato e il nome dell’applicazione dall’appsettings.json

I metodi di pubblicazione sulle code di Azure Service Bus sono:

1. Pubblica (Singolo IEvento)

   • Scopo: invio di un singolo oggetto di tipo IEvento.
   • Flusso:
     1. Crea un ServiceBusClient e un ServiceBusSender.
     2. Serializza il messaggio in un JSON.
     3. Invia il messaggio tramite SendMessageAsync.

2. PubblicaMultiplo (IEventoMultiplo)

   • Scopo: invio di un singolo oggetto di tipo IEventoMultiplo
   • Flusso:
     1. Se necessario divide la lista di eventi ad un valore fisso di elementi
     2. Serializza il messaggio in un JSON.
     3. Invia il messaggio tramite SendMessageAsync.

3. PubblicaMultiplo (Lista di IEvento)

   • Scopo: invio di eventi singoli in una singola chiamata ad azure
   • Flusso:
     1. Accodamento in memoria
        • Serializza i singoli IEvento
        • Crea ed aggiunge ad una Queue<ServiceBusMessage> gli eventi in memoria
     2. Invio Batch
        • Crea ServiceBusMessageBatch per un invio massivo degli eventi
        • Riempie il batch finché c’è spazio (TryAddMessage)
        • Quando il batch è pieno lo invia alla coda Azure
        • Ripete questa logica finché la Queue<ServiceBusMessage>, in memoria, contiene messaggi

Consumazione

1. Consuma (Sincrono e asincrono)
   • Scopo: Lettura di un singolo messaggio nelle code messaggi azure
   • Flusso:
     1. Recupero stringa di connessione e nome coda basato sui dati nell’appsettings.json
     2. Ricezione singolo messaggio
     3. Deserializzazione json messaggio (se fallisce il messaggio viene messo nelle Dead letter)
     4. Tramite un gestore esterno elabora il messaggio. Gli esiti possibili sono:
        • Successo: il messaggio viene completato ed eliminato dalla coda
        • Fallito: Scatta la logica di Retry

Logica Retry o DeadLettereQueue?

Il sistema implementa una logica di retry personalizzata poiché Service Bus non supporta nativamente retry con delay variabile arbitrario senza bloccare la coda.
Gli step che vengono effettuati sono:

1. Determinazione tentativi:
   • Recupera dall’appsettings.json NumeroMassimoTentativiCoda (default 3)
   • Recupera dal messaggio la proprietà custom RetryCount (default DeliveryCount)
2. Gestione retry
   • DeadLettereQueue se elaborazione.ritenta è a false OPPURE i tentativi superano il limite
   • Logica di retry altrimenti

Logica retry con delay crescente

Questa logica implementa il pattern “Clone & Schedule” per ottenere un retry ritardato

1. Viene creato un clone del messaggio in errore
2. Viene calcolato un scheduling time lineare (delay * tentativi)
3. Invio schedulato del messaggio clonato. Il messaggio sarà disponibile dopo il ritardo calcolato
4. Completamento e cancellazione del messaggio originale, solo se viene inviato il clone

Configurazione Messaggi di errore e retry

Configurazione retry

Nella classe Elaborazione è presente l’attributo Ritenta e il metodo DaRitentare() per la gestione del retry.

• DaRitentare(): Metodo di configurazione dell’attributo Ritenta. Va utilizzato nei vari flussi che utilizzano le code messaggi per far sì che nel metodo Consuma() venga riaccodato il messaggio in caso di anomalie nel gestore.
• Ritenta: Attributo utilizzato dal metodo Consuma() per sapere se il messaggio prelevato dalla coda debba essere gestito molteplici volte in caso di errore (es. attesa di import di una entità collegata)

Configurazione messaggi errore

La classe Elaborazione espone l’attributo Eccezione (di tipo Segnalazione). Questo attributo viene utilizzato dal metodo Consuma per prelevare il messaggio di errore da inviare alla coda messaggi.
La gestione del campo Eccezione è data dai metodi statici:

• RegistraComeEccezioneGenerica():
  1. Scopo: log interni.
  2. Messaggio code: “Errore interno”
• RegistraComeEccezioneDettagliata()
  1. Scopo: eccezione per il cliente
  2. Messaggio code: una stringa di dettagli presente nei parametri del metodo, oltre la segnalazione.