Collegare un marketplace a un negozio è un lavoro di un pomeriggio. Gestire l' integrazione di PrestaShop contemporaneamente su Etsy ed eBay è tutta un'altra storia, perché ora tre sistemi diversi ritengono di possedere il codice articolo ufficiale per un determinato SKU, ognuno utilizza il proprio modello di autenticazione e ognuno impone il proprio limite di richieste.
Il problema che si verifica effettivamente in produzione non è mai "la chiamata API non ha funzionato". Si tratta piuttosto di un'unità venduta in eccesso su eBay perché un ordine Etsy è arrivato 400 ms prima. Si tratta di un'inserzione che è rimasta online più a lungo del prodotto che qualcuno ha eliminato martedì scorso. Si tratta di un ordine importato due volte perché un webhook ha tentato di nuovo l'operazione mentre il tuo operatore era impegnato in una transazione. Quindi la domanda utile non è se PrestaShop può comunicare con eBay ed Etsy, ovviamente può, ma come progettare la sincronizzazione in modo che rimanga corretta anche dopo la pubblicazione del negozio.
1.0 API del servizio web di PrestaShop vs. modulo connettore per marketplace: quando è consigliabile svilupparlo?
La risposta onesta dipende meno dalle tue competenze in PHP e più da chi si fa carico dei costi di manutenzione quando eBay dismette una versione dell'API.
L'API del servizio web di PrestaShop è un livello CRUD generico che si sovrappone alle entità ObjectModel del negozio. Si trova all'indirizzo /api/ e si autentica tramite una chiave di accesso al back-office inviata come nome utente HTTP Basic con password vuota ( documentazione per sviluppatori di PrestaShop ). Consente di accedere a prodotti, combinazioni, disponibilità di magazzino e ordini, ma non ha alcuna conoscenza dei marketplace. La tassonomia di Etsy, le specifiche degli articoli di eBay, l'aggiornamento OAuth, gli ID delle inserzioni, la politica di retry e le protezioni di idempotenza sono tutti aspetti che spettano allo sviluppatore.
| Implementazione personalizzata sull'API del servizio web | modulo di connessione al marketplace | |
|---|---|---|
| Tempo di prima sincronizzazione dell'elenco | Prima vengono le settimane, l'autorizzazione, la mappatura e la gestione delle code. | Da ore a giorni; schermate di mappatura incluse |
| Aggiornamenti dell'API del Marketplace | Puoi seguire le note di rilascio di Etsy ed eBay | Responsabilità del fornitore, if il venditore rimane attivo |
| Controllo della mappatura dei dati | È possibile una logica degli attributi totale per marca | Delimitato dall'interfaccia di mappatura del modulo |
| Architettura di sincronizzazione | La tua scelta di coda, lavoratori, serrature, retromarcia | Solitamente gestito tramite cron; il comportamento in tempo reale varia |
| Gestione delle condizioni di gara | È valido solo quanto lo costruisci | Spesso il punto più debole |
| bilancio del limite di tariffa | Possiedi i secchi di token e puoi dare priorità | Opaco; controlla come il modulo limita |
| Debuggabilità | I tuoi log, i tuoi ID di correlazione | Formato del registro del fornitore; la tracciabilità per SKU varia |
| Costo corrente | Tempo di sviluppo, a tempo indeterminato | Licenza più attrito di aggiornamento |
| Più adatto a | 2 o più canali, attributi complessi, prezzi personalizzati | Sincronizzazione standard eBay/Etsy, piccoli team |
In pratica, la sequenza è preferibile all'alternativa: acquistare il connettore per dimostrare che il canale genera entrate, e poi svilupparlo ulteriormente quando il catalogo supera le capacità del modello di mappatura. Connettori come PrestaShop eBay Marketplace Integration e PrestaShop Etsy Marketplace Integration di Knowband esistono perché il primo livello, ovvero profili, mappatura delle categorie, stato delle inserzioni, importazione degli ordini e flusso di stato, è sempre lo stesso per ogni progetto. Qualunque sia la strada scelta, i criteri seguenti rimangono validi; un modulo sposta solo chi lo implementa.
1.1 Cosa non può fare per te l'API del servizio web
Trasferisce record; non esegue logica di business. La richiesta POST /api/orders salta PaymentModule::validateOrder(), quindi gli decrementi di stock, le fatture e le email sullo stato dell'ordine non vengono mai attivati. Inoltre, non esiste una quota di richieste documentata, il che non è la stessa cosa di un limite massimo, ogni chiamata /api/ avvia il framework, quindi il limite reale è rappresentato dai worker di PHP-FPM e un ciclo di risincronizzazione li esaurisce molto prima che i limiti di eBay diventino effettivi. Una soluzione alternativa può essere d'aiuto: un modulo può registrare le proprie risorse di servizio web ( concetti di servizio web del modulo ) ed esporre un singolo endpoint marketplace_sync invece di otto chiamate generiche per prodotto.
2.0 Mappatura dei dati: combinazioni PrestaShop vs. tassonomia Etsy e specifiche degli articoli eBay
È qui che i progetti di marketplace perdono silenziosamente settimane. I tre modelli di catalogo non si limitano a utilizzare nomi di campo diversi; sono in disaccordo su cosa sia un prodotto.
PrestaShop modella un prodotto come un albero di categorie annidate, un id_category_default e combinazioni generate da gruppi di attributi. eBay richiede un singolo categoryId foglia più le specifiche dell'articolo, i cui nomi, cardinalità e valori consentiti sono dettati per categoria e recuperati tramite il metodo getItemAspectsForCategory dell'API Taxonomy ( API Taxonomy di eBay ). Etsy richiede un taxonomy_id dalla propria tassonomia del venditore più le proprietà di quel nodo e limita le varianti a due proprietà per inserzione.
Tre conseguenze si fanno sentire durante la prima fase di lancio del catalogo:
- Un prodotto con tre gruppi di attributi: dimensione, colore, finitura, non può Si tratta di un'unica inserzione su Etsy. O si comprime una dimensione nel titolo oppure si divide il prodotto, quindi un prodotto PrestaShop ora corrisponde a più ID di inserzioni su Etsy.
- eBay rifiuta la pubblicazione se manca un elemento obbligatorio, quindi convalida la mappatura per categoria. prima la spinta piuttosto che scoprirlo da un 400.
- Entrambi i marketplace rivedono le loro tassonomie, il che renderà l'ID di categoria codificato in modo rigido un problema futuro.
2.1 Imposta lo SKU come chiave di unione su ogni canale
Prima di iniziare qualsiasi lavoro di mappatura, è necessario definire l'identità. Il riferimento PrestaShop deve essere l'identificativo di sincronizzazione principale e ogni combinazione necessita di un proprio, ad esempio TSHIRT-BLK-M, TSHIRT-BLK-L, TSHIRT-WHT-M. L'API di inventario di eBay è progettata per essere indirizzata tramite SKU ( eBay Inventory API ), quindi una combinazione con un riferimento vuoto non è sincronizzabile. È importante verificare questo aspetto in fase di onboarding, non a ogni push.
2.2 Memorizza la mappatura come dati e gestiscine la versione
Evitate di scrivere `mapCategory()` in PHP. Le mappature sono dati aziendali che un commerciante modifica, non codice che dovete ridistribuire.
-- Schema illustrativo per il livello di mappatura
CREATE TABLE ps_mp_category_map (
id_map INT UNSIGNED NOT NULL AUTO_INCREMENT,
canale ENUM('etsy','ebay') NOT NULL,
id_category INT UNSIGNED NOT NULL, -- Categoria PrestaShop
remote_node VARCHAR(64) NOT NULL, -- etsy taxonomy_id | ebay categoryId
aspects_json TEXT NULL, -- impostazioni predefinite degli aspetti statici
taxonomy_rev VARCHAR(32) NULL, -- Versione dell'albero delle categorie di eBay
CHIAVE PRIMARIA (id_map),
CHIAVE UNICA channel_cat (channel, id_category)
) MOTORE=InnoDB DEFAULT SET DI CARATTERI=utf8mb4;
CREATE TABLE ps_mp_listing_link (
id_product INT UNSIGNED NOT NULL,
id_attribute INT UNSIGNED NOT NULL DEFAULT 0, -- 0 = prodotto semplice
canale ENUM('etsy','ebay') NOT NULL,
remote_id VARCHAR(64) NOT NULL, -- listing_id | offerId
remote_sku VARCHAR(64) NOT NULL,
ultimo_inserimento_a DATA/ORA NULL,
CHIAVE PRIMARIA (id_prodotto, id_attributo, canale),
CHIAVE UNICA chan_remote (canale, remote_id)
) MOTORE=InnoDB DEFAULT SET DI CARATTERI=utf8mb4;
Memorizza la versione dell'albero delle categorie di eBay insieme alla mappatura. Quando getDefaultCategoryTreeId restituisce una nuova versione, ogni riga con un taxonomy_rev obsoleto necessita di una nuova convalida, il che fa la differenza tra una rimappatura programmata e un lunedì di errori di pubblicazione.
3.0 Architettura di sincronizzazione dell'inventario: webhook, polling programmato o entrambi
Confrontando ciò che ciascuna parte emette effettivamente, la risposta smette di essere una questione di gusto.
| canale | Capacità di spinta | Lacuna nella copertura |
|---|---|---|
| PrestaShop | Nessun webhook in uscita nativo; un modulo aggancia le azioni actionUpdateQuantity, actionValidateOrder e actionProductUpdate. | Non viene attivato alcun segnale per le modifiche SQL dirette o per alcuni percorsi di importazione |
| Etsy | I webhook coprono solo quattro eventi di ordine: order.paid, order.canceled, order.shipped, order.delivered (Webhook di Etsy) | Nessun evento di creazione della ricevuta e nessun evento di modifica dell'inventario |
| eBay | API di notifica con sottoscrizioni ad argomenti e destinazioni HTTPS (API di notifica di eBay) | La disponibilità degli argomenti varia; enumerare con getTopics invece di presumere |
Etsy non emette alcun segnale quando un acquirente modifica la quantità al momento del pagamento, né quando viene creata una ricevuta. Questa lacuna obbliga all'utilizzo del polling, indipendentemente dalla qualità della gestione dei webhook. La regola generale è quindi: webhook per ridurre la latenza, polling per verificare la veridicità dei dati . I webhook guidano il processo più veloce, mentre una fase di riconciliazione ogni 5-15 minuti rilegge le quantità e le ricevute recenti, correggendo eventuali errori non rilevati. La riconciliazione non è un ripiego da evitare a tutti i costi, ma è ciò che garantisce la correttezza del sistema.
Se si utilizza un connettore, la stessa architettura appare come processi cron. Un modulo installato, concesso in licenza e mappato correttamente sembra comunque non funzionante se la sua attività pianificata non viene mai eseguita, quindi la verifica tramite cron dovrebbe essere inclusa nella checklist di messa in produzione, non nelle note di risoluzione dei problemi.
3.1 Non chiamare mai un'API del marketplace durante il checkout
// Esempio illustrativo: hook del modulo. Solo accodamento: non chiamare mai un'API del marketplace qui.
funzione pubblica hookActionUpdateQuantity($params)
{
$sku = $this->resolveSku((int) $params['id_product'], (int) $params['id_product_attribute']);
se (!$sku) {
ritorno;
}
Db::getInstance()->insert('mp_sync_queue', [
'sku' => pSQL($sku),
'op' => 'stock.push',
'payload' => pSQL(json_encode(['quantity' => (int) $params['quantity']])),
'dedupe_key' => pSQL('stock:' . $sku), // comprime i burst
'created_at' => date('Ymd H:i:s'),
], falso, vero, Db::REPLACE); // REPLACE = l'intento più recente vince
}
Una chiamata HTTP all'interno dell'hook aggiunge latenza del marketplace al checkout e fa fallire l'ordine quando Etsy è lento, quindi l'hook si limita a mettere in coda. REPLACE su una dedupe_key per SKU trasforma quindi venti movimenti di stock in un minuto in una chiamata in uscita che trasporta la quantità corrente.
4.0 Condizioni di gara quando un singolo SKU viene venduto contemporaneamente su tre canali
Prendiamo quattro unità di TSHIRT-BLK-M. Un acquirente di eBay ne prende due, un acquirente di Etsy uno, il negozio fisico uno, il tutto entro due secondi. Tre dipendenti si svegliano, ognuno controlla le scorte, calcola la quantità e invia l'ordine. Due bug indipendenti sono ora in agguato.
L'aritmetica relativa non aggiorna i dati. Un operatore che invia "decremento di 2" mentre un altro invia "decremento di 1" rispetto a un valore letto da entrambi come 4, risulterà in 2 o 3 a seconda dell'ordine. Inviare sempre le quantità assolute lette al momento dell'invio. StockAvailable::getQuantityAvailableByProduct() è l'unica fonte di verità e le quantità del mercato sono proiezioni di essa, mai input per operazioni aritmetiche.
Le operazioni di push interlacciate lasciano uno stato finale obsoleto. Il worker A legge 2, il worker B legge 1 un attimo dopo, B inserisce 1, poi la richiesta più lenta di A arriva e scrive 2. eBay ora pubblicizza un'unità che non esiste. Un blocco per SKU più un controllo monotono della versione è il modo più economico per imporre l'ordinamento.
// Esempio illustrativo: serializzare tutte le notifiche push per un singolo SKU su tutti i canali.
$lockName = 'mp_sku_' . md5($sku);
$db = Db::getInstance();
// Blocco consultivo MySQL: attende fino a 3 secondi, restituisce 1 all'acquisizione, 0 in caso di timeout.
if (!(int) $db->getValue("SELECT GET_LOCK('" . pSQL($lockName) . "', 3)")) {
$this->requeue($job, 5); // un altro worker possiede questo SKU; riprova a breve
ritorno;
}
provare {
$qty = (int) StockAvailable::getQuantityAvailableByProduct($idProduct, $idAttribute);
$ver = (int) $db->getValue(
'SELECT stock_version FROM ' . _DB_PREFIX_ . 'mp_sku_state WHERE sku = "' . pSQL($sku) . '"'
);
se ($job['version'] < $ver) {
ritorno; // è già stata inviata una nuova notifica; scarta questa
}
$this->etsy->setQuantity($sku, $qty); // valore assoluto
$this->ebay->setQuantity($sku, $qty); // valore assoluto
$db->execute(
'AGGIORNA ' . _DB_PREFIX_ . 'mp_sku_state
SET stock_version = stock_version + 1, synced_qty = ' . $qty . ', synced_at = NOW()
DOVE sku = "' . pSQL($sku) . '"'
);
} finalmente {
$db->execute("SELECT RELEASE_LOCK('" . pSQL($lockName) . "')");
}
GET_LOCK ha ambito di sessione, quindi si estende ai processi worker di PHP-FPM e ai processi cron sullo stesso database e viene rilasciato quando la connessione si interrompe, cosa che un flag di blocco in una riga non fa. Su più server di database, sposta il blocco su Redis e mantieni la colonna della versione come backup.
Nessun blocco elimina completamente il rischio residuo. Tra il checkout di Etsy e la tua pubblicazione, eBay può legittimamente vendere lo stesso articolo, quindi per mitigare questo rischio a livello commerciale: pubblica "disponibile - 1" per gli articoli più venduti e pubblica "0" per l'ultimo articolo disponibile immediatamente, anziché al successivo controllo dei dati.
5.0 Come si combinano i limiti di frequenza dell'API di Etsy, i limiti di frequenza dell'API di eBay e il limite massimo di PrestaShop
Ogni budget, preso singolarmente, sembra generoso. Tuttavia, in una sincronizzazione a tre vie, i valori si moltiplicano in base al numero di SKU.
| canale | Limiti documentati | Segnali da leggere |
|---|---|---|
| Etsy | Quote QPS e QPD per app su una finestra scorrevole; il valore predefinito documentato per una nuova app è di 10 richieste/secondo e 10,000 ogni 24 ore, aumentabile su richiesta (limiti tariffari di Etsy) | x-limite-al-secondo, x-rimanenti-in-questo-secondo, x-limite-al-giorno, x-rimanenti-oggi; riprova dopo 429 |
| eBay | Limiti di chiamate giornaliere per applicazione per API e risorsa, aumentati tramite il controllo della crescita dell'applicazione (limiti delle chiamate API di eBay) | API di analisi per sviluppatori getRateLimits — quota, utilizzato, rimanente, finestra di ripristino |
| PrestaShop | Nessuna quota pubblicata; limitato dai worker PHP-FPM e dal costo di avvio del framework per chiamata /api/ | La tua velocità 5xx e la profondità della coda FPM |
Una risincronizzazione completa di 3,000 SKU richiede una scrittura dell'inventario Etsy per ogni inserzione, un aggiornamento dell'offerta eBay per ogni SKU e una lettura PrestaShop per ogni SKU. Con le 10 query al secondo (QPS) predefinite di Etsy, ciò si traduce in un consumo continuo di cinque minuti senza margine di manovra per il poller degli ordini, l'unico processo che non deve mai bloccarsi. Tre regole mantengono il budget gestibile:
- Eseguire un bucket di token per canale, condiviso da ogni worker. Applica questa regola in Redis, perché un limitatore per processo moltiplica la tua velocità effettiva per il numero di worker.
- Dare priorità alle code. Gli ordini evasi e le operazioni di azzeramento delle scorte hanno la precedenza sugli aggiornamenti di prezzo e sul caricamento delle immagini. La quota spesa per le miniature durante una sovra-vendita di birre è un errore di progettazione.
- Lotto e differenza. L'API di inventario di eBay offre aggiornamenti in blocco di prezzi e quantità, quindi raggruppa i dati fino al limite massimo per chiamata corrente, poi confronta con synced_qty e interrompi la spesa della quota per confermare che 7 sia ancora uguale a 7.
6.0 Autenticazione: API Etsy OAuth, eBay OAuth 2.0 e chiavi API PrestaShop
Tre modelli, e solo due di essi scadranno.
PrestaShop invia la chiave di accesso come nome utente HTTP Basic con una password vuota. Nessuna scadenza, nessun aggiornamento, nessuna modalità di errore di aggiornamento del token, il rischio è inverso, poiché una chiave non ruota mai a meno che non la ruoti tu.
Etsy utilizza il protocollo di autorizzazione OAuth 2.0 con PKCE obbligatorio: un code_verifier di 43-128 caratteri e un code_challenge S256. I token di accesso hanno una scadenza di 3600 giorni e i token di aggiornamento durano 90 giorni ( autenticazione Etsy ). Ogni richiesta necessita dell'intestazione x-api-key e del token bearer, e il formato del token è {user_id}.{token}; quel prefisso numerico appartiene alla credenziale e la sua rimozione è un classico bug del primo giorno.
eBay rilascia token di accesso utente validi per 7,200 secondi e token di aggiornamento validi per 47,304,000 secondi, ovvero circa diciotto mesi ( token OAuth di eBay ). I token applicativi coprono i dati pubblici, ma qualsiasi operazione relativa all'inventario di un venditore richiede il token utente.
Il problema che effettivamente interrompe i processi di sincronizzazione non è la scadenza. Si verifica quando dieci processi si accorgono della scadenza contemporaneamente. Pertanto, è consigliabile proteggere l'aggiornamento con un blocco a volo singolo, ricontrollare il token memorizzato sotto tale blocco ed eseguire l'aggiornamento con un margine di due minuti anziché in modo reattivo in caso di errore 401. È opportuno memorizzare il token di aggiornamento ruotato nella stessa operazione di scrittura del token di accesso, poiché un crash tra due scritture comporta la perdita del permesso. Infine, è necessario generare un avviso sia in caso di aggiornamento riuscito che di errore, perché un permesso non aggiornato entro 24 ore rappresenta un problema anche in assenza di errori ( Best Practice OAuth di eBay ).
7.0 Sincronizzazione degli ordini del Marketplace: tasse, spedizione, valuta e idempotenza
L'importazione degli ordini è il momento in cui i contabili individuano gli errori. Un ordine del marketplace non è un ordine PrestaShop con nomi di campo diversi; è un documento finanziario a tutti gli effetti. Quattro discrepanze devono essere risolte prima di poter scrivere il codice per l'importazione.
Imposta per i facilitatori di mercato. Etsy ed eBay raccolgono e versano l'imposta sulle vendite o l'IVA per conto del venditore in molte giurisdizioni. Tale imposta è inclusa nel pagamento, ma non rappresenta né un obbligo né un ricavo per il commerciante, pertanto la sua importazione in una normale regola fiscale gonfia la dichiarazione IVA. È necessario associarla a una regola ad aliquota zero e a un campo contabile separato, quindi confermare il trattamento con il commercialista del commerciante.
Spedizione. I marketplace inviano un importo già calcolato in base ai propri profili di spedizione. Non rieseguire le regole del corriere di PrestaShop, perché i totali divergono e l'ordine non corrisponde al pagamento. Crea invece un corriere per ogni canale e imposta il costo in base al carico.
Valuta. Il payload contiene la propria valuta e il pagamento potrebbe arrivare in una terza. Mantieni l'importo del marketplace, l'importo nella valuta del negozio e il tasso di conversione utilizzati all'importazione, poiché riutilizzare il tasso odierno per ristampare una fattura di tre mesi fa produce un documento che non corrisponde a nulla.
Percorso di creazione. Crea il carrello, quindi chiama PaymentModule::validateOrder() — l'unico percorso che decrementa le scorte, genera la fattura, imposta lo stato dell'ordine e attiva gli hook da cui dipendono gli altri moduli.
// Esempio illustrativo: importazione di un ordine idempotente dal marketplace.
$externalId = $channel . ':' . $remoteOrderId;
se (Db::getInstance()->getValue(
'SELECT id_order FROM ' . _DB_PREFIX_ . 'mp_order_link
DOVE external_id = "' . pSQL($externalId) . '"'
)) {
ritorno; // già importato — riprova webhook o polling sovrapposto
}
$cart = nuovo Cart();
$cart->id_customer = $idCustomer;
$cart->id_currency = (int) Currency::getIdByIsoCode($payload['currency']);
$cart->id_carrier = (int) Configuration::get('MP_CARRIER_' . strtoupper($channel));
$cart->id_address_delivery = $idAddress;
$cart->id_address_invoice = $idAddress;
$cart->add();
per ogni ($payload['lines'] come $line) {
$cart->updateQty((int) $line['qty'], (int) $line['id_product'], (int) $line['id_attribute']);
}
$module = Module::getInstanceByName('mpsync');
$module->validateOrder(
(int) $cart->id,
(int) Configurazione::get('PS_OS_PAYMENT'),
(float) $payload['total_paid'],
$channel . ' Marketplace',
nullo
['transaction_id' => $remoteOrderId],
(int) $cart->id_currency,
falso,
$cart->chiave_sicura
);
Db::getInstance()->insert('mp_order_link', [
'external_id' => pSQL($externalId),
'id_order' => (int) $module->currentOrder,
'importato_al' => data('Ymd H:i:s'),
])?
Aggiungi un indice UNIQUE a external_id. La SELECT di cui sopra è solo un percorso veloce; l'indice è la garanzia, perché due worker possono superare quel controllo nello stesso millisecondo. Quindi, pagina le funzioni getOrders di eBay e le ricevute dei negozi di Etsy utilizzando un cursore updated-since persistente anziché un offset fisso che si sposta a tua insaputa.
L'idempotenza si estende oltre gli ordini. Un push di prodotto prevede quattro chiamate: creazione dell'articolo di inventario, creazione dell'offerta, caricamento delle immagini, pubblicazione. Pertanto, è necessario registrare lo stato di ogni passaggio in base a (sku, canale, passaggio) e consentire a un tentativo di riprendere invece di riavviare. Etsy firma anche i webhook con webhook-id, webhook-timestamp e webhook-signature, quindi è necessario eliminare i duplicati in base al webhook-id e rifiutare i timestamp che differiscono di oltre 300 secondi circa. Questa sola intestazione elimina la classe di tentativi dei duplicati.
8.0 Monitoraggio della sincronizzazione del mercato di produzione
Una sincronizzazione che fallisce rumorosamente indica un'attività di manutenzione. Una che fallisce silenziosamente indica una richiesta di rimborso.
| Registra ogni operazione con | Avviso su |
|---|---|
| ID di correlazione che collega webhook → coda → chiamata API | divergenza di stock, locale ≠ remoto per più di N verbale |
| SKU, canale, operazione, quantità assoluta inviata | Autenticazione fallita, qualsiasi errore di aggiornamento OAuth, paginazione immediata |
| Richiesta e risposta complete per i dati non 2xx, segreti oscurati | Bruciatura del limite di velocitàquota giornaliera rimanente inferiore al 20% prima delle 18:00 |
| Budget rimanente del limite di tariffa per canale | Età della coda, lavoro non elaborato più vecchio di 5 minuti |
| Timestamp di scadenza del token e dell'ultimo aggiornamento riuscito | gap d'ordine, zero ordini da un canale in una finestra normalmente occupata |
| Risultati della riconciliazione: verificato, riparato, non risolto | Silenzio della Cronun'attività di sincronizzazione pianificata che non è stata eseguita in tempo |
Due parametri meritano la massima attenzione. L'età della coda è l'indicatore principale, poiché aumenta prima che i clienti si accorgano di eventuali problemi. Il conteggio delle riparazioni di riconciliazione è il parametro affidabile: quando il passaggio di 15 minuti continua a correggere gli stessi SKU, il percorso rapido è interrotto e il polling lo sta silenziosamente coprendo.
Infine, registra la quantità assoluta inviata anziché la differenza. Quando un venditore chiede perché eBay ha mostrato 3 mentre PrestaShop ha mostrato 1, la risposta deve essere ricavabile direttamente dalla riga di registro.
9.0 Risoluzione dei problemi relativi a quattro errori di sincronizzazione del marketplace PrestaShop che incontrerai effettivamente
9.1 Gli elenchi mostrano quantità obsolete mentre i log mostrano HTTP 200
Controlla il payload, non il codice di stato. Su Etsy, un aggiornamento dell'inventario di un'inserzione sostituisce l'intera struttura dell'inventario, quindi una struttura parziale può reimpostare offerte che non avresti mai dovuto modificare. Su eBay, aggiornare un articolo in inventario non è la stessa cosa di aggiornare l'offerta pubblicata e l'offerta riporta la quantità vendibile. Leggi immediatamente un SKU dopo un push e confronta campo per campo. In una configurazione basata su connettori, percorri prima la stessa catena: il prodotto è mappato? Ha un riferimento valido? Il job di sincronizzazione è abilitato? Il cron job è stato eseguito?
9.2 429 appaiono solo durante la risincronizzazione completa notturna
Il tuo bucket di token è per processo, quindi otto processi cron vengono eseguiti a una velocità otto volte superiore a quella prevista. Sposta il limitatore nella memoria condivisa. Quindi, metti in discussione la risincronizzazione completa stessa, confrontala con synced_qty e invia solo le modifiche, e il consumo notturno di solito si riduce di un ordine di grandezza. Rispetta l'opzione retry-after sugli errori 429 di Etsy e controlla getRateLimits di eBay prima di un batch di grandi dimensioni, invece di bloccarti a metà dell'esecuzione.
9.3 Lo stesso ordine viene importato due volte, a distanza di ore.
Finestre di polling sovrapposte e un vincolo mancante. Verificare l'esistenza dell'indice UNIQUE su external_id, perché una SELECT con controllo dei duplicati senza di esso genera una condizione di gara anziché una condizione di controllo. Quindi, controllare il cursore: un sistema di polling che richiede ogni 15 minuti gli "ordini aggiornati negli ultimi 30 minuti" offre ogni ordine due volte per impostazione predefinita. Mantenere un valore massimo, sovrapporlo deliberatamente e lasciare che il database garantisca l'unicità.
9.4 La sincronizzazione si interrompe per un canale alle 3 del mattino senza errori
Solitamente si tratta di una perdita di refresh token. Un refresh token di Etsy ha superato silenziosamente la sua finestra di 90 giorni, oppure un refresh simultaneo ha ruotato il token due volte e il tuo worker ha mantenuto quello non valido. Controlla prima i timestamp expires_at e last-successful-refresh dell'archivio dei token. Quindi verifica che il servizio cron del server o lo scheduler esterno stiano ancora eseguendo i job di sincronizzazione; uno scheduler arrestato produce esattamente questo sintomo e questi log vuoti.
10.0 Una checklist di preparazione alla produzione per la vendita multicanale di PrestaShop
Prima di considerare conclusa l'integrazione con Etsy o eBay, controlla questa lista:
- ProdottiOgni prodotto e combinazione sincronizzati hanno un riferimento univoco, le categorie corrispondono a nodi validi del marketplace, gli aspetti richiesti vengono compilati e le immagini soddisfano i requisiti del marketplace.
- InventarioPrestaShop è la fonte di verità, le notifiche push gestiscono quantità assolute con un blocco per SKU, le notifiche push a stock zero vengono inviate immediatamente e la riconciliazione viene eseguita secondo una pianificazione.
- OrdiniL'ID dell'ordine del marketplace viene memorizzato con un vincolo di unicità, le tasse e le spese di spedizione del facilitatore vengono mappate in modo specifico e le importazioni vengono eseguite tramite validateOrder().
- API e autenticazioneLe credenziali vengono archiviate in modo sicuro, l'aggiornamento viene eseguito su un margine dietro un blocco a volo singolo e i limiti di velocità sono condivisi tra i worker.
- Cron e monitoraggio, ogni lavoro richiesto viene eseguito in modo verificabile, l'età della coda e le riparazioni di riconciliazione sono visibili e gli errori di autenticazione generano un avviso anziché una riga di registro.
11.0 Da dove cominciare
Nella creazione di un'integrazione marketplace PrestaShop da zero, l'ordine che evita rilavorazioni è il seguente: integrità SKU, tabelle di mappatura, push di quantità assolute dietro un blocco per SKU, importazione degli ordini con un ID esterno univoco, riconciliazione e, per ultimi, webhook. I webhook sono l'ottimizzazione. Un ciclo di polling corretto con blocchi e idempotenza è già un sistema affidabile.
Se preferisci partire da un connettore funzionante e dedicare il tempo di sviluppo a ciò che è effettivamente specifico per il tuo catalogo, valuta il modulo rispetto allo stesso elenco, alla mappatura, alla pianificazione, alla visibilità degli errori, alla protezione dai duplicati, alla riconciliazione e conferma i suoi processi cron prima della messa in produzione. In entrambi i casi, l'obiettivo non è sincronizzare una sola volta, ma che sia ancora sincronizzato tra sei mesi.
Se hai domande o necessiti di assistenza per le prestazioni o la migrazione del tuo sito web, i nostri esperti sono a tua disposizione. Contatta oggi stesso il team di Knowband all'indirizzo [email protected] per plugin eCommerce affidabili e personalizzati in base alle tue esigenze.
