Architekturleitfaden für die WooCommerce-ERP-Integration 2026

Die Anbindung eines hochvolumigen WooCommerce-Onlineshops an ein Enterprise-Resource-Planning-System (ERP) zählt zu den anspruchsvollsten Aufgaben in der E-Commerce-Softwarearchitektur. Sobald Produktkataloge mehr als fünfzigtausend Artikelnummern (SKUs) umfassen, das tägliche Bestellaufkommen in die Tausende geht und Lagerbestände über mehrere Vertriebskanäle synchron gehalten werden müssen, versagen traditionelle synchrone Punkt-zu-Punkt-Schnittstellen. Direkte HTTP-Aufrufe zwischen den beteiligten Systemen führen unter Last unweigerlich zu kaskadierenden Gateway-Timeouts, Datenbank-Deadlocks, Überlastungen durch Webhook-Spitzen und fatalen Überverkäufen im Checkout.

Für Entwicklungsteams, die eine robuste E-Commerce-Integrationspipeline planen oder modernisieren möchten, bieten unsere spezialisierten WooCommerce-ERP-Integrationsdienste fundierte Unterstützung bei Konzeption und Implementierung. Dieser Leitfaden analysiert die architektonischen Grundlagen, Kompatibilitätsmatrizen führender ERP-Plattformen, praxiserprobte PHP 8.4-Implementierungen und operative Betriebshandbücher für unternehmenskritische Umgebungen.

#Architekturfundament: Entkoppelte ereignisgesteuerte Integration

In einfachen WooCommerce-Installationen lösen Shop-Ereignisse häufig direkte synchrone HTTP-Anfragen an ein ERP-System aus. Wenn beispielsweise ein Kunde eine Bestellung abschließt, feuert der Hook woocommerce_checkout_order_processed und startet eine synchrone cURL-Verbindung zu SAP S/4HANA, Microsoft Dynamics 365 oder Comarch Optima.

Dieses synchrone Muster birgt fundamentale Risiken für die Systemstabilität:

[Kunden-Browser] 
      │ (1) Checkout absenden
      ▼
[WooCommerce / PHP-FPM Worker] ──(2) Synchroner HTTP POST──▶ [ERP-Endpunkt (Langsam / Überlastet)]
      │                                                              │
      │ ◀───(3) HTTP 504 Gateway Timeout (60s blockiert)─────────────┘
      ▼
[Kunde sieht Fehlerseite] ──▶ Mehrfaches Klicken ──▶ DB-Deadlocks & verwaiste Bestellungen

Wenn das ERP-System nächtliche Stapelverarbeitungen durchführt, Datenbankwartungen laufen oder Netzwerkverzögerungen auftreten, steigt die Antwortzeit von 200 Millisekunden auf dreißig Sekunden oder mehr. Da PHP-FPM-Worker synchron an offene Netzwerk-Sockets gebunden sind, ist der Thread-Pool des Webservers innerhalb kürzester Zeit vollständig belegt. Neue Besucher, die lediglich Katalogseiten aufrufen oder den Warenkorb aktualisieren möchten, erhalten unmittelbar HTTP 504 Gateway Timeout-Fehler. Wird die Verbindung zudem nach der Beleganlage im ERP, aber vor dem Empfang der Quittung in WooCommerce unterbrochen, führen unkoordinierte Wiederholungen zu doppelten Rechnungen und doppelten Lagerreservierungen.

#Das entkoppelte Event-Broker-Muster

Zur Gewährleistung unternehmensweiter Stabilität müssen Ereigniserzeugung und Ereignisverarbeitung strikt voneinander getrennt werden. Der Onlineshop und das ERP-System kommunizieren ausschließlich über einen zwischengeschalteten Event-Broker.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                       ENTKOPPELTE EREIGNISGESTEUERTE PIPELINE                           │
│ (Vollständige Entkopplung zwischen Frontend-Checkout und Backend-ERP-Verarbeitung)      │
└─────────────────────────────────────────────────────────────────────────────────────────┘

 ┌─────────────────────────┐                     ┌─────────────────────────┐
 │    WooCommerce-Shop     │                     │       ERP-System        │
 │ (Bestell- & Kundendaten)│                     │ (Zentrallager & Finanz) │
 └────────────┬────────────┘                     └────────────▲────────────┘
              │                                               │
    (1) Schnelle Erfassung                          (4) Gesteuerter Export
       (Nicht-blockierend)                             (API-Ratenbegrenzung)
              ▼                                               │
 ┌────────────────────────────────────────────────────────────┴───────────────────────────┐
 │                               NACHRICHTEN-BROKER & PUFFER                              │
 │                           (Redis Streams / Cloudflare Queues)                          │
 │                                                                                        │
 │   ┌──────────────────────┐  ┌──────────────────────┐  ┌────────────────────────────┐   │
 │   │  orders.incoming     │  │  inventory.delta     │  │  dead.letter.queue (DLQ)   │   │
 │   │  [Event 1][Event 2]  │  │  [SKU 101][SKU 102]  │  │  [Fehlerhafte Payloads]    │   │
 │   └──────────┬───────────┘  └──────────┬───────────┘  └─────────────▲──────────────┘   │
 └──────────────┼─────────────────────────┼────────────────────────────┼──────────────────┘
                │                         │                            │
      (2) Stream auslesen mit   (5) Bestände schreiben        (3) Maximale Versuche
         Consumer Group            mittels InnoDB-Sperren        überschritten
                ▼                         ▼                            │
 ┌─────────────────────────────────────────────────────────────────────┴──────────────────┐
 │                           WP-CLI DAEMON WORKER POOL (PHP 8.4)                          │
 │                                                                                        │
 │  - Signal-Handling (SIGTERM/SIGINT)        - Idempotenz-Prüfung (Redis SETNX)          │
 │  - Speichermanagement (wp_cache_flush)     - Exponentielles Backoff mit Full Jitter    │
 └────────────────────────────────────────────────────────────────────────────────────────┘

1. Schnelle Ereigniserfassung: Beim Kaufabschluss schreibt WooCommerce ein kompaktes JSON-Payload in einen Redis Stream (orders.incoming) und bestätigt dem Kunden den Auftrag in weniger als 15 Millisekunden.
2. Asynchrone Hintergrundverarbeitung: Eine Flotte überwachter Hintergrund-Worker unter WP-CLI liest Nachrichten kontinuierlich und dosiert gemäß der Aufnahmekapazität des ERP-Systems aus.
3. Kontrollierter Gegendruck (Backpressure): Drosselt das ERP eingehende Anfragen oder ist wegen Wartungsfenstern offline, stauen sich die Aufträge sicher im Redis-Puffer, ohne die Reaktionszeiten des Onlineshops zu beeinträchtigen.
4. Idempotente Verarbeitung: Jedes Ereignis trägt einen eindeutigen, deterministischen Idempotenzschlüssel. Bricht ein Worker unerwartet ab, setzt der nachfolgende Prozess die Verarbeitung an der exakten Stelle fort, ohne Duplikate in der Datenbank zu erzeugen.

