Il mio cliente ha un processo che itera su un numero di azioni che possono o non possono essere applicate a un portafoglio di utenti. Molto spesso, l'elaborazione di un'azione può abbandonare e passare all'azione o al portafoglio successivo senza interrompere il processo (cioè l'elaborazione diretta).
A volte la decisione che porta alla riduzione dell'elaborazione dell'azione viene scritta nel registro e talvolta no. Anche quando lo è, questo è normalmente scritto deliberatamente a livello Informazioni piuttosto che Errore o Avviso . C'è una buona ragione per questo: Errori e Avvisi sono anche rilevati da altre regole di elaborazione e vengono generati ticket automatici. Se lasciassimo che accadesse, saremmo inondati di biglietti, molti dei quali non sarebbero necessari.
Il problema è che a volte un utente non chiede irragionevolmente perché non è stata eseguita un'azione sul proprio portafoglio e di solito non chiedono fino a pochi giorni o settimane dopo che l'elaborazione è avvenuta a partire da quando i log sono stati spesso purgato.
Ho suggerito che dovremmo introdurre un sistema più robusto per catturare questi problemi nel momento in cui accadono e abbiamo pensato a quanto segue:
- Semplicemente migliora la verbosità della registrazione. Bello e facile ma non aiuta con il problema di eliminazione del log e non crea problemi più ovvio.
- Aggiungi un processo separato per analizzare e analizzare i registri, selezionando su tali questioni. Il vantaggio è che non è necessario alcun o minimo cambiamento di codice, ma potrebbe non essere molto evidente che questo processo è in esecuzione o esiste e potrebbe essere compromesso se i messaggi di registrazione sono cambiati causando la mancata corrispondenza del modello. Potrebbe essere un problema di manutenzione.
- Modificare il codice per acquisire i messaggi separatamente in una tabella di database. Più robusto e ovvio nel codice, ma il cambiamento è più grande e il design della nuova tabella di database potrebbe diventare una sfida (cioè dovrebbe essere solo un campo di testo libero con un indice di data-ora o qualcosa di più strutturato. più complicato se è necessaria la parametrizzazione - e forse XML blob?
Altri aspetti che guidano il design sono: quanto è facile usare queste informazioni? (potremmo presentarlo all'utente stesso per impedire che ci chiamino in primo luogo?) Abbiamo bisogno di creare un'interfaccia per vederlo / monitorarlo? Possiamo cercare rapidamente i dati e accedere ai dettagli per il problema specifico in questione?
Se qualcuno ha qualche esperienza nel creare (o meglio ancora imbullonare) tale funzionalità, sarei molto interessato a sentire esperienze ecc.
Il tech stak che stiamo usando è C ++ (backend) + semplice database SQL e Javascript / web front end.
Tuttavia, non sono così preoccupato per le soluzioni tecnologiche come la soluzione è (a) Più efficace per il minimo sforzo, (b) più mantenibile e (c) aggiunge più valore in termini di ridurre il tempo trascorso girando intorno all'inchiesta biglietti.