Le associazioni incerte dei clienti richiedono un percorso definito

Quando un’integrazione non riesce ad associare con affidabilità il cliente di un’operazione, quel caso deve restare gestibile. Servono un ruolo responsabile, le informazioni necessarie e un ritorno controllato all’elaborazione. Un registro degli errori e l’indicazione di inviare di nuovo più tardi non risolvono un’identità aziendale incerta.

Microsoft considera anche interventi manuali con una causa d’errore tracciabile nei flussi a più passaggi. Il nostro esempio attende prima di scrivere nella destinazione.

Un caso aperto richiede un esito visibile

Nell’esempio interamente fittizio, la richiesta di progetto R-28 deve creare una bozza di progetto nell’ERP. Per il cliente CRM C-508 manca un’associazione confermata. La persona responsabile accerta che debba essere usato l’account cliente ERP esistente K-410. La tabella descrive il flusso desiderato.

Un nome in un elenco non deve decidere da solo la scelta del cliente. Il trattamento deve tenere insieme motivo del caso, versione di origine verificata, associazione precedente, associazione scelta e motivazione della decisione. Solo il ruolo autorizzato può accedere a questi casi.

La correzione deve considerare lo stato attuale

Dati o permessi possono cambiare fra visualizzazione e conferma. Prima di proseguire, verifichi i permessi attuali e se l’account scelto sia ancora utilizzabile. OWASP richiede controlli di autorizzazione a ogni richiesta. Una schermata di modifica già aperta non sostituisce la verifica.

Anche due persone che lavorano contemporaneamente non devono salvare decisioni contraddittorie senza che il sistema se ne accorga. Prerequisiti cambiati o un caso già risolto devono essere rilevati alla conferma. Se le condizioni non sono più valide, l’operazione resta aperta per un nuovo chiarimento.

Una ripetizione non deve creare una seconda bozza

Tutti i tentativi restano collegati alla stessa richiesta di progetto. Serve inoltre una protezione nella destinazione: per esempio una creazione idempotente che non produca un’altra bozza ripetendo la stessa richiesta, oppure un riferimento esterno di cui la destinazione imponga l’unicità, con una verifica affidabile dell’esito. Il solo identificativo dell’operazione non impedisce i duplicati.

Se la risposta manca dopo la scrittura, prima si chiarisce l’esito dell’operazione esistente. AWS segnala che un timeout non esclude effetti già avvenuti. Finché l’esito è ignoto, non va trattato come un fallimento certo e sostituito con una nuova richiesta arbitraria.

Limitare il percorso manuale ai casi necessari

Un’associazione univoca e verificata può essere elaborata automaticamente. Non tutti i record richiedono approvazione umana. Negli altri casi devono essere visibili responsabilità, tempo di risposta concordato ed escalation; un elenco che cresce senza un responsabile non risolve il problema.

Il nostro esempio si ferma prima di creare il progetto. Se qualcosa è già stato creato per il cliente sbagliato, occorre una correzione aziendale specifica che consideri i collegamenti generati.

Fonti

• Microsoft — Compensating Transaction pattern

• OWASP — Authorization Cheat Sheet

• AWS — Timeouts, retries, and backoff with jitter