#Praxisnahe ERP-Systemmatrix und Protokollkompatibilität

Verschiedene ERP-Plattformen unterscheiden sich grundlegend in ihren Netzwerkmodellen, Nebenläufigkeitsgrenzen, Authentifizierungsmechanismen und Durchsatzraten. Eine erfolgreiche Integration erfordert maßgeschneiderte Adapter für das jeweilige Zielsystem.

Die folgende Matrix vergleicht vier führende ERP-Systeme, die im europäischen und internationalen E-Commerce häufig mit WooCommerce vernetzt werden:

#Integrationsmuster für SAP S/4HANA

In SAP S/4HANA-Umgebungen erfolgt der Zugriff in der Regel über die SAP Business Technology Platform (SAP BTP) in Verbindung mit dem SAP Cloud Connector. Synchrone Einzelbelegbuchungen über standardisierte OData v4-Dienste (API_SALES_ORDER_SRV) weisen eine durchschnittliche Netzwerklatenz von 450 bis 800 Millisekunden pro Aufruf auf.

Für hochfrequente Onlineshops ist die Umstellung auf asynchrone Batch-Verfahren zwingend:

• JSON-Batching: Bis zu einhundert Kundenaufträge werden in einem einzigen mehrteiligen OData-Changeset zusammengefasst. Dies minimiert den Overhead von TCP- und TLS-Handshakes und garantiert, dass entweder alle Belege des Pakets gebucht werden oder eine konsistente Rückabwicklung erfolgt.
• Asynchrone IDoc-Schnittstellen: Für initiale Stammdatenimporte oder umfassende Preisaktualisierungen empfiehlt sich die Nutzung klassischer IDoc-Formate (wie ORDERS05 oder MATMAS05), die über Hintergrundjobs in SAP verarbeitet werden.
• Verwaltung logischer Einheiten (SAP LUWs): SAP gewährleistet Datenkonsistenz über Logical Units of Work. Die Integrationsschicht muss die zurückgegebene SAP-Belegnummer erfassen und in einer relationalen Nachschlagetabelle (wp_wc_orders_erp_lookup) mit der WooCommerce-Bestell-ID verknüpfen.

#Comarch ERP Optima und Comarch ERP XL

Comarch Optima ist im mitteleuropäischen Raum weit verbreitet. Da das System ursprünglich für lokale Arbeitsplatzinstallationen auf Microsoft SQL Server konzipiert wurde, stellt die moderne API-Anbindung besondere Anforderungen.

• WebAPI versus COM-Automatisierung: Die Optima WebAPI stellt zwar REST-Endpunkte bereit, instanziiert intern jedoch COM-Objekte (Optima.dll). Dadurch muss jeder Worker-Thread im Single-Threaded Apartment (STA) initialisiert werden (CoInitialize).
• Lizenz- und Thread-Management: Versuchen mehrere PHP-Prozesse gleichzeitig unkoordiniert Bestellungen über COM-Instanzen anzulegen, führen Windows-Ressourcengrenzen und Lizenzsperren zu sofortigen Verbindungsabbrüchen.
• Staging-Tabellen-Architektur: Für B2B-Plattformen mit zehntausenden Bestandsänderungen pro Stunde empfiehlt sich ein Architekturmuster, bei dem Lesevorgänge direkt über schreibgeschützte SQL-Snapshots in Redis repliziert werden. Schreibvorgänge für Bestellungen laufen über dedizierte, sequenzielle Windows-Worker-Daemons.

#InsERT Subiekt GT und Subiekt nexo PRO

InsERT Subiekt GT nutzt die Sfera-Schnittstelle (COM/OLE Automation), während das modernere Subiekt nexo PRO über ein mächtiges .NET SDK und WebAPI-Funktionen verfügt.

