Tria una direcció per dada
Determina quin sistema controla cada dada: client, preu, estat de comanda o factura. La sincronització bidireccional necessita regles quan tots dos canvien el mateix camp. Documenta quina dada preval i per què. Un diagrama amb dues fletxes no resol conflictes ni estableix responsabilitats.
Dissenya la repetició segura
Inclou identificadors de negoci que permetin reconèixer una operació ja processada. Prova un esdeveniment duplicat i una resposta tardana. Decideix quines accions es poden repetir automàticament i quines necessiten revisió. L’objectiu és evitar que un reintent creï dues comandes o marqui com a acabada una operació encara incerta.
Fes visibles els errors
Registra estat, hora, entitat i causa útil de l’error, evitant informació sensible innecessària. Defineix qui rep l’avís i com reprèn el procés. Distingeix error permanent d’indisponibilitat temporal. Un panell que només mostra èxits deixa l’equip sense explicació quan falten registres.
Acorda la conciliació
A més d’esdeveniments individuals, compara periòdicament conjunts i totals entre sistemes. Defineix toleràncies i excepcions de negoci. Prova una desconnexió i la recuperació posterior amb dades de prova. El contracte d’integració ha d’incloure la freqüència esperada i reconèixer els límits reals de les fonts.
Exemple: una comanda amb resposta tardana
Suposem que el CRM envia una comanda aprovada a l’ERP amb una referència de negoci estable. La connexió caduca abans de rebre confirmació. Hi ha dues possibilitats: l’ERP no l’ha creat, o l’ha creat i la resposta s’ha perdut. El connector consulta per aquesta referència o utilitza el mecanisme de repetició segura que permeti l’API. Només després decideix si reintenta. Si no ho pot comprovar, marca el resultat com a incert i demana revisió; no genera una segona comanda a cegues. L’operador ha de veure referència, estat, últim intent i acció proposada. L’exemple descriu un requisit de disseny; la implementació depèn de les capacitats verificades de cada API.
Proves que ha de superar el connector
Utilitza un conjunt amb comanda nova, duplicada, cancel·lada, incompleta i rebutjada per regles de negoci. Afegeix pèrdua de connexió abans i després d’una possible creació. Verifica que els duplicats no creen registres addicionals, que l’estat incert és visible i que una correcció es pot reprocessar de manera controlada. Compara les referències dels dos sistemes, no només els totals. Comprova també permisos revocats, límits d’ús i protecció de credencials. Documenta què es recupera automàticament i què requereix una persona. L’escenari no està acceptat si només funciona quan totes les respostes arriben a temps.
Punts clau
- La recuperació forma part de la integració, no és un afegit posterior.