Die Anbindung eines Marktplatzes an einen Shop ist an einem Nachmittag erledigt. Die gleichzeitige Integration von PrestaShop in Etsy und eBay stellt jedoch eine ganz andere Herausforderung dar, da nun drei Systeme jeweils die maßgebliche Artikelnummer für eine SKU für sich beanspruchen, jedes sein eigenes Authentifizierungsmodell verwendet und jedes sein eigenes Datenvolumenlimit durchsetzt.
Der Fehler, der im Produktivbetrieb tatsächlich auftritt, lautet nie „Der API-Aufruf hat nicht funktioniert“. Es handelt sich vielmehr um einen Artikel, der auf eBay überverkauft wurde, weil eine Etsy-Bestellung 400 ms zuvor eingegangen ist. Oder um ein Angebot, das länger online ist, als das Produkt vom letzten Dienstag gelöscht wurde. Auch kann es sich um eine Bestellung handeln, die doppelt importiert wurde, weil ein Webhook erneut versucht hat, sie zu übertragen, während Ihr Mitarbeiter noch eine Transaktion bearbeitete. Die entscheidende Frage ist also nicht, ob PrestaShop mit eBay und Etsy kommunizieren kann – das kann es natürlich –, sondern wie Sie die Synchronisierung gestalten, damit sie auch nach dem Livegang des Shops korrekt bleibt.
1.0 PrestaShop Webservice API vs. Marketplace-Connector-Modul: Wann sollten Sie selbst entwickeln?
Die ehrliche Antwort hängt weniger von Ihren PHP-Kenntnissen ab als davon, wer die Wartungskosten trägt, wenn eBay eine API-Version einstellt.
Die PrestaShop Webservice API ist eine generische CRUD-Schicht für die ObjectModel-Entitäten des Shops. Sie befindet sich unter /api/ und authentifiziert sich mit einem Backoffice-Zugriffsschlüssel, der als HTTP-Basic-Benutzername mit leerem Passwort übermittelt wird ( PrestaShop-Entwicklerdokumentation ). Sie greift auf Produkte, Kombinationen, Lagerbestände und Bestellungen zu und hat keine Kenntnis von Marktplätzen. Etsy-Taxonomie, eBay-Artikelmerkmale, OAuth-Aktualisierung, Angebots-IDs, Wiederholungsrichtlinie und Idempotenzschutz müssen weiterhin von Ihnen implementiert werden.
| Benutzerdefinierte Erweiterung der Webservice-API | Marktplatz-Verbindungsmodul | |
|---|---|---|
| Zeit bis zum ersten synchronisierten Eintrag | Wochen, Authentifizierung, Zuordnung und Warteschlangen haben Priorität. | Stunden bis Tage; inklusive Kartendarstellung. |
| Marketplace-API-Upgrades | Sie verfolgen die Versionshinweise von Etsy und eBay. | Verantwortung des Anbieters, if Der Anbieter bleibt aktiv |
| Datenzuordnungssteuerung | Gesamt- und markenspezifische Attributlogik ist möglich | Begrenzt durch die Mapping-Schnittstelle des Moduls |
| Sync-Architektur | Ihre Wahlmöglichkeit zwischen Warteschlange, Mitarbeitern, Schlössern und Rückhalteoptionen | Üblicherweise crongesteuert; das Echtzeitverhalten variiert |
| Rennbedingungen-Handling | Nur so gut, wie man es baut. | Oft die schwächste Stelle |
| Budgetbegrenzung | Sie besitzen die Token-Buckets und können Prioritäten festlegen. | Undurchsichtig; prüfen Sie, wie das Modul drosselt. |
| Debugbarkeit | Ihre Protokolle, Ihre Korrelations-IDs | Anbieterprotokollformat; die Nachverfolgung pro SKU variiert |
| Laufende Kosten | Entwicklerzeit, auf unbestimmte Zeit | Lizenz plus Upgrade-Reibung |
| Bestens geeignet für | 2 oder mehr Kanäle, komplexe Attribute, individuelle Preisgestaltung | Standardmäßige eBay/Etsy-Synchronisierung, kleine Teams |
In der Praxis ist die schrittweise Vorgehensweise vorteilhafter als die Entweder-oder-Entscheidung: Kaufen Sie den Konnektor, um nachzuweisen, dass der Kanal Umsätze generiert, und entwickeln Sie ihn erst, wenn der Katalog das Mapping-Modell übersteigt. Konnektoren wie Knowbands PrestaShop eBay Marketplace Integration und PrestaShop Etsy Marketplace Integration existieren, weil die erste Ebene – Profile, Kategoriezuordnung, Angebotsstatus, Bestellimport und Statusrückmeldung – in jedem Projekt gleich ist. Welchen Weg Sie auch wählen, die folgenden Kriterien gelten weiterhin: Ein Modul bringt nur diejenigen voran, die sie implementieren.
1.1 Was die Webservice-API nicht für Sie leisten wird
Es werden Datensätze verschoben, aber keine Geschäftslogik ausgeführt. POST /api/orders überspringt PaymentModule::validateOrder(), sodass Lagerbestandsreduzierungen, Rechnungen und E-Mails zum Bestellstatus nicht versendet werden. Es gibt auch kein dokumentiertes Anfragekontingent, was aber nicht bedeutet, dass es keine Obergrenze gibt. Jeder /api/-Aufruf startet das Framework neu, daher sind die PHP-FPM-Worker die eigentliche Grenze, und eine Resynchronisierungsschleife erschöpft diese lange bevor die eBay-Beschränkungen greifen. Ein Ausweg besteht darin, dass ein Modul seine eigenen Webservice-Ressourcen registrieren kann ( Modul-Webservice-Konzepte ) und einen einzigen marketplace_sync-Endpunkt anstelle von acht generischen Aufrufen pro Produkt bereitstellen kann.
2.0 Datenzuordnung: PrestaShop-Kombinationen vs. Etsy-Taxonomie und eBay-Artikelspezifika
Hier verlieren Marktplatzprojekte still und leise Wochen. Die drei Katalogmodelle verwenden nicht nur unterschiedliche Feldnamen; sie sind sich auch uneinig darüber, was ein Produkt ist.
PrestaShop modelliert ein Produkt als verschachtelten Kategorienbaum, bestehend aus einer Standardkategorie-ID (id_category_default) und Kombinationen aus Attributgruppen. eBay benötigt eine einzelne Kategorie-ID (categoryId) sowie Artikelmerkmale, deren Namen, Kardinalität und zulässige Werte pro Kategorie festgelegt und über die Methode `getItemAspectsForCategory` der eBay Taxonomy API abgerufen werden . Etsy benötigt eine Taxonomie-ID aus der eigenen Verkäufer-Taxonomie sowie die Eigenschaften des entsprechenden Knotens und beschränkt die Anzahl der Eigenschaften pro Angebot auf zwei.
Drei Konsequenzen machen sich beim ersten Katalog-Launch bemerkbar:
- Ein Produkt mit drei Attributgruppen: Größe, Farbe, Ausführung. kann keine Es handelt sich um ein einzelnes Etsy-Angebot. Entweder Sie reduzieren eine Dimension auf den Titel oder Sie teilen das Produkt auf, sodass ein PrestaShop-Produkt nun mehreren Etsy-Angebots-IDs zugeordnet wird.
- eBay lehnt eine Veröffentlichung ab, wenn ein erforderliches Element fehlt. Überprüfen Sie daher die Zuordnung pro Kategorie. bevor den Anschub, anstatt es aus einer 400er-Perspektive zu entdecken.
- Beide Marktplätze überarbeiten ihre Taxonomien, was eine fest codierte Kategorie-ID zu einem zukünftigen Ausfallrisiko macht.
2.1 Die SKU als Join-Schlüssel auf jedem Kanal festlegen
Vor Beginn der Zuordnungsarbeiten muss die Identität festgelegt werden. Die PrestaShop-Referenz dient als primärer Synchronisierungsbezeichner, und jede Kombination benötigt einen eigenen (z. B. TSHIRT-BLK-M, TSHIRT-BLK-L, TSHIRT-WHT-M). Die eBay-Inventar-API arbeitet standardmäßig mit SKUs ( eBay Inventory API ), daher ist eine Kombination ohne Referenz nicht synchronisierbar. Überprüfen Sie dies beim Onboarding, nicht bei jedem Push.
2.2 Speichern Sie die Zuordnung als Daten und versionieren Sie sie.
Vermeiden Sie es, mapCategory() in PHP zu schreiben. Mappings sind Geschäftsdaten, die ein Händler bearbeitet, kein Code, den Sie erneut bereitstellen.
-- Illustratives Schema für die Mapping-Ebene
CREATE TABLE ps_mp_category_map (
id_map INT UNSIGNED NOT NULL AUTO_INCREMENT,
Kanal ENUM('etsy','ebay') NOT NULL,
id_category INT UNSIGNED NOT NULL, -- PrestaShop-Kategorie
remote_node VARCHAR(64) NOT NULL, -- etsy taxonomy_id | ebay categoryId
aspects_json TEXT NULL, -- statische Aspekt-Standardwerte
taxonomy_rev VARCHAR(32) NULL, -- eBay-Kategoriebaumversion
PRIMÄRSCHLÜSSEL (id_map),
EINDEUTIGER SCHLÜSSEL channel_cat (channel, id_category)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE ps_mp_listing_link (
id_product INT UNSIGNED NOT NULL,
id_attribute INT UNSIGNED NOT NULL DEFAULT 0, -- 0 = einfaches Produkt
Kanal ENUM('etsy','ebay') NOT NULL,
remote_id VARCHAR(64) NOT NULL, -- listing_id | offerId
remote_sku VARCHAR(64) NOT NULL,
last_pushed_at DATETIME NULL,
PRIMÄRSCHLÜSSEL (id_product, id_attribute, channel),
EINDEUTIGER SCHLÜSSEL chan_remote (Kanal, Remote-ID)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
Speichern Sie die Version des eBay-Kategoriebaums zusammen mit der Zuordnung. Wenn getDefaultCategoryTreeId eine neue Version zurückgibt, muss jede Zeile mit einer veralteten taxonomy_rev neu validiert werden. Dies ist der Unterschied zwischen einer geplanten Neuzuordnung und einem Montag voller Veröffentlichungsfehler.
3.0 Architektur zur Bestandssynchronisierung: Webhooks, zeitgesteuerte Abfrage oder beides
Vergleicht man, was jede Seite tatsächlich ausstößt, hört die Antwort auf, eine Geschmacksfrage zu sein.
| Kanal | Push-Funktion | Abdeckungslücke |
|---|---|---|
| PrestaShop | Keine nativen ausgehenden Webhooks; ein Modul hookt actionUpdateQuantity, actionValidateOrder, actionProductUpdate | Bei direkten SQL-Änderungen oder bestimmten Importpfaden wird nichts ausgelöst. |
| Etsy | Webhooks decken nur vier Bestellereignisse ab: Bestellung bezahlt, Bestellung storniert, Bestellung versendet, Bestellung geliefert (Etsy-Webhaken) | Kein durch eine Quittung erstelltes Ereignis, und kein Bestandsänderungsereignis |
| eBay | Benachrichtigungs-API mit Themenabonnements und HTTPS-Zielen (eBay-Benachrichtigungs-API) | Die Verfügbarkeit von Themen variiert; verwenden Sie getTopics, um sie aufzulisten, anstatt sie anzunehmen. |
Etsy sendet keine Benachrichtigungen, wenn ein Käufer im Checkout die Menge ändert oder eine Quittung erstellt wird. Diese Lücke erfordert regelmäßiges Polling, unabhängig davon, wie gut die Webhook-Verarbeitung ist. Daher gilt die Faustregel: Webhooks für geringe Latenz, Polling für korrekte Daten : Webhooks beschleunigen die Datenverarbeitung, während alle 5–15 Minuten ein Abgleich durchgeführt wird, um Mengen und aktuelle Quittungen erneut zu lesen und die Fehler des beschleunigten Prozesses zu korrigieren. Der Abgleich ist keine Notlösung, die man idealerweise nie benötigt, sondern sorgt letztendlich für korrekte Systemdaten.
Wird stattdessen ein Connector verwendet, erscheint die gleiche Architektur wie bei Cronjobs. Ein Modul, das korrekt installiert, lizenziert und zugeordnet ist, wirkt dennoch fehlerhaft, wenn seine geplante Aufgabe nie ausgeführt wird. Daher gehört die Cron-Verifizierung in die Checkliste für den Produktivstart und nicht in die Hinweise zur Fehlerbehebung.
3.1 Rufen Sie während des Bezahlvorgangs niemals eine Marktplatz-API auf.
// Beispiel: Modul-Hook. Nur Enqueue – hier niemals eine Marketplace-API aufrufen.
public function hookActionUpdateQuantity($params)
{
$sku = $this->resolveSku((int) $params['id_product'], (int) $params['id_product_attribute']);
if (!$sku) {
zurück;
}
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), // fasst Bursts zusammen
'created_at' => date('Ymd H:i:s'),
], false, true, Db::REPLACE); // REPLACE = Letzte Absicht gewinnt
}
Ein HTTP-Aufruf innerhalb des Hooks erhöht die Latenz des Marktplatzes beim Checkout und führt bei langsamer Etsy-Last zu einem Bestellfehler. Daher wird der Hook lediglich in die Warteschlange gestellt. Durch die REPLACE-Anweisung mit einem SKU-spezifischen Deduplizierungsschlüssel werden zwanzig Lagerbewegungen pro Minute in einen einzigen ausgehenden Aufruf mit der aktuellen Menge umgewandelt.
4.0 Wettlaufsituationen, wenn eine Artikelnummer gleichzeitig auf drei Kanälen verkauft wird.
Nehmen wir vier T-Shirts (schwarz, Größe M). Ein eBay-Käufer nimmt zwei, ein Etsy-Käufer eines, der Ladenhändler eines – alles innerhalb von zwei Sekunden. Drei Mitarbeiter werden aktiv, lesen den Lagerbestand, berechnen die Menge und senden die Bestellung. Zwei unabhängige Fehler lauern nun im System.
Relative Arithmetik führt zu Aktualisierungsverlusten. Wenn ein Mitarbeiter „um 2 verringern“ sendet, während ein anderer „um 1 verringern“ sendet, obwohl beide den Wert 4 lesen, wird je nach Reihenfolge 2 oder 3 berechnet. Übertragen Sie immer die absoluten Mengen, die zum Zeitpunkt der Übertragung gelesen wurden. `StockAvailable::getQuantityAvailableByProduct()` ist die einzige verlässliche Quelle, und die Marktmengen sind Projektionen davon und werden niemals in die Arithmetik einbezogen.
Interleaved Push-Anfragen führen zu einem veralteten Endzustand. Worker A liest 2, Worker B liest kurz darauf 1, B sendet 1, dann trifft die langsamere Anfrage von A ein und schreibt 2. eBay bietet nun einen Artikel an, der nicht existiert. Eine SKU-Sperre in Kombination mit einer monotonen Versionsprüfung ist die kostengünstigste Methode, die Reihenfolge sicherzustellen.
// Beispiel: Serialisierung aller Push-Anfragen für eine SKU über alle Kanäle hinweg.
$lockName = 'mp_sku_' . md5($sku);
$db = Db::getInstance();
// MySQL-Advisory-Lock: Wartet bis zu 3 Sekunden, gibt 1 beim Erwerb und 0 bei Timeout zurück.
if (!(int) $db->getValue("SELECT GET_LOCK('" . pSQL($lockName) . "', 3)")) {
$this->requeue($job, 5); // Ein anderer Worker ist für diese SKU zuständig; erneuter Versuch folgt in Kürze
zurück;
}
versuche {
$qty = (int) StockAvailable::getQuantityAvailableByProduct($idProduct, $idAttribute);
$ver = (int) $db->getValue(
'SELECT stock_version FROM ' . _DB_PREFIX_ . 'mp_sku_state WHERE sku = "' . pSQL($sku) . '"'
);
if ($job['version'] < $ver) {
return; // Ein neuerer Push wurde bereits gesendet; dieser wird verworfen.
}
$this->etsy->setQuantity($sku, $qty); // Absolutwert
$this->ebay->setQuantity($sku, $qty); // Absolutwert
$db->execute(
'UPDATE ' . _DB_PREFIX_ . 'mp_sku_state
SET stock_version = stock_version + 1, synced_qty = ' . $qty . ', synced_at = NOW()
WHERE sku = "' . pSQL($sku) . '"'
);
} Endlich {
$db->execute("SELECT RELEASE_LOCK('" . pSQL($lockName) . "')");
}
GET_LOCK ist sitzungsbezogen und erstreckt sich daher über PHP-FPM-Worker und Cron-Prozesse auf derselben Datenbank. Die Sperre wird freigegeben, sobald die Verbindung abbricht, was bei einem Sperrflag in einer Zeile nicht der Fall ist. Bei mehreren Datenbankservern sollte die Sperre in Redis gespeichert und die Versionsspalte als zusätzliche Sicherheitsmaßnahme beibehalten werden.
Das Restrisiko bleibt jedoch auch ohne Sperre bestehen. Zwischen dem Etsy-Kaufabschluss und Ihrer Angebotsabgabe kann eBay dasselbe Produkt rechtmäßig verkaufen. Um dies wirtschaftlich zu minimieren, sollten Sie bei schnell verkäuflichen Artikeln „Verfügbar – 1“ anzeigen und beim letzten Artikel sofort „0“ statt erst beim nächsten Abgleich.
5.0 Wie sich die Ratenbegrenzungen der Etsy-API, der eBay-API und die Obergrenze von PrestaShop gegenseitig beeinflussen
Jedes Budget erscheint für sich genommen großzügig. Bei einer dreifachen Synchronisierung multiplizieren sie sich jedoch mit der Anzahl Ihrer Artikelnummern.
| Kanal | Dokumentierte Grenzwerte | Signale zum Lesen |
|---|---|---|
| Etsy | Pro App festgelegte QPS- und QPD-Quoten in einem gleitenden Fenster; der dokumentierte Standardwert für eine neue App beträgt 10 Anfragen/Sekunde und 10,000 pro 24 Stunden, auf Anfrage erhöhbar (Etsy-Ratenbegrenzungen) | x-Limit-pro-Sekunde, x-Verbleibend-in-dieser-Sekunde, x-Limit-pro-Tag, x-Verbleibend-heute; Wiederholungsversuch nach 429 |
| eBay | Tägliche Aufruflimits pro Anwendung, API und Ressource, die über die Anwendungswachstumsprüfung festgelegt wurden (eBay-API-Aufrufbeschränkungen) | Developer Analytics API getRateLimits – Kontingent, genutzt, verbleibend, Rücksetzfenster |
| PrestaShop | Kein veröffentlichtes Kontingent; begrenzt durch PHP-FPM-Worker und die Startkosten des Frameworks pro /api/-Aufruf. | Ihre eigene 5xx-Rate und FPM-Warteschlangenlänge |
Eine vollständige Resynchronisierung von 3,000 Artikeln erfordert pro Angebot einen Etsy-Bestandseintrag, pro Artikel eine eBay-Angebotsaktualisierung und pro Artikel einen PrestaShop-Lesevorgang. Bei Etsys Standardeinstellung von 10 Abfragen pro Sekunde (QPS) entspricht dies einer fünfminütigen, kontinuierlichen Belastung ohne Puffer für den Bestellabruf – den einzigen Prozess, der unter keinen Umständen unterbrochen werden darf. Drei Regeln sorgen für ein überschaubares Budget:
- Pro Kanal wird ein Token-Bucket betrieben, der von allen Workern gemeinsam genutzt wird. Setzen Sie dies in Redis durch, da ein Limiter pro Prozess Ihre tatsächliche Rate mit der Anzahl der Worker multipliziert.
- Warteschlangen priorisieren. Auftragsabrufe und Bestandsreduzierungen haben Vorrang vor Preisaktualisierungen und Bild-Uploads. Dass das Kontingent für Vorschaubilder verbraucht wird, während gleichzeitig ein Überangebot entsteht, ist ein Designfehler.
- Batch und Differenz. Die Inventar-API von eBay bietet die Möglichkeit, Preise und Mengen in großen Mengen zu aktualisieren. Führen Sie daher Batch-Updates bis zum aktuellen Limit pro Aufruf durch, vergleichen Sie diese dann mit der synchronisierten Menge (synced_qty) und stoppen Sie die Ausgabe des Kontingents, um zu bestätigen, dass 7 immer noch 7 entspricht.
6.0 Authentifizierung: Etsy API OAuth, eBay OAuth 2.0 und PrestaShop API-Schlüssel
Drei Modelle, und nur zwei davon laufen ab.
PrestaShop sendet den Zugriffsschlüssel als HTTP-Basic-Benutzernamen mit leerem Passwort. Es gibt kein Ablaufdatum, keine Aktualisierung und keinen Fehlermodus für Token-Aktualisierung. Das Risiko liegt jedoch in der anderen Richtung, da ein Schlüssel nur dann rotiert, wenn er manuell geändert wird.
Etsy verwendet den OAuth 2.0-Autorisierungscode-Grant mit obligatorischem PKCE: einen Code-Verifizierer mit 43–128 Zeichen und eine S256-Code-Challenge. Zugriffstoken haben eine Gültigkeitsdauer von 3600 Sekunden (expires_in: 3600), Aktualisierungstoken sind 90 Tage gültig ( Etsy-Authentifizierung ). Jede Anfrage benötigt den x-api-key-Header und das Bearer-Token. Das Token-Format ist {user_id}.{token}. Das numerische Präfix gehört zu den Anmeldeinformationen; dessen Entfernung ist ein typischer Anfängerfehler.
eBay stellt Benutzerzugriffstoken mit einer Gültigkeit von 7,200 Sekunden und Aktualisierungstoken mit einer Gültigkeit von 47,304,000 Sekunden, also etwa 18 Monaten, aus ( eBay OAuth-Token ). Anwendungstoken schützen öffentliche Daten, aber für alles, was auf den Lagerbestand eines Verkäufers zugreift, wird das Benutzertoken benötigt.
Der Fehler, der Synchronisierungsaufträge tatsächlich zum Abbruch bringt, ist nicht das Ablaufen des Tokens. Vielmehr bemerken zehn Worker gleichzeitig das Ablaufen des Tokens. Schützen Sie daher die Aktualisierung mit einer Single-Flight-Sperre, überprüfen Sie das gespeicherte Token unter dieser Sperre erneut und aktualisieren Sie die Berechtigung alle zwei Minuten, anstatt reaktiv auf einen 401-Fehler zu reagieren. Speichern Sie das rotierte Aktualisierungstoken im selben Schreibvorgang wie das Zugriffstoken, da ein Absturz zwischen zwei Schreibvorgängen zum Verlust der Berechtigung führt. Benachrichtigen Sie anschließend sowohl bei erfolgreichen als auch bei fehlgeschlagenen Aktualisierungen, da eine Berechtigung, die 24 Stunden lang nicht aktualisiert wurde, selbst dann problematisch ist, wenn keine Fehler aufgetreten sind (siehe Best Practices für eBay OAuth ).
7.0 Synchronisierung von Marktplatzbestellungen: Steuern, Versand, Währung und Idempotenz
Beim Import von Bestellungen stoßen Buchhalter auf Fehler. Eine Marktplatzbestellung ist keine PrestaShop-Bestellung mit anderen Feldnamen, sondern ein abgeschlossenes Finanzdokument. Vier Diskrepanzen müssen behoben werden, bevor Sie den Importer schreiben.
Marktplatzsteuer. Etsy und eBay erheben und führen in vielen Ländern die Umsatzsteuer bzw. Mehrwertsteuer für den Verkäufer ab. Diese Steuer ist zwar in den Zahlungsdaten enthalten, stellt aber weder die Verbindlichkeit noch die Einnahme des Händlers dar. Daher führt die Übernahme dieser Steuer in eine reguläre Steuerregelung zu einer erhöhten Mehrwertsteuererstattung. Ordnen Sie sie einer Nullsteuersatzregelung mit einem separaten Buchungsfeld zu und stimmen Sie die Vorgehensweise anschließend mit dem Steuerberater des Händlers ab.
Versand. Marktplätze senden einen Betrag, der bereits anhand ihrer Versandprofile berechnet wurde. Führen Sie die PrestaShop-Versandregeln nicht erneut aus, da die Summen voneinander abweichen und die Bestellung nicht mit der Auszahlung übereinstimmt. Erstellen Sie stattdessen einen Versanddienstleister pro Kanal und legen Sie die Kosten anhand der Nutzdaten fest.
Währung. Die Nutzdaten enthalten ihre eigene Währung, die Auszahlung kann in einer Drittwährung erfolgen. Speichern Sie den Marktplatzbetrag, den Betrag in der Shopwährung und den beim Import verwendeten Umrechnungskurs, da die Wiederverwendung des heutigen Kurses zum erneuten Drucken einer drei Monate alten Rechnung ein Dokument erzeugt, das zu keinem Dokument passt.
Erstellungspfad. Zuerst wird der Warenkorb erstellt, dann wird PaymentModule::validateOrder() aufgerufen – dies ist der einzige Pfad, der den Lagerbestand verringert, die Rechnung generiert, den Bestellstatus festlegt und die Hooks auslöst, auf die andere Module angewiesen sind.
// Beispiel: idempotenter Marktplatz-Auftragsimport.
$externalId = $channel . ':' . $remoteOrderId;
if (Db::getInstance()->getValue(
'SELECT id_order FROM ' . _DB_PREFIX_ . 'mp_order_link
WHERE external_id = "' . pSQL($externalId) . '"'
)) {
return; // bereits importiert — Webhook-Wiederholung oder überlappende Abfrage
}
$cart = new 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();
foreach ($payload['lines'] as $line) {
$cart->updateQty((int) $line['qty'], (int) $line['id_product'], (int) $line['id_attribute']);
}
$module = Module::getInstanceByName('mpsync');
$module->validateOrder(
(int) $cart->id,
(int) Configuration::get('PS_OS_PAYMENT'),
(float) $payload['total_paid'],
$channel . ' Marketplace',
null
['transaction_id' => $remoteOrderId],
(int) $cart->id_currency,
falsch,
$cart->secure_key
);
Db::getInstance()->insert('mp_order_link', [
'external_id' => pSQL($externalId),
'id_order' => (int) $module->currentOrder,
'imported_at' => date('Ymd H:i:s'),
]);
Erstellen Sie einen eindeutigen Index für external_id. Die obige SELECT-Anweisung ist lediglich ein schneller Pfad; der Index garantiert den Zugriff, da zwei Worker diese Prüfung in derselben Millisekunde durchführen können. Verwenden Sie anschließend für die Seitenaufrufe von eBay getOrders und Etsy Shop Receipts einen persistenten, seit dem letzten Update gespeicherten Cursor anstelle eines festen Offsets, der sich ständig ändert.
Die Idempotenz erstreckt sich auch auf frühere Bestellungen. Ein Produkt-Push besteht aus vier Aufrufen: Inventarartikel erstellen, Angebot erstellen, Bilder hochladen und veröffentlichen. Daher wird der Status jedes einzelnen Schritts anhand von (SKU, Kanal, Schritt) protokolliert und ein Wiederholungsversuch anstelle eines Neustarts ermöglicht. Etsy signiert Webhooks außerdem mit Webhook-ID, Webhook-Zeitstempel und Webhook-Signatur. Daher werden Duplikate anhand der Webhook-ID entfernt und Zeitstempel, die mehr als etwa 300 Sekunden abweichen, verworfen. Allein dieser Header schließt Duplikate von der Wiederholungsklasse aus.
8.0 Überwachung der Synchronisierung eines Produktionsmarktplatzes
Ein Synchronisierungsvorgang, der lautstark fehlschlägt, ist eine Wartungsaufgabe. Ein solcher, der stillschweigend fehlschlägt, ist eine Rückerstattungswarteschlange.
| Protokollieren Sie jeden Vorgang mit | Alarm an |
|---|---|
| Korrelations-ID-übergreifender Webhook → Warteschlange → API-Aufruf | Aktiendivergenz, lokal ≠ entfernt für mehr als N Minuten |
| Artikelnummer, Vertriebskanal, Vorgang, absolute Versandmenge | AuthentifizierungsfehlerBei jedem OAuth-Aktualisierungsfehler wird sofort eine Paging-Nachricht gesendet. |
| Vollständige Anfrage und Antwort für Nicht-2xx-Anfragen, Geheimnisse geschwärzt | Ratenbegrenzungsverbrauch, wenn die verbleibende Tagesquote vor 18:00 Uhr unter 20 % liegt |
| Verbleibendes Ratenlimitbudget pro Kanal | Warteschlangenalterältester unverarbeiteter Auftrag, der älter als 5 Minuten ist |
| Ablaufdatum des Tokens und Zeitstempel der letzten erfolgreichen Aktualisierung | OrdnungslückeNullaufträge von einem Kanal in einem normalerweise ausgelasteten Fenster |
| Abgleichsergebnis: geprüft, repariert, ungelöst | Cron-Stille, ein geplanter Synchronisierungsauftrag, der nicht rechtzeitig ausgeführt wurde |
Zwei Kennzahlen verdienen höchste Priorität. Die Warteschlangendauer ist der Frühindikator, da sie ansteigt, bevor Kunden einen Fehler bemerken. Die Anzahl der Korrekturen nach dem Abgleich ist die Kennzahl für Transparenz: Wenn der 15-Minuten-Durchlauf immer wieder dieselben Artikelnummern korrigiert, ist Ihr Schnellprozess fehlerhaft, und die Abfragen verschleiern dies unbemerkt.
Protokollieren Sie abschließend die absolute Menge der gesendeten Artikel und nicht die Differenz. Wenn ein Händler fragt, warum eBay 3 und PrestaShop 1 angezeigt hat, muss die Antwort allein aus der Protokollzeile ersichtlich sein.
9.0 Fehlerbehebung bei vier PrestaShop-Marktplatz-Synchronisierungsfehlern, denen Sie tatsächlich begegnen werden
9.1 Die Auflistungen zeigen veraltete Mengen an, während die Protokolle den HTTP-Statuscode 200 anzeigen.
Prüfen Sie die Nutzdaten, nicht den Statuscode. Bei Etsy ersetzt eine Aktualisierung des Angebotsbestands die gesamte Bestandsstruktur. Eine unvollständige Struktur kann daher Angebote zurücksetzen, die Sie nie bearbeiten wollten. Bei eBay ist die Aktualisierung eines Bestandsartikels nicht dasselbe wie die Aktualisierung des veröffentlichten Angebots. Das Angebot enthält die verkaufbare Menge. Lesen Sie direkt nach dem Push eine SKU aus und vergleichen Sie die Felder einzeln. Bei einer Connector-basierten Konfiguration gehen Sie zunächst dieselben Schritte durch: Ist das Produkt zugeordnet? Hat es eine gültige Referenz? Ist der Synchronisierungsjob aktiviert? Wurde der Cronjob ausgeführt?
9.2 429s treten nur während der nächtlichen vollständigen Resynchronisierung auf.
Ihr Token-Bucket ist prozessspezifisch, daher laufen acht Cronjobs mit der achtfachen geplanten Rate. Verschieben Sie den Limiter in einen gemeinsam genutzten Speicher. Hinterfragen Sie anschließend die vollständige Resynchronisierung, vergleichen Sie die Werte mit `synced_qty` und übertragen Sie nur die Änderungen. Dadurch sinkt der nächtliche Tokenverbrauch in der Regel um eine Größenordnung. Beachten Sie die Option `retry-after` bei Etsy-429-Fehlern und prüfen Sie die `getRateLimits` von eBay vor der Verarbeitung großer Batches, anstatt mitten im Lauf an die Grenzen zu stoßen.
9.3 Dieselbe Bestellung wird zweimal importiert, im Abstand von mehreren Stunden.
Überlappende Abfragefenster und eine fehlende Einschränkung. Stellen Sie sicher, dass der UNIQUE-Index für external_id existiert, da eine Duplikatsprüfung ohne diesen Index zu einem Race Condition führt. Überprüfen Sie anschließend den Cursor: Ein Poller, der alle 15 Minuten nach „in den letzten 30 Minuten aktualisierten Bestellungen“ fragt, bietet jede Bestellung systembedingt zweimal an. Legen Sie einen Höchststand fest, überlappen Sie diesen bewusst und lassen Sie die Datenbank die Eindeutigkeit sicherstellen.
9.4 Die Synchronisierung eines Kanals wird um 3 Uhr morgens ohne Fehlermeldung abgebrochen.
Meistens liegt es an einem Verlust des Refresh-Tokens. Ein Etsy-Refresh-Token ist stillschweigend über die 90-Tage-Frist hinausgelaufen, oder ein gleichzeitiger Refresh hat das Token zweimal rotiert, und Ihr Worker hat das ungültige Token beibehalten. Überprüfen Sie zunächst die Felder `expires_at` und `last-successful-refresh` des Token-Speichers. Stellen Sie anschließend sicher, dass der Cron-Dienst des Servers oder ein externer Scheduler die Synchronisierungsaufträge überhaupt noch ausführt. Ein gestoppter Scheduler verursacht genau dieses Symptom und genau diese leeren Protokolle.
10.0 Checkliste zur Produktionsbereitschaft für den PrestaShop-Multichannel-Verkauf
Bevor Sie eine Etsy- oder eBay-Integration als abgeschlossen betrachten, sollten Sie diese Liste durchgehen:
- ProdukteJedes synchronisierte Produkt und jede Kombination verfügt über eine eindeutige Referenz, Kategorien werden gültigen Marktplatzknoten zugeordnet, erforderliche Aspekte werden ausgefüllt und Bilder entsprechen den Marktplatzanforderungen.
- InventarPrestaShop ist die maßgebliche Datenquelle, Push-Benachrichtigungen enthalten absolute Mengen hinter einer SKU-Sperre, Push-Benachrichtigungen bei Nullbestand werden sofort versendet und der Abgleich erfolgt nach einem festgelegten Zeitplan.
- BestellungenDie Marktplatz-Bestell-ID wird unter einer eindeutigen Einschränkung gespeichert, die Steuern und Versandkosten des Vermittlers werden bewusst zugeordnet, und Importe werden über validateOrder() abgewickelt.
- API und AuthentifizierungAnmeldeinformationen werden sicher gespeichert, Aktualisierungen erfolgen mit einem Sicherheitsabstand hinter einer Single-Flight-Sperre, und Ratenbegrenzungen werden zwischen den Workern geteilt.
- Cron und ÜberwachungJeder erforderliche Job wird nachweislich ausgeführt, Warteschlangenalter und Abgleichreparaturen sind sichtbar, und Authentifizierungsfehler führen zu einer Warnung anstatt zu einer Protokollzeile.
11.0 Wo anfangen?
Bei der Entwicklung einer PrestaShop-Marktplatzintegration von Grund auf wird die folgende Reihenfolge angewendet, um Nacharbeiten zu vermeiden: SKU-Integrität, Zuordnungstabellen, absolute Mengenübertragung mit einer SKU-spezifischen Sperre, Bestellimport mit einer eindeutigen externen ID, Datenabgleich und zuletzt Webhooks. Webhooks dienen der Optimierung. Ein korrekter Polling-Loop mit Sperren und Idempotenz ist bereits ein zuverlässiges System.
Wenn Sie lieber mit einem funktionierenden Konnektor beginnen und die Entwicklungszeit auf die wirklich spezifischen Anforderungen Ihres Katalogs konzentrieren möchten, bewerten Sie das Modul anhand derselben Liste, Zuordnung, Zeitplanung, Fehlererkennung, Duplikatschutz und Datenabgleich und bestätigen Sie die Cronjobs vor der Live-Schaltung. In jedem Fall ist das Ziel nicht die einmalige Synchronisierung, sondern die fortlaufende Synchronisierung in sechs Monaten.
Haben Sie Fragen zur Performance Ihrer Website oder benötigen Sie Unterstützung bei deren Migration? Unsere Experten helfen Ihnen gerne. Kontaktieren Sie das Knowband-Team noch heute unter [email protected] für zuverlässige E-Commerce-Plugins, die perfekt auf Ihre Bedürfnisse zugeschnitten sind.
