Collegare due software: cosa verificare prima di promettere un'integrazione

«I due sistemi si parlano?» è una domanda a cui non si può rispondere. Si parlano per fare che cosa: quale dato, in che direzione, con quale frequenza, e chi ha ragione quando i due dicono cose diverse. Questa guida serve a rispondere prima di prendere un impegno, perché un’integrazione promessa e non verificata trasforma un progetto in una manutenzione senza fine.

Quasi tutte le integrazioni fallite hanno la stessa storia: funzionava in prova, poi è arrivato un caso non previsto — un ordine annullato, un cliente con due schede, un articolo cancellato — e nessuno si è accorto che da tre giorni non passava più niente.

Una riga per ogni dato

Il documento di partenza è un elenco: una riga per dato, quattro colonne. Se non si riesce a compilarlo, non è ancora il momento di guardare le specifiche tecniche.

L’ultima colonna è quella che evita le discussioni. Se il prezzo di un articolo risulta diverso nei due sistemi, chi vince? Se la risposta è «dipende», l’integrazione produrrà dati incoerenti qualunque tecnologia usiate.

I dati che cambiano padrone lungo il percorso

Alcuni dati cambiano proprietario ed è il caso più delicato. Un ordine appartiene al sito finché non viene acquisito; da quel momento la verità sta nel gestionale e il sito ne mostra soltanto una copia. Se entrambi possono modificarlo, prima o poi due modifiche si incroceranno e vincerà l’ultima arrivata, che non è necessariamente quella giusta.

La regola pratica è una sola: per ogni dato, in ogni momento, un solo sistema può scriverlo. Gli altri leggono.

Quello che le interfacce non dicono nella prima pagina

• I permessi. Le credenziali che vi danno possono non coprire tutti i campi che vi servono, e l’autorizzazione può scadere o richiedere un rinnovo periodico che qualcuno deve ricordarsi di fare.
• I limiti. Quante chiamate al minuto o al giorno, quanti record per richiesta. Un catalogo grande può non stare dentro i limiti con la frequenza che vi serve, e questo cambia il progetto, non solo il codice.
• I campi realmente disponibili. La documentazione elenca gli oggetti, ma non sempre dice se i vostri campi personalizzati sono esposti: vanno guardati sui vostri dati, non sull’esempio.
• L’ambiente di prova. Se non esiste, ogni verifica si fa sui dati veri, con quello che comporta. È un vincolo da mettere in conto prima, non da scoprire dopo.
• Le condizioni del fornitore. Che cosa è consentito fare, con quale piano, e se l’accesso allo scambio dati è compreso o è un costo a parte.

Scheda di integrazione: l’ordine che arriva due volte

Il caso da progettare non è quello normale, è quello sporco. Un ordine viene inviato al gestionale, la risposta non arriva per un problema di rete, il sistema riprova, e l’ordine entra due volte. È il guasto più comune di tutti.

1. Ogni messaggio porta un identificativo stabile, deciso da chi lo invia: il numero d’ordine del sito, non un progressivo generato al momento dell’invio.
2. Chi riceve controlla se quell’identificativo è già stato lavorato. Se sì, non rifà niente e risponde che è già a posto. È questa proprietà che rende sicuro riprovare.
3. I tentativi si ripetono a intervalli crescenti e per un numero definito di volte; poi il messaggio finisce in una coda di errori che una persona guarda. Riprovare all’infinito nasconde il problema invece di risolverlo.
4. A intervalli regolari si confrontano i due sistemi sul periodo: quanti ordini da una parte, quanti dall’altra, quali mancano. È la riconciliazione, ed è l’unica cosa che dice davvero se l’integrazione sta funzionando.
5. Il recupero è una procedura scritta: chi cancella il duplicato e in quale sistema, che cosa succede al documento eventualmente già emesso, chi avvisa il cliente se ha ricevuto due conferme.

La stessa scheda va compilata per l’anagrafica cliente, dove il guasto tipico è un altro: due schede per la stessa azienda, create con la partita IVA scritta in due modi diversi. Serve una regola di riconoscimento decisa prima, e un posto dove finiscono i casi dubbi in attesa che una persona li guardi.

Chi se ne accorge quando si ferma

Un’integrazione si ferma sempre, prima o poi: il fornitore aggiorna, una password scade, un certificato non viene rinnovato, un campo cambia formato. La domanda non è se succederà, ma quanto tempo passerà prima che qualcuno lo noti.

• Un controllo che verifichi il passaggio recente di dati e avvisi quando il flusso si interrompe, invece di aspettare la telefonata di un cliente.
• Un destinatario con nome e cognome per quell’avviso, e un secondo nome per quando il primo non c’è.
• Un registro degli scambi consultabile senza chiamare uno sviluppatore: quando un ordine non arriva, la prima domanda è sempre «è partito?».
• Una responsabilità dichiarata per la manutenzione, con le date di scadenza di credenziali e certificati segnate in un posto che qualcuno guarda.

Quello che questa guida non copre

Qui si progetta lo scambio fra due sistemi destinati a convivere. Portare dentro dati storici — da un vecchio gestionale o da fogli di calcolo — è un lavoro diverso, con problemi di pulizia e di controllo del risultato, e ha una guida dedicata. Anche il caso specifico del collegamento fra negozio online e magazzino è trattato a parte.