B2B-Integrationen in Magento 2: Profiles, Mappings und Synchronisation in B2B Suite

Die Integration von Magento 2 mit ERP, PIM, WMS oder CRM endet nicht beim Senden von Daten an eine API. Firmenbezug und Kennungen müssen zugeordnet, Ergebnisse geprüft und abgelehnte Nachrichten behandelt werden. Im B2B entscheidet das darüber, ob Bestellungen bearbeitet, Geschäftskunden richtig erkannt und vereinbarte Preislisten dem richtigen Kanal zugeführt werden.

Integrations in Kowal B2B Suite organisiert diese Arbeit in fünf Bereichen: Profiles, Mappings, Sync Jobs, Dead Letter Queue und Sync Errors. Wir erklären deren Funktionsweise und den Einsatz im täglichen Integrationsbetrieb.

Die Beschreibung basiert auf der im November 2026 geprüften Implementierung. Die Beispiele setzen einen Adapter für das jeweilige System und die jeweilige Operation voraus und dienen der Veranschaulichung.

Was liefert Integrations, was übernimmt der Adapter?

Integrations bietet gemeinsame Infrastruktur: Profilkonfiguration, ID-Zuordnungen, Auftragsregister, Versuchskontrolle, Ergebnisse und Fehlerhistorie. Die konkrete Verbindung zu ERP, PIM, WMS oder CRM übernimmt ein Adapter, der API und Datenaustauschregeln des Systems kennt.

Er definiert Authentifizierung, Nachrichtenformate, Feldtransformationen und Ausführung. „ERP“ als Profiltyp beschreibt den Zweck; dadurch wird keine fertige Verbindung zu einem beliebigen ERP installiert.

Auch das Speichern eines Auftrags registriert zunächst nur Arbeit. Das Formular startet keinen wiederkehrenden Hintergrundprozess. Verarbeitung und Auswahl ausführbarer Aufträge müssen im Projekt angebunden werden, etwa über Worker, Zeitplanung oder Middleware mit der bereitgestellten Logik und API.

Fünf Ansichten, fünf konkrete Fragen

Alle Elemente betrachten denselben Ablauf aus anderer Perspektive: Das Profil definiert den Kontext, Mappings verbinden Datensätze, der Auftrag repräsentiert die Operation und die letzten beiden Ansichten unterstützen die Fehlerbehandlung.

Profiles: Integration für die richtige Website konfigurieren

Unter B2B > Integrations > Profiles erstellen und bearbeiten Sie Integrationsprofile. Jedes gehört zu einer Magento-Website mit aktivem B2B. So lassen sich etwa Inlands- und Exportkanal getrennt konfigurieren, wenn sie eigene Websites verwenden.

Website bezeichnet hier die Magento-Organisationseinheit für Vertriebskanäle. Mehrere Sprachansichten derselben Website bedeuten nicht automatisch mehrere eigenständige Integrationen.

Config JSON besitzt keinen universellen Feldsatz für alle Integrationen. Die Schlüssel interpretiert der Adapter. Das Formular prüft JSON-Syntax, ersetzt aber keinen Verbindungstest zum Zielsystem. Zugangsdaten sollten entsprechend den Adapteranforderungen über Referenzen auf sichere Konfiguration eingebunden werden.

Praktisch nutzt der Integrator ein benanntes Profil, statt ERP-Parameter über viele Skripte zu verteilen. Der Operator erkennt System und Austauschrichtung des Prozesses.

Mappings: Magento- und externe Kennungen verknüpfen

Dieselbe Firma kann in B2B Suite die ID 42 und im ERP den Code ERP-C-0084 haben. Menschen erkennen einen Geschäftspartner; die Integration braucht eine ausdrückliche Verknüpfung zum richtigen Datensatz.

Mappings speichert Website, Systemtyp, Entitätstyp, lokale und externe ID sowie optionale JSON-Metadaten. Die Oberfläche sieht unter anderem Firmen, Kunden, Produkte, Kategorien, Preislisten, Bestellungen, RFQ und Dokumente vor.

