Integrare senza API nel sistema di origine: progettare un passaggio CSV

Scegliere un passaggio disponibile

Verifichi prima se i dati necessari sono accessibili tramite un’esportazione supportata. Il middleware, software intermedio tra i sistemi, elabora questi ingressi; non crea un accesso che il sistema sorgente non offre.

L’ultima opzione richiede di riconoscere in modo affidabile gli elementi utilizzati e il risultato. Microsoft descrive a questo scopo i selettori dell’interfaccia. Dopo modifiche all’interfaccia occorre verificarne di nuovo l’idoneità; una sequenza di clic registrata non dimostra da sola l’acquisizione dei dati.

Registrare un contratto di file dettagliato

Un’azienda di software fittizia sceglie la seconda opzione. Il suo vecchio sistema di rilevazione dei tempi non offre API per le ore approvate, ma permette un’esportazione giornaliera. Un’elaborazione intermedia deve ricavarne una riga da aggiungere a una bozza di fatturazione nell’ERP. Per questo nostro esempio si concordano UTF-8, la virgola come separatore e questa intestazione:

entryId,projectRef,approvedMinutes,approvalState
T-81,PR-42,90,approved

La riga significa che il record sorgente stabile T-81 contiene tempo di lavoro approvato in minuti per il progetto PR-42. Questo è associato esplicitamente al progetto ERP ERP-903. Possono proseguire solo le righe approvate. Campi e identificativi sono una nostra progettazione, non uno schema Odoo o di un altro fornitore. RFC 4180 descrive convenzioni CSV; il contratto concreto di importazione deve essere adatto al prodotto. La documentazione Odoo mostra, per esempio, l’uso di identificativi esterni nelle importazioni e nelle relazioni.

Separare risultati confermati e incerti

Per un trasferimento confermato, l’elaborazione intermedia deve collegare il record sorgente al riferimento di destinazione. Una riga invariata già confermata come acquisita non deve creare un’altra riga di bozza. Se quel record cambia in seguito, si tratta di una correzione di business; il progetto scelto la sospende in attesa di chiarimento.

Se la connessione si interrompe dopo l’invio, la destinazione potrebbe avere già scritto i dati. Prima di riprovare va chiarito lo stato tramite un riferimento di destinazione adeguato. Se la destinazione non permette questa verifica, l’operazione resta incerta e richiede attenzione. Il solo trasporto riuscito del file non conferma una registrazione nell’ERP.

Concordare i risultati attesi prima dell’implementazione

In un ambiente di test adeguato andrebbero verificati questi casi:

• La prima riga approvata crea una riga di bozza di 90 minuti nel progetto associato.

• Una ripetizione identica dopo il successo confermato non crea un’altra riga.

• Un riferimento di progetto sconosciuto rimane aperto con un motivo di chiarimento.

• Lo stesso record con 120 minuti viene sospeso come correzione, senza sovrascrivere in silenzio il valore confermato.

Nell’esempio, il gruppo accetta un’elaborazione giornaliera alle 18:00, nel fuso Europe/Berlin, per successive bozze di fatturazione. Se servono valori aggiornati durante la giornata lavorativa, il passaggio va rivalutato. Responsabilità dell’esportazione, gestione degli errori e riscontro fanno quindi parte dell’accordo.

Fonti

• IETF · RFC 4180 CSV

• Odoo 19 · Export and import data, official source

• Microsoft · Automate using UI elements