> Produktdaten zwischen SAP oder Infor, Pimcore und Shop synchronisieren: Delta vs. Full Sync, Änderungserkennung, idempotente Importe, Messenger, Ownership, Replays. > > Web page: https://balazscsorba.com/de/blog/pimcore-erp-delta-sync · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/pimcore-erp-delta-sync.md) · [Magyar](https://balazscsorba.com/hu/blog/pimcore-erp-delta-sync.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: Pimcore ERP delta sync, Pimcore developer, Pimcore SAP integration, PIM ERP Schnittstelle, Pimcore SAP Schnittstelle, PIM ERP sync best practices, Pimcore Symfony Messenger, delta sync vs full sync, idempotent import Pimcore, Pimcore Infor integration [Blog](https://balazscsorba.com/de/blog)/Web-Engineering # Pimcore ERP Delta-Sync: Produktdaten zwischen SAP oder Infor, PIM und Shop Produktdaten zwischen SAP oder Infor, Pimcore und Shop synchronisieren: Delta vs. Full Sync, Änderungserkennung, idempotente Importe, Messenger, Ownership, Replays. [Balázs Csorba](https://balazscsorba.com/de/about)·2\. Oktober 2026·12 Min. Lesezeit - Pimcore - SAP integration - PIM ERP sync - Symfony Messenger ![Diagramm: Produktdaten fließen von einem SAP- oder Infor-ERP über einen Delta-Extrakt und eine Message Queue in Pimcore, wo Qualitätsprüfungen laufen, und weiter in den Shop.](https://balazscsorba.com/images/blog/pimcore-erp-delta-sync/cover.webp?v=58260af2c2) ## Das Wichtigste in Kürze - Lege die Ownership pro Attribut fest, bevor du einen Import schreibst: Das ERP besitzt kaufmännische und logistische Daten, das PIM Inhalte und Klassifikation, und kein Feld wird von zwei Systemen geschrieben. - Nutze einen Delta-Sync für den Alltag und einen Full Sync als geplanten Abgleich, nicht als Normalfall. Erkenne Änderungen an der Quelle (SAP Change Pointer, Infor Sync BODs, CDC) und bestätige sie mit einem Content-Hash. - Nachrichten werden mindestens einmal zugestellt, also muss jeder Handler idempotent sein: ein stabiler Schlüssel pro Geschäftsereignis, Upsert statt Insert und ein Hash-Vergleich vor dem Schreiben. - Setze eine Queue zwischen ERP und PIM. In Pimcore ist das Symfony Messenger mit der Queue pimcore\_core und einem Failure Transport, im Produktivbetrieb idealerweise auf RabbitMQ. - Qualitätsprüfungen, eine Failure Queue, die wirklich jemand beobachtet, und ein Replay-Befehl machen aus einem fragilen Import eine betreibbare Pipeline. Prüfe vorab aktuelle Pimcore-Version, Edition und Supportzeitraum. Auf dieser Seite 1. [Warum dieser Sync schwieriger ist, als er aussieht](https://balazscsorba.com/#why-it-is-hard) 2. [Lege zuerst fest, wem welches Attribut gehört](https://balazscsorba.com/#ownership) 3. [Der Datenfluss](https://balazscsorba.com/#data-flow) 4. [Full vs. Delta Sync und wie du eine Änderung erkennst](https://balazscsorba.com/#delta-vs-full) 5. [Idempotente Importe](https://balazscsorba.com/#idempotent-imports) 6. [Queues: Symfony Messenger in Pimcore](https://balazscsorba.com/#queues) 7. [Datenqualitäts-Gates](https://balazscsorba.com/#quality-gates) 8. [Monitoring und Replays](https://balazscsorba.com/#monitoring-replays) 9. [Was du 2026 zu Pimcore prüfen solltest](https://balazscsorba.com/#verify-2026) 10. [Wie ich es in Projekten angehe](https://balazscsorba.com/#my-approach) 11. [Quellen](https://balazscsorba.com/#sources) Fast jedes B2B-Commerce-Projekt, an dem ich arbeite, hat dasselbe Rückgrat: Ein ERP wie SAP oder Infor kennt die Wahrheit über Artikel, Preise und Bestand, ein PIM wie Pimcore macht daraus etwas, das Kunden verstehen, und ein Shop verkauft es. Am Montag sind sich die drei Systeme einig, am Freitag nicht mehr. Wenn der Vertrieb fragt, warum der Shop einen alten Preis zeigt, lautet die Antwort fast nie „der Sync ist kaputt“. Sondern: Niemand hat entschieden, wem das Feld gehört, was als Änderung gilt oder was passiert, wenn eine Nachricht fehlschlägt. Dieser Artikel beschreibt das Design, das ich heute für den Sync zwischen ERP, Pimcore und Shop verwenden würde: zuerst die Ownership, dann ein Delta-Fluss mit einem Full-Abgleich daneben, Änderungserkennung, die sich nicht auf ein einzelnes Signal verlässt, idempotente Handler hinter einer Queue, Qualitätsprüfungen sowie Monitoring und Replays, die den Betrieb ermöglichen. Am Ende steht eine kurze Liste, was du zu Pimcore-Versionen und -Editionen prüfen solltest, bevor du dich festlegst, denn dieses Feld hat sich 2026 bewegt. Wenn du eine KI-Schicht auf sauberen Produktdaten planst, gilt dasselbe Fundament: Strukturierte, verlässliche Katalogdaten sind die Basis für [Agentic-Commerce-Protokolle](https://balazscsorba.com/de/blog/agentic-commerce-protocols-ucp-acp-guide) und [Generative Engine Optimization](https://balazscsorba.com/de/blog/generative-engine-optimization-audit). ## Warum dieser Sync schwieriger ist, als er aussieht Auf dem Papier ist es eine Leitung: aus dem ERP lesen, ins PIM schreiben, in den Shop veröffentlichen. In der Praxis stecken vier Probleme darin. Erstens Volumen und Takt: Ein Materialstamm mit Hunderttausenden Datensätzen lässt sich nicht alle paar Minuten komplett lesen, aber Preise und Bestände ändern sich ständig. Zweitens ist „geändert“ mehrdeutig: Ein ERP-Datensatz kann angefasst werden, ohne dass sich ein für den Shop relevantes Attribut ändert. Drittens scheitern Systeme auf halbem Weg: Ein Netzwerk-Timeout, ein gesperrtes Objekt oder ein Validierungsfehler hinterlässt teils aktualisierte, teils nicht aktualisierte Datensätze. Viertens schreiben oft zwei Systeme dasselbe Feld, und der letzte Schreibzugriff gewinnt zufällig. Jedes dieser Probleme hat eine langweilige, gut verstandene Antwort. Der Sinn des folgenden Designs ist, sie konsequent anzuwenden, damit sich der Sync auf einer Seite erklären und in zehn Minuten debuggen lässt. ## Lege zuerst fest, wem welches Attribut gehört Bevor ich Importcode schreibe, halte ich eine Ownership-Tabelle fest: jede Attributgruppe, welches System der einzige Schreiber ist und in welche Richtung die Daten fließen. Ein Feld hat genau einen Owner. Die anderen Systeme dürfen es lesen, anzeigen oder cachen, aber nie zurückschreiben. Diese eine Regel beseitigt die meisten „Ping-Pong“-Fehler, bei denen ein Import eine manuelle Änderung überschreibt oder ein Redakteur einen Wert korrigiert, der in der nächsten Nacht wieder überschrieben wird. Attributgruppe Owner Richtung Regel Artikelnummer, Basiseinheit, Status, Gewichte, GTIN ERP ERP → PIM Im PIM-Editor schreibgeschützt Preise, Bestand, Verfügbarkeit, kundenspezifische Konditionen ERP ERP → Shop Umgeht oft das PIM oder wird live abgefragt Titel, Beschreibungen, Bilder, Dokumente, Übersetzungen PIM PIM → Shop Nach der Pflege nie mehr aus dem ERP importiert Klassifikation, filterbare Attribute, Varianten, Cross-Selling PIM PIM → Shop Einmal aus dem ERP befüllt, danach im PIM geführt Sortierung, SEO-URL, Merchandising-Flags Shop Bleibt im Shop Nicht zurückgespielt Diese Aufteilung ist typisch, nicht universell. Manche Firmen halten lange Texte im ERP, andere Abmessungen im PIM. Entscheidend ist, dass deine Tabelle existiert, dass sie im Code durchgesetzt wird (der Import hat schlicht kein Mapping für Felder, die ihm nicht gehören) und dass die PIM-Oberfläche ERP-Felder als schreibgeschützt markiert, damit Redakteure nicht versuchen, sie zu ändern. Für die Grauzone, etwa einen Namen, der im ERP beginnt und im PIM veredelt wird, mach die Übergabe explizit: Der ERP-Wert befüllt das Feld einmal, und ein Flag hält fest, dass das PIM es ab dann besitzt. ## Der Datenfluss Die Form, die ich nutze, ist eine kurze Kette mit einer Queue in der Mitte und einem Fehlerpfad daneben. Die ERP-Seite erzeugt Änderungsereignisse; ein dünner Extraktionsschritt normalisiert sie; eine Queue entkoppelt das Tempo des ERP vom Tempo von Pimcore; Pimcore prüft, reichert an und speichert; der Publish-Schritt versorgt den Shop. Der Sync als Kette mit einer Queue in der Mitte. Fehlerpfad, Replay-Werkzeuge und Abgleich laufen daneben und sind Teil des Designs, kein Nachgedanke. Drei Details machen diese Form tragfähig. Erstens ist der Extraktionsschritt die einzige Stelle, die SAP oder Infor kennt: Er spricht IDoc, BOD, OData oder REST und gibt ein einheitliches internes Nachrichtenformat aus. Ein Tausch des ERP oder ein zweites ERP betrifft dann eine Komponente. Zweitens ist die Queue eine echte Queue und keine Tabelle, die du pollst, sodass Back-Pressure und Retries von Infrastruktur gehandhabt werden, die du nicht selbst geschrieben hast. Drittens veröffentlicht das PIM nicht blind: Es hält einen Datensatz zurück, wenn er eine Prüfung nicht besteht, und der Shop sieht nur, was durchgekommen ist. ## Full vs. Delta Sync und wie du eine Änderung erkennst Ein Full Sync liest bei jedem Lauf jeden Datensatz und vergleicht ihn mit dem Bestand. Er ist einfach, heilt sich selbst und ist das richtige Werkzeug für die Erstbefüllung und den regelmäßigen Abgleich. Er ist aber auch langsam und belastet das ERP. Ein Delta Sync überträgt nur, was sich seit dem letzten erfolgreichen Lauf geändert hat. Er ist schnell, hat aber einen Fehlermodus, den ein Full Sync nicht hat: Eine verpasste Änderung bleibt verpasst. Deshalb nutze ich beides: Delta für den Alltag, einen geplanten Full-Abgleich, um Drift zu finden. Die schwierigere Frage ist, woher du weißt, dass sich etwas geändert hat. Es gibt vier gängige Signale, und keines reicht allein. Signal Funktionsweise Stärke Schwäche Änderungszeitstempel Abfrage der seit der letzten Wasserlinie geänderten Datensätze Einfach zu bauen Zeitversatz, rückdatierte Änderungen, keine Information über Löschungen Ereignisse an der Quelle SAP Change Pointer erzeugen IDocs; Infor ION veröffentlicht Sync BODs vom Datenbesitzer Meldet die Änderung selbst, inklusive Löschungen Setup und Aufräumarbeit im ERP nötig Change Data Capture Ein Tool wie Debezium streamt zeilenweise Änderungen in Commit-Reihenfolge Vollständig und geordnet Arbeitet auf Tabellen-, nicht auf Geschäftsebene Content-Hash Du hashst die normalisierten, relevanten Attribute und vergleichst Ignoriert irrelevante Zugriffe, wiederholbar Berechnung und Speicherung liegen bei dir Auf der SAP-Seite sind Change Pointer der klassische Mechanismus für Stammdaten. Sie werden generell in Transaktion BD61 und pro Nachrichtentyp aktiviert, zum Beispiel MATMAS für Materialien. Der Report RBDMIDOC (Transaktion BD21) liest unverarbeitete Pointer, erzeugt IDocs und markiert die Pointer als verarbeitet, und RBDCPCLR (BD22) entfernt verarbeitete, damit die Tabellen BDCP und BDCPS klein bleiben. Plane beide Jobs ein; ein Delta-Feed, der nie aufgeräumt wird, wird zum eigenen Performanceproblem. Auf der Infor-Seite routet ION Business Object Documents, und ein Sync BOD wird vom Besitzer der Daten an jede Anwendung gesendet, die die Änderung braucht. Mein Standard ist deshalb eine **zweistufige Prüfung**: Ein Ereignis oder eine Wasserlinie sagt mir, welche Datensätze ich ansehe, und ein Hash der normalisierten, eigenen Attribute sagt mir, ob ich schreibe. Normalisiere vor dem Hashen: Leerzeichen entfernen, Zahlenformate und Nachkommastellen vereinheitlichen, Listen sortieren und Felder weglassen, die das ERP ohne fachliche Bedeutung anfasst. Sonst löst ein Zeitstempel-Update im ERP tausende sinnlose Schreibvorgänge und Neuindizierungen in Pimcore aus. ## Idempotente Importe Messaging-Systeme liefern mindestens einmal zu. Symfony dokumentiert das klar: Eine Nachricht kann mehr als einmal zugestellt werden, deshalb müssen Handler wiederholt sicher laufen. Mit Retries, einem Worker-Neustart und einem Replay wird irgendwann jeder Datensatz zweimal verarbeitet. Idempotenz ist keine Optimierung, sondern eine Anforderung. - **Stabiler Schlüssel pro Geschäftsereignis.** Leite den Schlüssel aus der fachlichen Bedeutung ab (Artikelnummer plus ERP-Änderungsnummer oder Content-Hash), nie aus einer beim Senden erzeugten Zufalls-ID. - **Upsert per natürlichem Schlüssel.** Suche das Pimcore-Objekt per Artikelnummer und aktualisiere oder erzeuge es in einem Handler. Nie blind anlegen. - **Hash vor dem Schreiben.** Entspricht der Hash der eingehenden eigenen Attribute dem gespeicherten, tue nichts. Das verhindert auch Neuindizierungen und Cache-Invalidierungs-Stürme. - **Reihenfolge-Toleranz.** Führe eine Version oder einen Zeitstempel der Quelle mit und ignoriere Nachrichten, die älter sind als der gespeicherte Stand. Queues garantieren keine globale Reihenfolge. - **Löschungen als Zustand.** Bilde Deaktivierung und Löschung als Statuswechsel mit Quellversion ab, nicht als fehlenden Datensatz, damit sie Replays überstehen. - **Datenbank-Constraints als letzte Verteidigung.** Ein Unique-Key auf der Artikelnummer macht aus einem Rennen zwischen zwei Workern einen sichtbaren Fehler. Der Pimcore Data Importer folgt bei dateibasierten Feeds derselben Idee: Sein Resolver entscheidet, ob ein Datensatz ein bestehendes Objekt aktualisiert oder ein neues anlegt, und eine Delta-Prüfung überspringt unveränderte Datensätze. Ist dein Feed eine CSV- oder JSON-Datei aus dem ERP, reicht das vielleicht schon. Zu eigenen Handlern greife ich, wenn der Fluss ereignisgetrieben ist, wenn die Ownership pro Attribut Logik braucht oder wenn eine ERP-Nachricht auf mehrere Pimcore-Objekte auffächert. ## Queues: Symfony Messenger in Pimcore Pimcore nutzt Symfony Messenger für Hintergrundarbeit. Die Dokumentation definiert die Queue pimcore\_core für Hintergrundaufgaben und einen optionalen Transport pimcore\_failed\_jobs für fehlgeschlagene Nachrichten. Das Backend wählt die Umgebungsvariable PIMCORE\_MESSENGER\_TRANSPORT\_DSN\_PREFIX: Doctrine ist der Standard, unterstützt werden AMQP (RabbitMQ) und Redis. Laut Dokumentation ist RabbitMQ die empfohlene Message Queue für den Produktivbetrieb, und Worker laufen als \`bin/console messenger:consume pimcore\_core\`, überwacht von supervisor oder systemd. Für einen ERP-Sync würde ich neben pimcore\_core einen eigenen Transport anlegen, damit ein Schwall von Preisupdates die Hintergrundjobs der Redakteure nicht aushungert, und Worker pro Queue dimensionieren. Auf Symfony-Seite wird das Retry-Verhalten pro Transport konfiguriert (max\_retries, delay, multiplier, max\_delay, jitter); standardmäßig wird eine Nachricht dreimal mit exponentiellem Backoff wiederholt, bevor sie im Failure Transport landet. Überlege, welche Fehler einen Retry verdienen: Ein gesperrtes Objekt oder ein Timeout ja, ein Validierungsfehler nein, denn ein Retry verzögert dann nur den Alarm. **Packe nicht den ganzen ERP-Datensatz in die Nachricht** Sende eine kleine Nachricht mit Schlüssel, Quellversion und Hash und lass den Handler bei Bedarf den vollständigen Datensatz holen. Große Payloads blähen die Queue auf, und beim Retry kann die Payload schon veraltet sein. Eine schlanke Nachricht plus frisches Lesen lässt sich leichter wiederholen und leichter nachvollziehen. Halte die Queue ehrlich. messenger:stats zeigt, wie viele Nachrichten pro Transport warten, und der Failure Transport nützt nur, wenn jemand hinschaut, womit wir beim Monitoring sind. ## Datenqualitäts-Gates Ein Sync, der schlechte Daten treu kopiert, ist schlimmer als einer, der stoppt. Ich setze Gates zwischen „empfangen“ und „veröffentlicht“, und ein Datensatz, der ein Gate nicht besteht, wird zurückgehalten und gemeldet, weder verworfen noch veröffentlicht. - **Struktur-Gate:** Pflichtfelder vorhanden, Typen und Einheiten gültig, referenzierte Objekte (Marke, Kategorie, Einheit) existieren. - **Fach-Gate:** sinnvolle Wertebereiche (Preis über null, Gewicht nicht das Zehntausendfache des Medians), plausible Statusübergänge, keine plötzliche Massendeaktivierung. - **Vollständigkeits-Gate:** Ein Produkt wird nur in den Shop veröffentlicht, wenn Pflichtinhalte (Titel, Bild, Übersetzung) in jeder erforderlichen Sprache vorliegen. - **Mengen-Gate:** Würde ein Lauf weit mehr Datensätze ändern oder löschen als üblich, pausiere und frage nach Bestätigung, statt ihn anzuwenden. So fängst du eine ERP-Fehlkonfiguration ab, bevor sie deinen Shop leert. Gates liefern dir ein klares Statusmodell: empfangen, gültig, angereichert, veröffentlicht, zurückgehalten. Wenn du ein LLM zur Anreicherung einsetzt, etwa für Beschreibungsentwürfe oder Klassifikation, behandle seine Ausgabe als weiteren Gate-Input und teste es wie jedes Modell-Feature, wie in [LLM-Evals für Produkt-Features](https://balazscsorba.com/de/blog/llm-evals-for-product-features) beschrieben. ## Monitoring und Replays Der Maßstab für einen Sync ist nicht, wie er an guten Tagen läuft, sondern wie schnell du dich an schlechten erholst. Vor dem Go-live will ich vier Dinge haben. 1. **Eine Failure Queue mit Verantwortlichem.** Fehlgeschlagene Nachrichten landen in einem eigenen Transport (in Pimcore pimcore\_failed\_jobs). Prüfen mit messenger:failed:show, erneut ausführen mit messenger:failed:retry, verwerfen mit messenger:failed:remove. Alarmiere, wenn die Anzahl länger als eine festgelegte Zeit über null liegt. 2. **Lag und Durchsatz.** Queue-Tiefe pro Transport, Alter der ältesten Nachricht und Datensätze pro Minute. Eine flache Linie ist so verdächtig wie eine Spitze. 3. **Ein Replay-Befehl.** Zu einer Artikelnummer, einem Zeitfenster oder einer ERP-Änderungsnummer neu extrahieren und neu senden. Weil Handler idempotent sind, lassen sich Replays gefahrlos in Produktion ausführen. 4. **Ein Abgleichsbericht.** Der volle Vergleich zwischen ERP und PIM, der Unterschiede auflistet, nicht nur bestanden oder nicht. Nächtlich oder wöchentlich laufen lassen und den Trend prüfen: Eine wachsende Zahl an Unterschieden heißt, dass ein Delta-Signal verpasst wird. Logge pro Nachricht eine strukturierte Zeile: Schlüssel, Quellversion, Hash, Ergebnis (geschrieben, unverändert übersprungen, von Gate gehalten, fehlgeschlagen) und Dauer. Die meisten Supportfragen werden dann zu einer Suche statt einer Untersuchung. ## Was du 2026 zu Pimcore prüfen solltest Pimcore hat sein Releasemodell kürzlich geändert, und einiges davon betrifft die Planung. Diese Punkte würde ich vor Projektstart gegen die aktuelle Dokumentation prüfen, statt sie aus dem Gedächtnis anzunehmen. 1. **Plattformversion und Supportzeitraum.** Pimcore-Versionen folgen Major.Minor, Minor-Versionen erscheinen etwa quartalsweise, und seit 2026.1 tragen alle Module die Versionsnummer der Plattform. Das Release 2026.3 erschien am 29. September 2026 und ist kein LTS. Der Community-Support für eine Plattformversion endet mit dem Release der nächsten. 2. **LTS-Ziel.** Die Dokumentation nennt 2025.4 als LTS bis Dezember 2028 und 2024.4 bis Dezember 2026. Für einen langlebigen B2B-Shop würde ich auf eine LTS-Linie setzen oder regelmäßige Minor-Upgrades einplanen. 3. **Edition und Module.** Data Hub und Data Importer sind in der Community Edition aufgeführt; Professional ergänzt den TinyMCE-Editor; Enterprise enthält alle Module, zum Beispiel Workflow Designer und E-Commerce Framework. Prüfe, auf welche Module sich dein Design tatsächlich stützt und welche Edition und Lizenz sie brauchen. 4. **Release Notes, nicht nur Versionsnummern.** Die Notes zu 2026.3 erwähnen Sicherheitsfixes und die Entfernung alter Admin-Controller zugunsten der Studio API. Wenn du eigenen Admin-Code oder Integrationen hast, lies zuerst die Upgrade Notes. 5. **Messenger-Setup.** Prüfe den Transport-DSN-Prefix, die Failure-Transport-Konfiguration und wie Worker in deinem Hosting überwacht werden, denn hier entscheidet sich die Zuverlässigkeit des Syncs. Preise und Details von Supportverträgen nenne ich hier bewusst nicht: Sie hängen von deiner Vereinbarung mit Pimcore oder deinem Partner ab und ändern sich. ## Wie ich es in Projekten angehe Dieses Design ist meine Denkweise für einen Pimcore-SAP-Delta-Sync, und ich habe ein Referenzprojekt mit Pimcore und SAP Delta-Sync, das du auf der [Referenzseite](https://balazscsorba.com/de/references) findest. Wenn du einen Pimcore-Entwickler für eine SAP- oder Infor-Integration, eine PIM-ERP-Schnittstelle oder ein Review eines driftenden Syncs suchst, schau dir mein [Profil als B2B-E-Commerce-Entwickler](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer) an. Mein Rat in Kurzform: Schreib zuerst die Ownership-Tabelle, mach jeden Handler idempotent, hashe, was dir gehört, setze eine Queue und einen Fehlerpfad in die Mitte und übe den Replay, bevor du ihn brauchst. ## Quellen 1. [Pimcore docs: Symfony Messenger](https://docs.pimcore.com/platform/Getting_Started/Installation/Advanced_Installation_Topics/Symfony_Messenger/) 2. [Pimcore docs: Platform Versions](https://docs.pimcore.com/platform/Pimcore_Platform/Platform_Versions/) 3. [Pimcore docs: Pimcore Editions](https://docs.pimcore.com/platform/Pimcore_Platform/Pimcore_Editions/) 4. [Pimcore docs: Data Importer](https://docs.pimcore.com/platform/Data_Importer/) 5. [Pimcore on GitHub: Release 2026.3.0](https://github.com/pimcore/pimcore/releases/tag/v2026.3.0) 6. [Symfony docs: Messenger, Sync & Queued Message Handling](https://symfony.com/doc/current/messenger.html) 7. [SAP Library: Change Pointer (Master Data Distribution)](https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-us/4a/bb1e253536478be10000000a421937/content.htm?no_cache=true) 8. [SAP Library: Change Pointer (IDoc Interface/ALE)](https://help.sap.com/doc/saphelp_em700_ehp01/7.0.1/en-US/12/83e03c19758e71e10000000a114084/content.htm?no_cache=true) 9. [Infor docs: Infor ION and M3 BODs](https://docs.infor.com/m3cs/10.2.3/en-us/m3csbom/fabsog/goi1495809108914.html) 10. [Infor Developer Portal: Integration with ION](https://developer.infor.com/tutorials/integration-with-ion) 11. [Debezium: open source distributed platform for change data capture](https://debezium.io/) ## Häufige Fragen Wie synchronisiere ich Produktdaten von SAP nach Pimcore? Hole Änderungen aus SAP als Ereignisse, statt jedes Mal den gesamten Materialstamm zu lesen, zum Beispiel mit Change Pointern (aktiviert in Transaktion BD61, verarbeitet vom Report RBDMIDOC), die IDocs erzeugen. Lege die Nachrichten auf eine Queue, importiere sie mit einem idempotenten Handler, der per Artikelnummer upsertet und Datensätze mit unverändertem Content-Hash überspringt, und behalte einen geplanten Full-Abgleich als Sicherheitsnetz. Was ist der Unterschied zwischen Full Sync und Delta Sync? Ein Full Sync liest und vergleicht bei jedem Lauf alle Datensätze. Er ist einfach und selbstheilend, aber langsam und belastet das ERP. Ein Delta Sync überträgt nur, was sich seit dem letzten Lauf geändert hat: schnell und günstig, kann aber unbemerkt driften, wenn eine Änderung verpasst wird. Ich fahre Delta im Alltag und wöchentlich oder nächtlich einen Full-Abgleich, um Drift zu finden. Wie erkenne ich geänderte Datensätze zwischen ERP und PIM? Es gibt vier Möglichkeiten: einen Änderungszeitstempel, Ereignisse an der Quelle wie SAP Change Pointer oder Infor Sync BODs, Change Data Capture auf der Datenbank und einen selbst berechneten Content-Hash. Zeitstempel und Ereignisse sagen dir, wo du hinschauen sollst; der Hash sagt, ob sich wirklich etwas Relevantes geändert hat. Ereignis oder Zeitstempel plus Hash liefert die besten Ergebnisse. Kann Pimcore eine Message Queue für Importe nutzen? Ja. Pimcore nutzt Symfony Messenger und definiert die Queue pimcore\_core für Hintergrundaufgaben sowie einen optionalen Transport pimcore\_failed\_jobs für Fehler. Standard-Backend ist Doctrine, unterstützt werden außerdem AMQP (RabbitMQ) und Redis. Die Dokumentation empfiehlt RabbitMQ für den Produktivbetrieb, Worker starten mit bin/console messenger:consume pimcore\_core. Was bietet der Pimcore Data Importer für Delta-Importe? Der Data Importer liest CSV-, JSON-, XML-, XLSX- und SQL-Quellen, läuft zeitgesteuert, per Kommandozeile oder per Push über eine Queue und enthält eine Delta-Prüfung, die unveränderte Datensätze überspringt, sowie ein Cleanup, das Objekte entfernt, die die Quelle verlassen haben. Er passt gut zu dateibasierten Feeds. Für ereignisgetriebene ERP-Flüsse mit Regeln pro Attribut ergänze ich meist eigene Messenger-Handler. Wie finde ich einen Pimcore-Entwickler für eine SAP- oder ERP-Integration? Suche jemanden, der einen produktiven Sync ausgeliefert hat und nicht nur eine Demo: Frag nach Ownership pro Attribut, Idempotenz, fehlgeschlagenen Nachrichten und Replays. Erfahrung mit Symfony Messenger, der ERP-Seite (IDocs, BODs, OData oder REST) und dem Shop am anderen Ende zählt mehr als ein einzelnes Tool. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [B2B-E-Commerce & PIM →](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [European Accessibility Act im B2B-Shop: was Spryker-, Pimcore- und TYPO3-Teams beheben müssen](https://balazscsorba.com/de/blog/european-accessibility-act-b2b-shop) - [Headless B2B-Produktkonfigurator: Regeln, Preise und Nuxt auf einer Commerce-API](https://balazscsorba.com/de/blog/headless-product-configurator-b2b) - [Core Web Vitals für Nuxt-Sites und Shops: LCP, INP und CLS beheben](https://balazscsorba.com/de/blog/nuxt-core-web-vitals-performance) - [Laden nach EPEX-Preisen in Österreich: was meine Home-Assistant-App spart](https://balazscsorba.com/de/blog/home-assistant-ev-charging-energy-manager) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Gespräch buchen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)