Die Tabellenwerte sind Beispiele. Der Adapter legt die Darstellung lokaler Kennungen je Entität fest. Zuordnungen sind sowohl über lokale als auch über externe IDs abrufbar.

Mappings ordnet Datensatzidentitäten zu und ist kein visueller Editor für Feldtransformationen. Regeln wie „ERP-Kundenname wird ins Magento-Feld company übertragen“ gehören zum Adapter. Das Speichern einer Zuordnung lädt selbst keine Daten und führt keine Synchronisation aus.

Der Kontext umfasst Website, System- und Entitätstyp, nicht ausschließlich ein Profil. Bei mehreren Verbindungen desselben Typs in einer Website muss der Integrator die Datensatzidentifikation abstimmen. Innerhalb dieses Kontexts erzwingt die Datenbank eindeutige lokale und externe IDs.

Sync Jobs: Arbeit und Synchronisationsverlauf verfolgen

Ein Sync Job steht für eine konkrete Operation, etwa die Übergabe einer Bestellung ans ERP. Unter Schedule Sync Job wählen Sie aktives Profil, Entitätstyp und Operation. Optional werden Richtung, JSON-Eingabedaten, Idempotenzschlüssel, Versuchslimit und Termin angegeben. Ohne Überschreibung gilt die Richtung des Profils.

Entitätstyp und Operationsname müssen dem Adapter bekannt sein. export_order kann beispielsweise Teil der vereinbarten Lösung sein; die Eingabe allein implementiert keinen Export.

View zeigt Zusammenfassung, Eingabe, Adapterergebnis, Logs und Fehler. Prüfen lassen sich Website, Profil, Richtung, Entität, Operation, Versuche, Idempotenzschlüssel und Zeitpunkte von Planung, Start und Ende.

success ist nach dem Vertrag des Adapters zu interpretieren. Nimmt die externe API Nachrichten nur zur späteren Verarbeitung an, muss geklärt sein, ob das Ergebnis Annahme oder bestätigten Abschluss des Geschäftsvorgangs bedeutet.

Der Termin ist eine Information für den ausführenden Prozess. Eine Datumsangabe ersetzt weder dessen Betrieb noch die Regeln zur Auswahl fälliger Aufträge.

Idempotenz: doppelte Aufträge begrenzen

Nach einem Verbindungsabbruch kann Middleware dieselbe Operation erneut melden. Ein Idempotenzschlüssel erkennt einen bestehenden Auftrag: Derselbe Schlüssel innerhalb derselben Website liefert den vorhandenen Datensatz zurück, statt einen neuen zu erstellen.

Der Schlüssel sollte einen konkreten Geschäftsvorgang identifizieren, etwa den Export einer Bestellversion. Da er websiteweit gilt, sollte er System und Operation erkennbar einbeziehen. Die Wiederverwendung eines Schlüssels aktualisiert nicht die Eingabedaten des alten Auftrags.

Das schützt vor doppelter Registrierung. Doppelte Auswirkungen im ERP, etwa ein zweiter Beleg nach unklarem Verbindungsergebnis, müssen zusätzlich durch Adapter und Möglichkeiten der externen API verhindert werden.

Dead Letter Queue: Aufträge mit Entscheidungsbedarf

Dead Letter Queue zeigt Aufträge mit Status dead. Es handelt sich um eine Ansicht derselben Datensätze, nicht um weitere Nachrichtenkopien. Sie isoliert Operationen, die innerhalb ihrer Versuche nicht abgeschlossen wurden.

Bei drei zulässigen Versuchen setzt der dritte fehlgeschlagene Adapterlauf den Status dead. Das Modul führt deshalb nicht automatisch drei Versuche nacheinander aus. Weitere Ausführungen und Abstände bestimmt die implementierte Wiederholungs- und Ausführungslösung.

Der Operator öffnet den Auftrag, untersucht den Fehler und behebt etwa eine fehlende Kundenzuordnung oder falsche Verbindungsparameter. Anschließend kann er Retry Job verwenden.

Wiederholung ist für failed und dead verfügbar. Sie erstellt keinen neuen Auftrag und setzt die Versuchshistorie nicht zurück. Sie setzt retry, den aktuellen Wiederholungstermin und entfernt die bisherigen Start- und Endzeitpunkte. Bei ausgeschöpftem Limit wird noch ein Versuch zugelassen. Erst die anschließende Verarbeitung führt den Adapter aus.

