Integrazione Eshop con Galaxy ERP: flussi, requisiti e verifiche

Colleghiamo l'Eshop a Galaxy ERP con un flusso specifico e l'interfaccia disponibile nell'installazione. In Galaxy la sincronizzazione corretta si basa sul Web Scenario e sulla continuità dei numeri di revisione. L'Eshop richiede un quadro iniziale di articoli, attributi e scorte, e poi soltanto le modifiche concordate.

In Galaxy la sincronizzazione corretta si basa sul Web Scenario e sulla continuità dei numeri di revisione. L'Eshop richiede un quadro iniziale di articoli, attributi e scorte, e poi soltanto le modifiche concordate. Il checkpoint dell'aggiornamento viene salvato dopo l'applicazione completa dei dati. Le chiamate online per clienti e acquisti vengono organizzate separatamente dagli aggiornamenti massivi del catalogo. Con più società o scenari, la scelta della destinazione è una parte sostanziale della mappatura, non un semplice dettaglio tecnico.

Sync Service offre elenchi di entità sincronizzate e chiamate online di registrazione. Usa numeri di revisione per modifiche ad articoli, attributi, clienti e scorte. Un Web Scenario funzionante è un requisito. La progettazione prevede soprattutto aggiornamenti periodici massivi del catalogo. Quando lo scenario non è quello predefinito, serve il WebScenID corretto. Non promettiamo una sincronizzazione universale in tempo reale.

Un fornitore di attrezzature professionali dispone di scenari B2B e B2C. Il connettore conserva un checkpoint separato per il flusso previsto e invia il WebScenID corretto dove necessario. Se l'aggiornamento si interrompe a metà, riparte dall'ultimo checkpoint completato. Non sposta il puntatore soltanto perché ha ricevuto una risposta. L'acquisto crea la relativa registrazione commerciale nello scenario appropriato, associando cliente e ordine esterno. Così continuità del catalogo e registrazione della vendita possono essere verificate indipendentemente.

Uno scenario critico si presenta quando un aggiornamento massivo si interrompe e il connettore salva prematuramente la nuova revisione. Conserviamo riferimento esterno e ID di destinazione confermato prima di ripetere l'azione. Distinguiamo fallimento dell'accesso, rifiuto operativo e risultato incerto. L'operatore deve poter esaminare il record pertinente e ripristinare lo stato senza ripetere passaggi completati. Concordiamo quali campi compaiano nei log e chi gestisca le attività in sospeso.

Verifichiamo la ripresa dopo un'interruzione, un Web Scenario non predefinito e la creazione di un nuovo cliente. Per ogni caso documentiamo dati iniziali attesi, record di destinazione e stato visto dal cliente. Aggiungiamo un errore di autorizzazione e un'interruzione della risposta. Ripetiamo un evento già confermato e verifichiamo che il risultato operativo non cambi. Il verbale di accettazione definisce il team responsabile e le prove necessarie per chiudere una discrepanza.

Lo studio iniziale conferma: Web Scenario funzionante e WebScenID corretto; accesso API con autorizzazioni aziendali; salvataggio dei checkpoint di revisione e aggiornamento iniziale completo. Prima della produzione documentiamo la mappatura del flusso Snapshot iniziale → catalogo Eshop → Modifiche delle revisioni → checkpoint confermato → Acquisto online → registrazione commerciale Galaxy. Definiamo responsabilità per rinnovo degli accessi, monitoraggio e correzioni. Una modifica alla configurazione del prodotto o alla regola operativa concordata attiva una nuova verifica mirata. Partiamo da questo flusso specifico e aggiungiamo un altro canale dopo averne chiarito responsabilità e scenari di accettazione.