• Besonderheiten bei Subiekt GT Sfera: Sfera-Aufrufe laufen synchron im Kontext des Windows-Desktops. Tritt ein unerwarteter Fehler auf oder öffnet sich im Hintergrund ein modales Dialogfenster, friert der COM-Thread dauerhaft ein. Der Integrationsdienst muss als robuster Windows-Dienst (z. B. in C# oder Go) mit Watchdog-Überwachung und harten 30-Sekunden-Timeouts implementiert werden.
• Vorteile von Subiekt nexo PRO: Nexo PRO unterstützt echte Multithreading- und Asynchron-Verarbeitung. Bei der Produktkatalogsynchronisation sollten Deltas anhand der Zeitstempel-Spalte Zmieniono abgefragt werden, um ausschließlich geänderte Datensätze zu übertragen.

#Microsoft Dynamics 365 Business Central

Die Cloud-Version von Business Central setzt strenge Governance-Regeln durch:

• Mandanten-Ratenbegrenzungen: Microsoft limitiert API-Aufrufe auf 600 Anfragen pro Minute pro Umgebung. Bei Überschreitung liefert der Server unmittelbar HTTP 429 Too Many Requests mit einem Retry-After-Header.
• $batch-Endpunkte: Anstelle von 50 Einzelaufrufen sendet die Middleware eine POST-Anfrage an https://api.businesscentral.dynamics.com/v2.0/{tenant}/production/api/v2.0/$batch mit einem Array von Sub-Requests, die sequenziell innerhalb der Cloud-Sandbox abgearbeitet werden.
• Ereignisbasierte Benachrichtigungen: Anstatt Business Central permanent nach Bestandsänderungen zu durchsuchen (Polling), registriert die Middleware Webhook-Abonnements (Graph Notifications) und stößt bei Eingang zielgerichtete Delta-Synchronisationen an.

#Fehlertoleranzmuster für Transaktionen mit hohem Volumen

Unternehmensintegrationen müssen unter der Prämisse entworfen werden, dass Netzwerkverbindungen, externe Server und Datenbankknoten jederzeit temporär ausfallen können. Fünf Architekturmuster bilden das Fundament für einen stabilen Betrieb.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                          IDEMPOTENZ & FEHLERTOLERANZ-MUSTER                             │
└─────────────────────────────────────────────────────────────────────────────────────────┘

 Eingehende Anfrage / Webhook
          │
          ▼
 ┌───────────────────────────────────┐
 │ X-Idempotency-Key Header auslesen │
 └─────────────────┬─────────────────┘
                   │
                   ▼
 ┌───────────────────────────────────┐
 │ Atomare Redis-Sperre setzen:      │
 │ SETNX lock:idempotency:{key}      │
 └─────────┬─────────────────────────┘
           │
     ┌─────┴────────────────────────┐
     │ Schlüssel erworben (Neu)     │ Schlüssel existiert (Duplikat / In Arbeit)
     ▼                              ▼
 ┌───────────────────────────┐  ┌─────────────────────────────────────────────────┐
 │ Status: PROCESSING        │  │ Status prüfen:                                  │
 │ (TTL: 86400 Sekunden)     │  │ - Wenn 'PROCESSING': HTTP 409 Conflict melden   │
 └─────────┬─────────────────┘  │ - Wenn 'COMPLETED': Gecachte Antwort liefern    │
           │                    └─────────────────────────────────────────────────┘
           ▼
 ┌───────────────────────────┐
 │ Geschäftslogik ausführen  │
 │ (Transaktion + DB-Write)  │
 └─────────┬─────────────────┘
           │
     ┌─────┴────────────────────────┐
     │ Erfolg                       │ Fehler (Exception / Timeout)
     ▼                              ▼
 ┌───────────────────────────┐  ┌─────────────────────────────────────────────────┐
 │ Redis-Status aktualisieren│  │ Exponentielles Backoff mit Full Jitter berechnen│
 │ COMPLETED + Cache-Payload │  │ sleep = min(T_max, T_base * 2^retry) + rand()   │
 └─────────┬─────────────────┘  └─────────────┬───────────────────────────────────┘
           │                                  │
           ▼                                  ▼
 ┌───────────────────────────┐  ┌─────────────────────────────────────────────────┐
 │ HTTP 200/201 zurückgeben  │  │ Wenn Versuche < 5: Zurück in verzögerte Queue   │
 └───────────────────────────┘  │ Wenn Versuche >= 5: In Dead Letter Queue (DLQ) │
                                └─────────────────────────────────────────────────┘

#1. Idempotente Anforderungsverarbeitung (X-Idempotency-Key)

In asynchronen Systemen sind Netzwerk-Wiederholungen und duplizierte Webhooks unvermeidlich. Ohne Idempotenzsicherung könnte das erneute Eintreffen eines Webhooks zur Zahlungsbestätigung einen Auftrag doppelt anlegen oder eine doppelte Erstattung veranlassen.

Jede schreibende Anfrage erfordert einen eindeutigen Schlüssel:

• Schlüsselerzeugung: Der Client übergibt einen X-Idempotency-Key-Header (UUIDv4) oder der Server errechnet einen deterministischen Hash: sha256(order_id + status + timestamp).
• Atomare Statussperre: Vor der Ausführung setzt der Worker eine atomare Sperre in Redis:

  SET lock:idempotency:{hash} "PROCESSING" NX EX 86400

• Statusauflösung:
  • Wird der Schlüssel erfolgreich angelegt (OK), beginnt die Verarbeitung. Nach erfolgreichem Abschluss wird der Wert auf "COMPLETED:{response_json}" aktualisiert.
  • Existiert der Schlüssel bereits mit dem Wert "PROCESSING", bearbeitet ein anderer Worker die Anfrage parallel. Das Duplikat bricht mit HTTP 409 Conflict ab oder wartet auf Freigabe.
  • Beginnt der Wert mit "COMPLETED:", überspringt der Worker die Ausführung und liefert direkt das gespeicherte Ergebnis mit dem Header X-Cache-Lookup: HIT zurück.

#2. Redis Streams für garantierte Nachrichtenreihenfolge

Klassische Redis-Listen (LPUSH/RPOP) verlieren Nachrichten, wenn ein Worker-Prozess nach dem Auslesen, aber vor dem Datenbank-Commit abstürzt. Redis Streams bieten vollständige Transaktionssicherheit über Consumer Groups:

• Nachrichten anhängen (XADD): Ereignisse werden mit monoton steigenden Zeitstempel-IDs in ein persistentes Log geschrieben.
• Consumer Groups (XREADGROUP): Mehrere Worker teilen sich die Last eines Streams, ohne Nachrichten doppelt zu verarbeiten. Redis erfasst exakt, welcher Worker welchen Datensatz beansprucht hat.
• Explizite Bestätigung (XACK): Eine Nachricht wird erst dann aus der Liste ausstehender Einträge (PEL) entfernt, wenn der Worker alle Datenbankänderungen erfolgreich committet und XACK aufgerufen hat.
• Wiederaufnahme verwaister Nachrichten (XCLAIM): Stürzt ein Worker ab, identifizieren überlebende Instanzen via XPENDING alle Nachrichten, die länger als 60 Sekunden unbestätigt blieben, und übernehmen diese per XCLAIM.

#3. Dead Letter Queues (DLQ) und exponentielles Backoff mit Full Jitter

Integrationsfehler müssen differenziert behandelt werden:

1. Flüchtige Fehler: Netzwerk-Timeouts, HTTP 502/503/504-Gateway-Fehler, HTTP 429-Drosselungen und temporäre MySQL-Deadlocks. Diese müssen automatisch wiederholt werden.
2. Dauerhafte Fehler: HTTP 400 Bad Request, 404 Not Found, 422 Unprocessable Entity, ungültige Steuerkonfigurationen oder Schema-Fehler. Diese dürfen nicht automatisch wiederholt werden.

Für flüchtige Fehler verhindert exponentielles Backoff mit zufälliger Streuung (Full Jitter) das synchrone Einstürmen hunderter Worker auf ein wieder anlaufendes ERP-System:

$$\text{Intervall} = \min\left(T_{\text{max}}, T_{\text{base}} \times 2^{\text{Versuch}}\right)$$

$$\text{Wartezeit} = \text{random}\left(0, \text{Intervall}\right)$$

Schlägt eine Nachricht auch nach fünf Versuchen fehl, wandert sie in die Dead Letter Queue (dlq:erp_sync). Der DLQ-Datensatz enthält das vollständige Payload, den Exception-Stacktrace, den HTTP-Statuscode und den Fehlerzeitstempel für das anschließende Replay.

#Datenbank-Parallelitätskontrolle und Bestandssperren

Bei exklusiven Produkt-Launches oder Rabattaktionen greifen oft hunderte Kunden zeitgleich auf denselben Restbestand zu. Lesen zwei Threads parallel denselben Bestand aus, verifizieren die Verfügbarkeit und dekrementieren anschließend, kommt es unweigerlich zu physischen Überverkäufen.

#Pessimistisches Sperren: MySQL InnoDB SELECT FOR UPDATE

WooCommerce speichert Bestände in der MySQL-Datenbank. Die Standardmethoden get_stock_quantity() und wc_update_product_stock() sind unter Hochlast unsicher, da sie nicht-sperrende Lesezugriffe durchführen.

Pessimistische Sperren verhindern Race Conditions, indem sie die betroffene Zeile für die Dauer der Transaktion exklusiv blockieren:

Transaktion A (Kunde 1)                         Transaktion B (Kunde 2)
───────────────────────                         ───────────────────────
START TRANSACTION;                              START TRANSACTION;

SELECT stock_quantity                           SELECT stock_quantity
FROM wp_wc_product_meta                         FROM wp_wc_product_meta
WHERE product_id = 4500                         WHERE product_id = 4500
FOR UPDATE;                                     FOR UPDATE;
──▶ Zeile durch Transaktion A gesperrt              ──▶ WARTET (Thread blockiert)

Bestand prüfen: 5 verfügbar.
Abzug: 5 - 1 = 4.

UPDATE wp_wc_product_meta
SET stock_quantity = 4
WHERE product_id = 4500;

COMMIT; ── Sperre freigegeben ────────────────▶ Sperre an Transaktion B erteilt!
                                                Bestand prüfen: 4 verfügbar.
                                                Abzug: 4 - 1 = 3.
                                                UPDATE wp_wc_product_meta SET ...
                                                COMMIT;

Wichtige Architekturregel: Halten Sie niemals eine offene Datenbanktransaktion während eines externen HTTP-API-Aufrufs zum ERP. Sperren Sie die Zeile, aktualisieren Sie die lokalen Tabellen, committen Sie die Transaktion innerhalb von maximal 50 Millisekunden und übergeben Sie die ERP-Synchronisation an die asynchrone Warteschlange.

#Optimistische Nebenläufigkeitskontrolle (OCC)

Bei moderater Schreiblast bietet optimistische Nebenläufigkeitskontrolle höheren Durchsatz ohne Lese-Blockaden.

Hierbei wird eine Versionsspalte (version) in der Produkttabelle genutzt:

UPDATE wp_wc_product_meta 
SET stock_quantity = stock_quantity - :kaufmenge,
     version = version + 1
WHERE product_id = :produkt_id 
   AND version = :erwartete_version 
   AND stock_quantity >= :kaufmenge;

Wurde der Artikel zwischenzeitlich modifiziert, schlägt die Bedingung fehl und es werden null Zeilen aktualisiert. Die Anwendung erkennt dies und wiederholt den Vorgang mit der neuen Versionsnummer.

#Produktionsreife Codebeispiele: PHP 8.4 Hintergrund-Queue-Consumer und WP-CLI-Daemon

Die folgenden praxiserprobten Komponenten illustrieren die Implementierung robuster Integrationsmuster unter modernem PHP 8.4.

#Listing 1: Hintergrund-Queue-Consumer als WP-CLI-Daemon (QueueConsumerCommand.php)

Dieser Befehl wird als dauerhafter Systemdienst unter Systemd oder Supervisord betrieben. Er konsumiert Redis Streams, verarbeitet Nachrichten in Batches, reagiert auf POSIX-Signale und steuert den Speicherverbrauch aktiv.

<?php
declare(strict_types=1);

namespace WPPoland\ErpIntegration\Cli;

use WP_CLI;
use Redis;
use Throwable;

if (!defined('ABSPATH')) {
    exit;
}

/**
 * Überwachter WP-CLI-Hintergrund-Daemon für die asynchrone ERP-Synchronisation.
 */
class QueueConsumerCommand
{
    private const STREAM_KEY = 'erp:stream:orders';
    private const CONSUMER_GROUP = 'erp_sync_group';
    private const BATCH_SIZE = 10;
    private const BLOCK_TIMEOUT_MS = 2000;
    private const MAX_MEMORY_BYTES = 134217728; // 128 MB Limit vor geordnetem Neustart

    private Redis $redis;
    private string $consumerName;
    private bool $shouldRun = true;

    public function __construct()
    {
        $this->consumerName = 'worker_' . gethostname() . '_' . getmypid();
        $this->initRedis();
        $this->registerSignalHandlers();
    }

    /**
     * Einstiegspunkt für: wp erp-queue consume
     */
    public function __invoke(array $args, array $assocArgs): void
    {
        WP_CLI::line("Starte ERP-Queue-Consumer-Daemon [{$this->consumerName}] auf PHP " . PHP_VERSION);
        $this->ensureConsumerGroup();

        $processedCount = 0;

        while ($this->shouldRun) {
            // POSIX-Signalverarbeitung
            if (function_exists('pcntl_signal_dispatch')) {
                pcntl_signal_dispatch();
            }

            try {
                $messages = $this->redis->xReadGroup(
                    self::CONSUMER_GROUP,
                    $this->consumerName,
                    [self::STREAM_KEY => '>'],
                    self::BATCH_SIZE,
                    self::BLOCK_TIMEOUT_MS
                );

                if (empty($messages) || !isset($messages[self::STREAM_KEY])) {
                    $this->reclaimOrphanedMessages();
                    $this->checkMemoryThreshold();
                    continue;
                }

                foreach ($messages[self::STREAM_KEY] as $messageId => $payload) {
                    $this->processMessage((string) $messageId, $payload);
                    $processedCount++;
                }

                $this->checkMemoryThreshold();
            } catch (Throwable $e) {
                WP_CLI::error("Unbehandelte Ausnahme in der Consumer-Schleife: " . $e->getMessage(), false);
                sleep(2); // Drosselung bei Infrastrukturproblemen
            }
        }

        WP_CLI::success("ERP-Queue-Consumer nach Verarbeitung von {$processedCount} Nachrichten sauber beendet.");
    }

    private function processMessage(string $messageId, array $payload): void
    {
        $orderId = isset($payload['order_id']) ? (int) $payload['order_id'] : 0;
        $idempotencyKey = $payload['idempotency_key'] ?? '';

        if ($orderId <= 0 || empty($idempotencyKey)) {
            WP_CLI::warning("Fehlerhaftes Payload in Nachricht {$messageId}. Weiterleitung an DLQ.");
            $this->routeToDlq($messageId, $payload, 'Validierungsfehler: order_id oder idempotency_key fehlt');
            $this->redis->xAck(self::STREAM_KEY, self::CONSUMER_GROUP, [$messageId]);
            return;
        }

        // Idempotenz-Sperre in Redis prüfen
        $lockKey = "erp:lock:idemp:{$idempotencyKey}";
        $acquired = $this->redis->set($lockKey, 'PROCESSING', ['NX', 'EX' => 86400]);

        if (!$acquired) {
            $status = (string) $this->redis->get($lockKey);
            if (str_starts_with($status, 'COMPLETED')) {
                WP_CLI::line("Ereignis {$idempotencyKey} bereits abgeschlossen. Bestätige Quittung.");
                $this->redis->xAck(self::STREAM_KEY, self::CONSUMER_GROUP, [$messageId]);
                return;
            }
            WP_CLI::line("Ereignis {$idempotencyKey} wird aktuell von anderem Worker verarbeitet. Überspringe.");
            return;
        }

        try {
            // Ausführung der ERP-Synchronisationslogik
            $this->syncOrderToErp($orderId, $payload);

            // Als abgeschlossen markieren und im Stream bestätigen
            $this->redis->set($lockKey, 'COMPLETED:' . time(), ['EX' => 86400]);
            $this->redis->xAck(self::STREAM_KEY, self::CONSUMER_GROUP, [$messageId]);
            WP_CLI::line("Bestellung #{$orderId} erfolgreich synchronisiert [Msg: {$messageId}]");
        } catch (Throwable $e) {
            WP_CLI::warning("Fehler bei Synchronisation von Bestellung #{$orderId}: " . $e->getMessage());
            $this->redis->del($lockKey); // Sperre für Wiederholung freigeben

            $attempts = isset($payload['_retry_count']) ? ((int) $payload['_retry_count']) + 1 : 1;
            if ($attempts >= 5) {
                $this->routeToDlq($messageId, $payload, $e->getMessage());
                $this->redis->xAck(self::STREAM_KEY, self::CONSUMER_GROUP, [$messageId]);
            } else {
                // Erneut in Warteschlange einreihen
                $payload['_retry_count'] = $attempts;
                $this->redis->xAdd(self::STREAM_KEY, '*', $payload);
                $this->redis->xAck(self::STREAM_KEY, self::CONSUMER_GROUP, [$messageId]);
            }
        }
    }

    private function syncOrderToErp(int $orderId, array $payload): void
    {
        $order = wc_get_order($orderId);
        if (!$order) {
            throw new \RuntimeException("WooCommerce-Bestellung #{$orderId} nicht in Datenbank gefunden.");
        }

        // ERP-Client-Adapter aufrufen (z. B. SAP oder Dynamics REST API)
        // $this->erpClient->createSalesOrder($order);
    }

    private function reclaimOrphanedMessages(): void
    {
        // Ausstehende Nachrichten prüfen, die älter als 60 Sekunden sind
        $pending = $this->redis->xPending(self::STREAM_KEY, self::CONSUMER_GROUP, '-', '+', 5);
        if (empty($pending)) {
            return;
        }

        $staleIds = [];
        foreach ($pending as $entry) {
            $messageId = $entry[0];
            $idleMs = $entry[2];
            if ($idleMs > 60000) {
                $staleIds[] = $messageId;
            }
        }

        if (!empty($staleIds)) {
            $claimed = $this->redis->xClaim(
                self::STREAM_KEY,
                self::CONSUMER_GROUP,
                $this->consumerName,
                60000,
                $staleIds,
                ['JUSTID']
            );
            WP_CLI::line(count($claimed) . " verwaiste Nachricht(en) von abgestürzten Workern übernommen.");
        }
    }

    private function routeToDlq(string $messageId, array $payload, string $reason): void
    {
        $dlqEntry = [
            'original_id' => $messageId,
            'payload' => json_encode($payload, JSON_THROW_ON_ERROR),
            'failure_reason' => $reason,
            'failed_at' => (new \DateTimeImmutable('now', new \DateTimeZone('UTC')))->format(\DateTimeInterface::ATOM),
            'consumer' => $this->consumerName,
        ];
        $this->redis->xAdd('erp:stream:dlq', '*', $dlqEntry);
        WP_CLI::error("Nachricht {$messageId} in DLQ verschoben: {$reason}", false);
    }

    private function checkMemoryThreshold(): void
    {
        // WordPress-Objekt-Cache und SQL-Query-Log bereinigen
        wp_cache_flush();
        global $wpdb;
        $wpdb->queries = [];
        if (function_exists('gc_collect_cycles')) {
            gc_collect_cycles();
        }

        $memoryUsed = memory_get_usage(true);
        if ($memoryUsed >= self::MAX_MEMORY_BYTES) {
            WP_CLI::line("Speicherlimit erreicht (" . round($memoryUsed / 1048576, 2) . " MB). Starte Prozess geordnet neu...");
            $this->shouldRun = false;
        }
    }

    private function registerSignalHandlers(): void
    {
        if (!function_exists('pcntl_signal')) {
            return;
        }
        pcntl_signal(SIGTERM, function () {
            WP_CLI::line("SIGTERM empfangen. Beende aktuellen Batch vor dem Exit...");
            $this->shouldRun = false;
        });
        pcntl_signal(SIGINT, function () {
            WP_CLI::line("SIGINT empfangen. Fahre Daemon herunter...");
            $this->shouldRun = false;
        });
    }

    private function initRedis(): void
    {
        $this->redis = new Redis();
        $this->redis->connect('127.0.0.1', 6379, 2.5);
    }

    private function ensureConsumerGroup(): void
    {
        try {
            $this->redis->xGroup('CREATE', self::STREAM_KEY, self::CONSUMER_GROUP, '0', true);
        } catch (Throwable) {
            // Gruppe existiert bereits
        }
    }
}

#Listing 2: Sicherer Webhook-Endpunkt mit HMAC-Validierung (WebhookController.php)

Dieser REST-API-Controller empfängt ERP-Benachrichtigungen (wie Bestandsänderungen), validiert SHA-256 HMAC-Signaturen in konstanter Ausführungszeit, überprüft Zeitstempel-Toleranzen und reiht Ereignisse in unter 20 ms in Redis Streams ein.

<?php
declare(strict_types=1);

namespace WPPoland\ErpIntegration\Api;

use WP_REST_Controller;
use WP_REST_Request;
use WP_REST_Response;
use WP_Error;
use Redis;
use Throwable;

if (!defined('ABSPATH')) {
    exit;
}

class WebhookController extends WP_REST_Controller
{
    protected $namespace = 'erp-sync/v1';
    protected $rest_base = 'webhook';

    private const WEBHOOK_SECRET_OPTION = 'erp_webhook_hmac_secret';
    private const MAX_TIMESTAMP_SKEW_SECONDS = 300; // 5-Minuten-Zeitfenster gegen Replay-Angriffe

    public function register_routes(): void
    {
        register_rest_route($this->namespace, '/' . $this->rest_base, [
            [
                'methods' => 'POST',
                'callback' => [$this, 'handleIncomingWebhook'],
                'permission_callback' => [$this, 'validateHmacSignature'],
            ],
        ]);
    }

    /**
     * Validiert HMAC-Signatur und Zeitstempel in konstanter Rechenzeit.
     */
    public function validateHmacSignature(WP_REST_Request $request): bool|WP_Error
    {
        $signatureHeader = $request->get_header('x-erp-signature-256');
        $timestampHeader = $request->get_header('x-erp-timestamp');

        if (empty($signatureHeader) || empty($timestampHeader)) {
            return new WP_Error(
                'rest_forbidden',
                'Erforderliche Authentifizierungs-Header fehlen: X-ERP-Signature-256 oder X-ERP-Timestamp.',
                ['status' => 401]
            );
        }

        // Zeitstempel prüfen, um Replay-Angriffe zu verhindern
        $requestTime = (int) $timestampHeader;
        $currentTime = time();
        if (abs($currentTime - $requestTime) > self::MAX_TIMESTAMP_SKEW_SECONDS) {
            return new WP_Error(
                'rest_forbidden',
                'Webhook-Zeitstempel weicht mehr als 300 Sekunden von der Serverzeit ab.',
                ['status' => 403]
            );
        }

        $rawBody = $request->get_body();
        $secret = (string) get_option(self::WEBHOOK_SECRET_OPTION, '');

        if (empty($secret)) {
            return new WP_Error('rest_error', 'Server-HMAC-Secret ist nicht konfiguriert.', ['status' => 500]);
        }

        $signedPayload = "t={$timestampHeader}.{$rawBody}";
        $expectedSignature = hash_hmac('sha256', $signedPayload, $secret);

        // Timing-sicherer Zeichenkettenvergleich
        if (!hash_equals($expectedSignature, $signatureHeader)) {
            return new WP_Error(
                'rest_forbidden',
                'Ungültige kryptografische HMAC-Signatur.',
                ['status' => 403]
            );
        }

        return true;
    }

    /**
     * Nicht-blockierende Erfassung und Pufferung in Redis.
     */
    public function handleIncomingWebhook(WP_REST_Request $request): WP_REST_Response|WP_Error
    {
        $params = $request->get_json_params();
        if (empty($params) || !is_array($params)) {
            return new WP_Error('rest_bad_request', 'Ungültiger JSON-Body.', ['status' => 400]);
        }

        $eventId = $request->get_header('x-idempotency-key') ?: wp_generate_uuid4();
        $eventType = sanitize_text_field((string) ($params['event_type'] ?? 'inventory_delta'));

        try {
            $redis = new Redis();
            $redis->connect('127.0.0.1', 6379, 1.0);

            // In Redis Stream für Hintergrundverarbeitung schreiben
            $streamPayload = [
                'event_id' => $eventId,
                'event_type' => $eventType,
                'received_at' => (string) microtime(true),
                'payload_json' => json_encode($params, JSON_THROW_ON_ERROR),
            ];

            $messageId = $redis->xAdd('erp:stream:incoming_webhooks', '*', $streamPayload);

            return new WP_REST_Response([
                'status' => 'accepted',
                'message_id' => $messageId,
                'event_id' => $eventId,
            ], 202);
        } catch (Throwable $e) {
            return new WP_Error(
                'rest_internal_error',
                'Fehler beim Einreihen des Webhooks: ' . $e->getMessage(),
                ['status' => 500]
            );
        }
    }
}

#Listing 3: Atomare Bestandsreduktion mit SELECT FOR UPDATE (StockManager.php)

Dieser Datenbankdienst verwaltet Lagerabzüge bei Bestellungen in WooCommerce. Er nutzt MySQL-InnoDB-Transaktionen, Zeilensperren und automatische Deadlock-Wiederholungen.

<?php
declare(strict_types=1);

namespace WPPoland\ErpIntegration\Database;

use wpdb;
use RuntimeException;
use InvalidArgumentException;
use Throwable;

if (!defined('ABSPATH')) {
    exit;
}

class StockManager
{
    private wpdb $db;
    private const MAX_DEADLOCK_RETRIES = 3;

    public function __construct()
    {
        global $wpdb;
        $this->db = $wpdb;
    }

    /**
     * Zieht Bestände atomar unter Verwendung exklusiver Zeilensperren ab.
     *
     * @param int $productId ID des Produkts oder der Variante
     * @param int $quantityToDeduct Positive Abzugsmenge
     * @return int Verbleibender Lagerbestand
     * @throws RuntimeException Bei unzureichendem Bestand oder anhaltendem Deadlock
     */
    public function deductStockAtomically(int $productId, int $quantityToDeduct): int
    {
        if ($quantityToDeduct <= 0) {
            throw new InvalidArgumentException("Die Abzugsmenge muss größer als null sein.");
        }

        $attempt = 0;

        while ($attempt < self::MAX_DEADLOCK_RETRIES) {
            $attempt++;

            try {
                $this->db->query('START TRANSACTION');

                // Exklusive Zeilensperre auf den Bestands-Metadatenwert anfordern
                $query = $this->db->prepare(
                    "SELECT meta_value FROM {$this->db->postmeta} 
                     WHERE post_id = %d AND meta_key = '_stock' 
                     FOR UPDATE",
                    $productId
                );

                $currentStockRaw = $this->db->get_var($query);

                if ($currentStockRaw === null) {
                    throw new RuntimeException("Bestandseintrag für Produkt-ID {$productId} nicht gefunden.");
                }

                $currentStock = (int) $currentStockRaw;

                if ($currentStock < $quantityToDeduct) {
                    $this->db->query('ROLLBACK');
                    throw new RuntimeException(
                        "Nicht genügend Bestand. Angefordert: {$quantityToDeduct}, Verfügbar: {$currentStock}"
                    );
                }

                $newStock = $currentStock - $quantityToDeduct;

                // Neuen Bestand in der Datenbank speichern
                $this->db->update(
                    $this->db->postmeta,
                    ['meta_value' => (string) $newStock],
                    ['post_id' => $productId, 'meta_key' => '_stock'],
                    ['%s'],
                    ['%d', '%s']
                );

                // Status bei Nullbestand auf 'outofstock' setzen
                if ($newStock === 0) {
                    $this->db->update(
                        $this->db->postmeta,
                        ['meta_value' => 'outofstock'],
                        ['post_id' => $productId, 'meta_key' => '_stock_status'],
                        ['%s'],
                        ['%d', '%s']
                    );
                }

                $this->db->query('COMMIT');

                // WooCommerce-Objekt-Caches nach erfolgreichem Commit leeren
                wp_cache_delete($productId, 'post_meta');
                if (function_exists('wc_delete_product_transients')) {
                    wc_delete_product_transients($productId);
                }

                return $newStock;
            } catch (Throwable $e) {
                $this->db->query('ROLLBACK');

                // MySQL Deadlock Fehler 1213 abfangen
                $isDeadlock = str_contains($e->getMessage(), 'Deadlock found') ||
                              ($this->db->last_error && str_contains($this->db->last_error, '1213'));

                if ($isDeadlock && $attempt < self::MAX_DEADLOCK_RETRIES) {
                    // Exponentielles Backoff mit Jitter vor dem Wiederholungsversuch
                    $backoffUs = (int) (pow(2, $attempt) * 10000 + random_int(1000, 5000));
                    usleep($backoffUs);
                    continue;
                }

                throw new RuntimeException(
                    "Bestandstransaktion in Datenbank fehlgeschlagen [Versuch {$attempt}]: " . $e->getMessage(),
                    0,
                    $e
                );
            }
        }

        throw new RuntimeException("Maximale Anzahl an Deadlock-Wiederholungen für Produkt {$productId} überschritten.");
    }
}

#Durchgängiges Abgleichsverfahren und Beilegung von Split-Brain-Zuständen

Selbst bei strikter Nutzung von Transaktionswarteschlangen und Idempotenz-Schlüsseln führen externe Einflüsse — wie manuelle Filialverkäufe am POS, Warenrücksendungen im Lager oder das Einspielen von Datenbank-Backups — im Laufe der Zeit zu Datenabweichungen zwischen WooCommerce und dem ERP.

Eine professionelle Integrationsarchitektur erfordert daher automatisierte Abgleichsroutinen sowie unmissverständliche Governance-Regeln zur Datenhoheit.

#Governance-Regeln zur Single Source of Truth

Um konkurrierende bidirektionale Aktualisierungen auszuschließen, müssen die Systemgrenzen eindeutig definiert werden:

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           SPLIT-BRAIN-GOVERNANCE-MODELL                                 │
└─────────────────────────────────────────────────────────────────────────────────────────┘

 ┌───────────────────────────────────────────────────────────────────────────────────────┐
 │                               ERP-SYSTEM (MASTER-SYSTEM)                              │
 │                                                                                       │
 │  - Physische Lagerbestände (Zentrallager und Außenlager)                              │
 │  - B2B- und B2C-Preislisten, Staffelpreise und Kundengruppenkonditionen               │
 │  - Artikelstammdaten (Basis-SKU, EAN/Barcodes, Zoll- und Steuerklassen)               │
 │  - Fakturierung, Buchhaltung und Hauptbuchführung                                     │
 └───────────────────────────────────────────┬───────────────────────────────────────────┘
                                             │
                        Autoritative Synchronisation in Richtung Shop
                                             │
                                             ▼
 ┌───────────────────────────────────────────────────────────────────────────────────────┐
 │                          WOOCOMMERCE (COMMERCE-FRONTEND)                              │
 │                                                                                       │
 │  - Aktive Warenkörbe, Checkout-Sitzungen und Kaufabsichten                            │
 │  - Marketingtexte, SEO-Metadaten und Kategoriestrukturen                              │
 │  - Temporäre Bestandsreservierungen während des Checkouts (5 Min. TTL)                │
 │  - Kundenkonten und abweichende Lieferadressen                                        │
 └───────────────────────────────────────────────────────────────────────────────────────┘

1. Lagerbestände: Das ERP-System ist das absolute Master-System. Kommt es bei einem Abgleich zu Diskrepanzen zwischen dem Shopbestand und dem ERP-Wert, überschreibt der ERP-Stand immer den WooCommerce-Wert.
2. Preise & Rabatte: Das ERP ist führend. WooCommerce berechnet Steuern und Rabatte für die Warenkorbansicht, das ERP validiert und recalculiert jedoch die finalen Rechnungsbeträge bei der Auftragserstellung.
3. Auftragserfassung: WooCommerce ist führend für die Kaufabsicht. Wurde die Bestellung online autorisiert, hält WooCommerce den primären Datensatz und übergibt ihn an die Queue. Sobald das ERP den Auftrag bestätigt und eine Belegnummer (ERP_DOC_ID) vergibt, übernimmt das ERP die Hoheit für alle weiteren Statusänderungen (Kommissionierung, Versand, Stornierung).

#Zweistufige Abgleichsarchitektur

Ein ganzheitliches Abgleichskonzept arbeitet auf zwei verschiedenen zeitlichen Ebenen:

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                              ZWEISTUFIGE ABGLEICHSSCHLEIFEN                             │
└─────────────────────────────────────────────────────────────────────────────────────────┘

 ┌───────────────────────────────────────────────────────────────────────────────────────┐
 │ STUFE 1: KONTINUIERLICHER STÜNDLICHER DELTA-ABGLEICH                                  │
 │ (Hohe Frequenz, schlankes Datenvolumen, schnelle Erkennung)                           │
 │                                                                                       │
 │  Abfrage an ERP & WooCommerce:                                                        │
 │  WHERE updated_at >= NOW() - INTERVAL 90 MINUTE                                       │
 │  ──▶ Geänderte SKUs und Aufträge ermitteln ──▶ In Prioritätswarteschlange einreihen   │
 └───────────────────────────────────────────────────────────────────────────────────────┘

 ┌───────────────────────────────────────────────────────────────────────────────────────┐
 │ STUFE 2: NÄCHTLICHER KRYPTOGRAFISCHER PRÜFSUMMEN-AUDIT                                │
 │ (Vollständige Katalogintegrität, Blockvergleich, automatisierte Reparatur)            │
 │                                                                                       │
 │  WooCommerce-Katalog (Block 01: SKUs 00001 - 00500) ──▶ SHA-256: e3b0c442...          │
 │                                                                  │                    │
 │                                                            [Hash-Vergleich]           │
 │                                                                  │                    │
 │  ERP-Katalog         (Block 01: SKUs 00001 - 00500) ──▶ SHA-256: e3b0c442...          │
 │                                                                                       │
 │  - Bei ÜBEREINSTIMMUNG: Block verifiziert. Weiter mit Block 02.                       │
 │  - Bei ABWEICHUNG: Gezielter Einzelabgleich nur für die 500 SKUs aus Block 01.        │
 └───────────────────────────────────────────────────────────────────────────────────────┘

#Stufe 1: Stündlicher Delta-Abgleich

Der stündliche Delta-Abgleich fragt beide Systeme nach Entitäten ab, die innerhalb der letzten 90 Minuten modifiziert wurden (wodurch sich ein 30-minütiges Überlappungsfenster ergibt).

• WooCommerce durchsucht wp_wc_orders nach date_updated_gmt >= (NOW() - INTERVAL 90 MINUTE).
• Der ERP-Adapter fragt geänderte Belegköpfe und Bestandsbewegungen ab.
• Der Abgleichsdienst vergleicht Statuspaare. Fehlt ein Auftrag oder weicht ein Status ab, wird der Beleg automatisch in die hochpriorisierte Reparatur-Queue eingereiht.

#Stufe 2: Nächtlicher kryptografischer Prüfsummenabgleich

Der zeilenweise Vergleich von einhunderttausend Artikeln über Netzwerkschnittstellen erzeugt enorme Bandbreiten- und Datenbanklasten. Stattdessen wird ein blockweises kryptografisches Hashing eingesetzt:

1. Der gesamte Artikelkatalog wird lexikografisch sortiert und in Blöcke von jeweils 500 SKUs unterteilt (z. B. Block 001: SKUs A0001 bis A0500).
2. Für jeden Block wird ein SHA-256-Hash über die sortierten Textrepräsentationen der Werte gebildet: $$\text{Hash} = \text{SHA256}\left(\sum_{i=1}^{500} \text{SKU}_i + \text{Preis}_i + \text{Bestand}_i\right)$$
3. Das ERP generiert parallel identische Block-Hashes.
4. Die Integrationsschicht vergleicht die 200 resultierenden Block-Hashes.
5. Stimmen 198 Hashes überein, sind 99.000 Artikel mathematisch garantiert synchron.
6. Nur die beiden abweichenden Blöcke (insgesamt 1.000 Artikel) werden zur granularen Reparatur heruntergeladen. Dies reduziert das Datenvolumen um 99 Prozent.

#GoBD-Verfahrensdokumentation, DATEV-Übergabe und E-Rechnung

Die deutsche Besonderheit an einer WooCommerce-ERP-Kopplung ist nicht technischer, sondern beweisrechtlicher Natur. Die GoBD verlangen für jedes steuerrelevante Verfahren eine Verfahrensdokumentation, und eine bidirektionale Synchronisation ist ein solches Verfahren. Sie müssen also nicht nur eine funktionierende Warteschlange bauen, sondern beschreiben können, wie sie arbeitet.

Drei GoBD-Grundsätze wirken unmittelbar auf das Design der Queue:

Der dritte Punkt hat eine Folge, die Teams regelmäßig übersehen. Wenn ein Auftrag nach den Wiederholungsversuchen in der Dead Letter Queue landet, ist er damit steuerlich nicht verschwunden. Die DLQ braucht eine dokumentierte Aufarbeitung mit Verantwortlichem und Frist, sonst entsteht genau die Belegfolgenlücke, die eine Prüfung beanstandet.

Bei der Übergabe an die Buchhaltung führt in Deutschland kaum ein Weg an DATEV vorbei. Der praktische Fehler ist, den DATEV-Export als weiteren Empfänger derselben Nachricht zu behandeln. Er gehört hinter die Abstimmung, nicht neben sie, weil sonst ein Auftrag exportiert wird, dessen Bestandsbuchung im ERP noch aussteht.

Bei der E-Rechnung verschiebt sich der Ausgabepunkt. Sowohl XRechnung als auch ZUGFeRD setzen auf der europäischen Norm EN 16931 auf, und beide verlangen strukturierte Pflichtfelder, die im WooCommerce-Checkout schlicht nicht erhoben werden: Leitweg-Identifikation im Behördengeschäft, exakte Steuerkategorie je Position, Zahlungsbedingungen in maschinenlesbarer Form.

Daraus folgt eine Architekturentscheidung, die man früh treffen sollte. Der Shop bleibt Bestellsystem, das ERP wird Rechnungssteller. Wer WooCommerce zum Rechnungssteller macht, muss die EN-16931-Pflichtfelder im Shop nachbauen und dort dauerhaft pflegen.

#Fehlerbehebungs-Leitfaden: Lösung von Vorfällen im Produktivbetrieb

Treten im Livebetrieb Störungen auf, müssen Entwicklungsteams anhand klar strukturierter Betriebshandbücher vorgehen.

#Vorfall 1: Fehlgeordnete Webhook-Zustellungen und Race Conditions

• Symptome: Ein Administrator storniert einen Auftrag in WooCommerce. Fünf Minuten später springt der Status plötzlich wieder auf “In Bearbeitung”, da ein verspäteter Status-Webhook des ERPs eingetroffen ist.
• Ursache: Asynchrone Netzwerke garantieren keine strikte Reihenfolge bei der Paketzustellung. Webhook B (gesendet um 14:02 Uhr) traf vor Webhook A (gesendet um 14:00 Uhr) ein.
• Lösungsverfahren:
  1. Ergänzen Sie Webhook-Payloads um einen monotonen Revisions-Zähler (revision_id) oder einen UTC-Zeitstempel.
  2. Führen Sie eine Versionsspalte in wp_wc_orders_erp_lookup.
  3. Führen Sie Datenbank-Updates nur aus, wenn die eingehende Version neuer ist als der gespeicherte Stand:

     UPDATE wp_wc_orders_erp_lookup 
     SET erp_status = :new_status, last_event_version = :incoming_version 
     WHERE order_id = :order_id AND last_event_version < :incoming_version;

  4. Werden null Zeilen aktualisiert, verwerfen Sie den veralteten Webhook mit dem Logeintrag EVENT_SUPERSEDED.

#Vorfall 2: Datenbank-Deadlocks bei Verkaufsaktionen

• Symptome: Kunden erhalten beim Checkout die Meldung “Fehler bei der Bestellabwicklung”. Das MySQL-Error-Log verzeichnet: ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction.
• Ursache: Zwei parallele Transaktionen erwerben dieselben zwei Produkte (Produkt A und Produkt B) in umgekehrter Reihenfolge. Transaktion 1 sperrt Produkt A und wartet auf Produkt B; Transaktion 2 sperrt Produkt B und wartet auf Produkt A.
• Lösungsverfahren:
  1. Etablieren Sie eine kanonische Sperr-Reihenfolge. Sortieren Sie bei Warenkörben mit mehreren Artikeln die Produkt-IDs vor dem Aufruf von SELECT ... FOR UPDATE immer aufsteigend numerisch:

     $productIds = [842, 105, 330];
     sort($productIds, SORT_NUMERIC); // Ergibt: [105, 330, 842]
     foreach ($productIds as $id) {
         $stockManager->deductStockAtomically($id, $cartItems[$id]['qty']);
     }

  2. Da alle konkurrierenden Prozesse die Zeilensperren nun in der identischen Reihenfolge anfordern, sind zirkuläre Deadlocks mathematisch ausgeschlossen.

#Performance-Benchmarking, Überwachung und betriebliche SLAs

Ein zuverlässiger Betrieb setzt eine kontinuierliche Erfassung von Telemetriedaten voraus, um Performance-Einbußen frühzeitig zu erkennen.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                              INTEGRATIONS-MONITORING-STACK                              │
└─────────────────────────────────────────────────────────────────────────────────────────┘

 [WooCommerce PHP Worker]   ──▶ OpenTelemetry Traces ──▶ [Jaeger / Tempo / Datadog]
 [Redis Streams Broker]     ──▶ Prometheus Exporter  ──▶ [Prometheus Server]
 [WP-CLI Daemons]           ──▶ Custom StatsD Gauges ──▶        │
                                                                 ▼
                                                        [Grafana Dashboards]
                                                                 │
                                                        [Alertmanager Alarme]
                                                                 │
                                           ┌─────────────────────┴─────────────────────┐
                                           ▼                                           ▼
                                    [PagerDuty / Opsgenie]                      [Slack Channel]

#Wichtige Metriken und Alarmschwellen

#Nächste Schritte im Engineering

Der Aufbau einer ausfallsicheren WooCommerce-ERP-Schnittstelle verlangt eine konsequente asynchrone Entkopplung, deterministische Idempotenz, transaktionale Parallelitätskontrolle und automatisierte Datenabgleichsprozesse.

Wenn Sie Ihre bestehende E-Commerce-Infrastruktur überprüfen oder eine maßgeschneiderte Integrationsarchitektur für Ihr ERP-System realisieren möchten, informieren Sie sich über unsere WooCommerce-ERP-Integrationsdienste oder sprechen Sie mit unseren erfahrenen WooCommerce-Entwicklern bei WPPoland.