Cambio ERP: separare per fasi i flussi collegati

Separi i singoli flussi di dati prima di cambiarne la destinazione durante una migrazione ERP. Un’applicazione che conosce ovunque i campi interni del vecchio ERP è più difficile da migrare in modo selettivo. Un punto di consegna chiaro può limitare questa dipendenza.

Scegliere un percorso delimitato

In un’azienda fittizia un portale crea ordini nel vecchio ERP e ne riceve lo stato in seguito. Per il primo passo della migrazione si sceglie esattamente questo percorso. Le altre connessioni restano nello stato concordato. Registri anche le risposte e l’elaborazione differita; un ordine già inviato può ancora generare una risposta dal vecchio sistema dopo il passaggio.

Microsoft descrive la sostituzione graduale tramite un intermediario nel pattern Strangler Fig. È una decisione architetturale che richiede impegno. È particolarmente adatta quando il vecchio e il nuovo percorso possono coesistere per un certo periodo.

Mantenere stabile il significato di business alla consegna

Nell’esempio il portale trasmette una richiesta di creazione ordine con un proprio identificatore di operazione. Un adattatore la traduce nel formato dell’ERP previsto. L’identificatore interno dell’ordine ERP viene associato all’operazione del portale.

La tabella è una nostra ripartizione d’esempio. Due ERP non devono eseguire indipendentemente la stessa richiesta come nuovo ordine. Un confronto tecnico in parallelo richiede un percorso protetto separatamente, senza effetti duplicati in produzione.

Verificare traduzione e mappatura dei dati

Un’Anti-Corruption Layer traduce tra modelli di sistemi diversi. Può risiedere dentro un’applicazione. Nel nostro esempio identificatori di articoli e clienti e significato delle quantità devono essere adatti al nuovo ERP. Lo stesso nome di campo non basta a dimostrarlo.

Prima del passaggio verifichi un nuovo ordine e una notifica di stato tardiva per un vecchio ordine. Controlli che entrambi arrivino all’operazione corretta del portale. La migrazione dei dati esistenti deve considerare le stesse mappature.

Pianificare il ritorno con gli effetti sui dati

Definisca quando le nuove richieste possono tornare al vecchio percorso. Chiarisca separatamente il destino degli ordini già creati nel nuovo ERP. Ripristinare il vecchio instradamento dell’intermediario non li trasferisce né elimina automaticamente. Verifichi anche chi monitora e mantiene l’intermediario; non deve diventare un collo di bottiglia inosservato.

La vecchia connessione viene rimossa solo dopo aver chiarito le risposte aperte e le dipendenze restanti. La sua fine dipende così dalle operazioni interessate, oltre che dalla data della prima nuova richiesta riuscita.

Fonti

• Microsoft Learn: Strangler Fig pattern

• Microsoft Learn: Anti-Corruption Layer pattern