Sync Errors: Fehlerhistorie mit Auftragskontext

Sync Errors zeigt beim Adapterlauf gespeicherte Fehler mit Code, Nachricht, Zeit und Wiederholungsmöglichkeit. Die Liste verbindet sie mit dem aktuellen Auftrags-, Profil- und Website-Kontext. So lassen sich Einzelkundenprobleme von Verbindungsausfällen unterscheiden.

Auftragsdetails enthalten zugehörige Fehler und technische Logs, etwa für Start, Abschluss und erneute Planung. Fehlerdaten speichern außerdem einen technischen Trace für den Integrator.

Ein Auftrag kann mehrere Fehlereinträge aus verschiedenen Versuchen besitzen. Fehlerzahl und offene Operationen sind daher nicht identisch. Frühere Fehler bleiben auch nach späterem Erfolg Teil der Historie.

Retryable ergibt sich hier aus den beim Fehler verbleibenden Versuchen. Das Kennzeichen erkennt keine vorübergehende Ursache automatisch. Eine falsche ID wird durch Wiederholen allein nicht richtig, auch wenn weitere Versuche zulässig sind.

Die wesentliche Unterscheidung: Sync Errors unterstützt die Ursachenanalyse; Dead Letter Queue zeigt Aufträge mit ausgeschöpften Versuchen.

Szenario 1: B2B-Firma mit ERP-Kundenstamm verbinden

Firma Alfa hat ein Magento-Konto und bereits einen ERP-Kundenstamm. Das Team möchte keinen zweiten Geschäftspartner anlegen.

1. Der Integrator richtet ERP-Adapter und Profil für die richtige Website ein.
2. Mappings verknüpft Firma 42 mit ERP-C-0084.
3. Der Adapterauftrag nutzt die Zuordnung für den vorhandenen Datensatz.
4. Der Operator prüft Ergebnis und zurückgelieferte Kennungen in Sync Jobs.

Der Nutzen ist eine konsistente Geschäftspartneridentität. Welche Felder aktualisiert werden und welches System sie führt, gehört zum vereinbarten Integrationsumfang.

Szenario 2: B2B-Bestellung nach Verbindungsunterbrechung ins ERP übertragen

Ein Kunde bestellt, die implementierte Lösung erstellt einen Exportauftrag. Das ERP ist vorübergehend nicht erreichbar. Der Adapterlauf scheitert, der Fehler wird gespeichert und der Auftrag erhält failed oder nach Ausschöpfung der Versuche dead.

Nach Wiederherstellung prüft der Operator das vorherige Ergebnis im ERP und plant Retry desselben Auftrags. Der Adapter sollte vorhandene Belege erkennen, falls das ursprüngliche Anliegen trotz verlorener Antwort angenommen wurde, um Duplikate zu vermeiden.

Bei Erfolg kann das Ergebnis die ERP-Beleg-ID enthalten und der Adapter eine Zuordnung speichern. Ergebnisinhalt und Zeitpunkt der Zuordnung hängen von der Implementierung ab.

Szenario 3: Preisliste für den richtigen B2B-Kanal aktualisieren

Das ERP führt die vereinbarten Konditionen. Für den Großhandelskanal bestehen ein Importprofil und die Zuordnung von Preisliste 7 zu ERP-PRICELIST-DEALERS.

Der Adapter liest ERP-Daten, prüft SKUs, Währung und Mengenstaffeln und speichert nach den Regeln des Pricing-Moduls. Sync Job verfolgt die Operation; das Ergebnis kann verarbeitete Positionen zusammenfassen. Bei Problemen stehen Auftragskontext und Fehlermeldung bereit.

Integrations steuert den Ablauf, Pricing die Preisauswahl. Mehr dazu im Artikel über B2B-Preislisten und Price List in Magento 2. Validierung, Teiländerungen und Indexaktualisierung müssen im Adapter definiert werden.

Szenario 4: Wiederkehrender Fehler erfordert Datenkorrektur

