🎉 T-wiki 1.3.0 is released

BACK-ENDProgettiDeadPoolQueue

DeadPoolQueue

Architettura

Flusso

  1. Worker (DeadPoolQueueWorker)
    • Ruolo: Orchestratore del servizio.
    • Funzionamento: Esegue un ciclo infinito che richiama periodicamente il Gestore Errori
      • Se il gestore segnala un errore critico, il worker attende un intervallo di tempo configurabile (DeadLetterQueueSettings:MinutiAttesaRiesecuzione) prima di riprovare.
  2. DeadLetterQueueGestore
    • Ruolo: Cuore della logica di business.
    • Flusso di Esecuzione:
      1. Recupera l’elenco di Topic e Sottoscrizioni da Azure Service Bus.
      2. Itera su ogni sottoscrizione.
      3. Legge i messaggi dalla Dead Letter Queue in modalità PeekLock (senza rimuoverli subito).
      4. Invia i messaggi a ElasticSearch per l’archiviazione.
      5. Se l’archiviazione ha avuto successo, completa i messaggi su Service Bus, rimuovendoli dalla coda.
      6. Implementa un meccanismo di sicurezza (NrMassimoCicliPerCoda) per evitare loop infiniti su code problematiche.
  3. AccessoDatiDeadLetterQueues
    • Tecnologia: Azure.Messaging.ServiceBus.
    • Funzionalità:
      • Lettura della topologia (Topic/Subscription) tramite ServiceBusAdministrationClient.
      • Lettura messaggi DLQ tramite ServiceBusReceiver.
      • Supporto per Retry Policy configurabili.
  4. AccessoDatiElasticSearch
    • Tecnologia: Elastic.Clients.Elasticsearch.
    • Funzionalità:
      • Indicizzazione dei messaggi.
      • Supporto per operazioni Bulk per ottimizzare le performance.
      • Gestione dinamica dell’indice di destinazione basata sul messaggio.

Entità salvata

Da ogni messaggio letto nelle dead letter queue vengono prelevati i seguenti dati:

public record ElasticMessageDTO(
    DateTime DataOraGestione,
    string CodiceDiErrore, // DeadLetterMessage.DeadLetterReason
    string MessaggioDiErrore, // DeadLetterMessage.DeadLetterErrorDescription
    string Sottoscrizione, // DeadLetterMessage.DeadLetterSource
    string CorpoMessaggio // DeadLetterMessage.Body
);

Il campo CorpoMessaggio è di tipo string e non object? per evitare di avere una infinità di campi salvati negli indici (soprattutto per le entità più complesse).