Das Lagersystem lehnt eine Operation ab, weil es das Produkt nicht erkennt. Wiederholen allein hilft nicht. Der Auftrag erreicht das Limit und erscheint in Dead Letter Queue.

Der Operator öffnet View Job, liest die Nachricht und prüft IDs. Fehlt eine Zuordnung, korrigiert er Mappings. Nach Behebung wählt er Retry Job und kontrolliert das nächste Ergebnis.

Das zeigt, warum Zuordnungen und Fehlerhistorie zusammen nötig sind. Die Warteschlange ermöglicht die Rückkehr zur Operation; die Diagnose zeigt die erforderliche Korrektur.

Integrations schrittweise einführen

1. Ersten Prozess wählen. Etwa mit Bestellexport beginnen, statt alle Bereiche gleichzeitig anzubinden.
2. Datenquellen bestimmen. Führendes System für Kunde, Preisliste oder Abwicklungsstatus und Konfliktregeln festlegen.
3. Adapter und Ausführungsprozess vorbereiten. Operationen, Formate, Authentifizierung, Ausführung und Wiederholungen definieren.
4. Profiles und Mappings konfigurieren. Website, Richtung und IDs an echten Fällen prüfen.
5. Erfolg und Fehler testen. API-Ausfall, falsche Daten, wiederholte Meldungen und ausgeschöpfte Versuche einbeziehen.
6. Geschäftsergebnis prüfen. Neben dem Status auch den richtigen Zieldatensatz bestätigen.
7. Verantwortung zuweisen. Überwachung von Sync Errors und Dead Letter Queue sowie Korrekturen zuordnen.

So bewerten Sie korrekt verarbeitete Vorgänge und Behebungszeiten statt lediglich das Vorhandensein einer API-Verbindung.

Häufige Fragen zu Integrations in B2B Suite

Bedeutet ein ERP-Profil eine fertige Anbindung an jedes ERP?

Nein. Es speichert Kontext und Konfiguration. Ein für die API und Prozesse entwickelter Adapter übernimmt die Kommunikation.

Ordnet Mappings Importfelder zu?

Die Ansicht verbindet lokale und externe Datensatzkennungen. Feldtransformationen und Datenformatierung übernimmt der Adapter.

Sendet Retry sofort Daten?

Nein. Es plant den vorhandenen Auftrag neu. Senden oder Abrufen erfolgt bei der nächsten Verarbeitung durch den angebundenen Ausführungsprozess.

Wie unterscheiden sich Dead Letter Queue und Sync Errors?

Dead Letter Queue zeigt dead-Aufträge, Sync Errors gespeicherte Fehler mit Kontext. Fehler später erfolgreicher Operationen können in der Historie bleiben.

Wiederholt das Modul automatisch alle paar Minuten?

Es speichert Termine, Status und Zähler und bietet Wiederholungen an. Zeitplan, Abstände und automatische Auswahl weiterer Versuche müssen in der Ausführungslösung konfiguriert werden.

Ist die Integration über API steuerbar?

Die B2B-Suite-API unterstützt Profile, Zuordnungen, Anlegen, Verarbeiten und Wiederholen von Aufträgen sowie Lesen von Aufträgen, Logs und Fehlern. Erforderlich sind Integrationsrechte und bei entsprechenden Operationen Website-Kontext.

B2B-Integration unter Kontrolle Ihres Teams

Profiles ordnet Konfiguration, Mappings Datensatzidentitäten, Sync Jobs Abläufe und Dead Letter Queue sowie Sync Errors die Fehlerbehandlung. Zusammen bilden sie eine erweiterbare Grundlage für Magento-2-Backoffice-Integrationen mit passenden Adaptern.

Entdecken Sie Kowal B2B Suite für Magento 2 Open Source oder beschreiben Sie Ihren gewünschten ERP-, PIM-, WMS- oder CRM-Prozess. System, Austauschrichtung und ein heute manueller Vorgang reichen als Ausgangspunkt.

Lesen Sie auch: manuelle B2B-Vertriebsabwicklung reduzieren und Kosten manueller B2B-Bestellbearbeitung.