+  QUELLE → ZIEL

Mehrere Systeme, eine Leitung

Die Extension wird auf mindestens auf einer Quellsystem- und einer Zielsystem-Instanz installiert. Das Quellsystem überträgt die gewünschten Informationen via Magento WebAPI. Das Zielsystem nimmt sie entgegen und legt sie an – oder aktualisiert sie, falls sie schon existieren. 

+  TYPISCHE SZENARIEN

Wer mit "Smart Data Synchronizer" arbeitet

Staging → Live

Kampagnenseiten und neue Produkte in Ruhe auf dem Staging bauen, prüfen lassen und dann gezielt einzeln freischalten. Ohne Datenbank-Dump, ohne Deployment-Fenster.

Mehrere Ländershops

Separate Magento-Installationen für DE, AT und CH. Ein Produkt wird einmal gepflegt und geht mit einem Klick in alle Instanzen, die es haben sollen.

Agentur und Kunde

Vorlagenseiten und Blockbibliotheken zentral pflegen und in Kundeninstanzen ausrollen – ohne dass jemand Zugriff auf die Produktionsdatenbank braucht.

Relaunch mit Parallelbetrieb

Während der neue Shop entsteht, laufen die alten Inhalte weiter. Änderungen aus dem Tagesgeschäft ziehen Sie stückweise in die neue Instanz nach.

B2B- und B2C-Instanz

Gemeinsame Stammdaten, getrennte Systeme. Über die Feldauswahl gehen Texte und Bilder mit, die Preislogik bleibt je Instanz eigenständig.

Notfall-Nachpflege

Ein Tippfehler in der Kategoriebeschreibung, drei Systeme betroffen. Korrigieren, Data Sync, erledigt – statt dreimal einloggen.

+  WARUM ÜBERHAUPT

Der Weg von Staging nach Live kostet Sie jedes Mal einen halben Tag

_bisher

Export, Datei, Import, Nacharbeit

• CSV exportieren, Spalten prüfen, Mapping pflegen, wieder importieren.
• Bilder liegen nicht in der Datei – die lädt jemand von Hand nach.
• Page-Builder-Inhalte brechen, weil die Block-IDs im Zielsystem andere sind.
• Fehlt ein Attribut im Ziel, bricht der Import ab.
• Für eine einzige geänderte Landingpage denselben Aufwand wie für 5.000 Produkte.
• Niemand weiß hinterher genau, was übertragen wurde.

_{mit Smart Data Synchronizer}

Bearbeiten, Data Sync, fertig

• Die Redaktion bleibt in der Maske, in der sie ohnehin gerade arbeitet.
• Bilder der Galerie und aus Page-Builder-Inhalten werden base64-kodiert mitgeliefert.
• Referenzierte CMS-Blöcke werden vorab übertragen und die ID's im Zielsystem neu verknüpft.
• Fehlende Attribute und Attributsets legt das Zielsystem auf Wunsch selbst an.
• Jeder Sync steht mit Status und Zeitstempel im Log.

+  IM BETRIEB GESEHEN

Ein Sync in zwei Minuten erklärt

Die Funktionalitäten im Überblick und an zwei Beispiel-Synchronisationen einfach erklärt.

+  WAS ÜBERTRAGEN WIRD

Vier Datentypen, jeder mit eigener Vorlage

Pro Typ definieren Sie eine Sync-Vorlage: welche Felder an das  Zielsysteme, mit welchen Optionen übertragen werden sollen. Was Sie nicht auswählen, bleibt im Ziel unverändert.

_product

Produkte

Alle Produktattribute stehen zur Auswahl. Die Zuordnung im Ziel läuft über die SKU. Die Galerie kann als base64 mitgeschickt werden.

_category

Kategorien

Kategoriefelder inklusive der strukturellen Bezüge zur Elternkategorie. Der url_key geht immer mit.

_{cms_page}

CMS-Seiten

Inklusive Page-Builder-Inhalt: Bilder werden eingebettet, absolute URLs zu host-unabhängigen Direktiven normalisiert.

_{cms_block}

CMS-Blöcke

Zuordnung über den Identifier. Blöcke, die in einer Seite referenziert sind, synchronisieren automatisch vorweg.

Immer dabei, egal was Sie auswählen: Identitäts- und Strukturschlüssel (SKU), identifier, url_key, Eltern-Referenzen und Medien-Assets. Ohne die könnte das Zielsystem die Datentypen nicht sicher zuordnen.

+  WAS ÜBERTRAGEN WIRD

Einmal konfiguriert, danach ein Klick

Die folgenden Schritte 1 bis 3 werden nur einmalig durchgeführt. Schritt 4 macht die Redaktion danach jeden Tag.

SCHRITT 01 — EINMALIG

Zielsystem anlegen und Verbindung testen

Basis-URL eintragen, Authentifizierung wählen – wahlweise ein statischer Integration Access Token oder Admin-Zugangsdaten. Zugangsdaten liegen verschlüsselt vor und werden im Backend maskiert angezeigt.

Der Button Test Connection pingt das Ziel an und meldet sofort zurück, ob die Leitung steht – aus der Übersicht heraus oder direkt im Formular.

Es können mehrere Zielsysteme konfiguriert und für Daten-Synchronisationen genutzt werden.

^{Zielsystem konfigurieren: Name, Basis-URL, Auth-Typ, Timeout, aktiv ja/nein.}

SCHRITT 02 — EINMALIG

Sync-Vorlage definieren

Eine Vorlage legt fest, was übertragen wird und wohin: Datentyp (Entity), die Felder und Attribute per Mehrfachauswahl, ein oder mehrere Zielsysteme sowie die Optionen für Medien und Page-Builder-Referenzen.

Werden keine Felder ausgewählt, greifen die Standardwerte. Für jeden Entitätstyp gibt es eine eigene Vorlage – die Feldliste filtert sich entsprechend.

^{Vorlage anlegen: Entitätstyp wählen, Felder picken, Ziele zuordnen.}

SCHRITT 03 — EINMALIG

Globale Einstellungen

Timeout für die Verbindung, maximale Mediengröße für den base64-Transfer, Log-Level und die Frage, ob fehlende Attribute im Ziel automatisch angelegt werden sollen. Alles unter Stores › Configuration › CLEVER+ZOEGER › Smart Data Synchronizer.

^{Zentrale Einstellungen inklusive Log-Level für var/log/cleverzoeger_datasync.log.}

SCHRITT 04 — TÄGLICH

Smart Data Synchronizer starten

Der Button "Data Sync" sitzt in der Toolbar jeder unterstützten Bearbeitungsmaske. Ein Klick öffnet ein Fenster mit den aktiven Vorlagen für diesen Entitätstyp. Vorlage wählen, Run Sync drücken – und im selben Fenster steht, was im Ziel passiert ist.

Kein Kontextwechsel, keine Datei, kein Warten auf die Technik.

^{Vorlage wählen, Sync starten. Das Ergebnis erscheint direkt im Dialog.}

^Produkt

^Kategorie

^CMS-Seite

^CMS-Block

+  DER SCHWIERIGE FALL

Page Builder überlebt den Umzug

Eine Landingpage mit einem Bild und einem eingebundenen CMS-Block ist genau der Inhalt, an dem klassische Import-Werkzeuge scheitern. Hier ist, was beim Übertragen tatsächlich passiert.

• Bilder werden gelesen und eingebettet. Sowohl https://<QUELLSYSTEM>/media/…-Direktiven als auch absolute …/media/…-Quellen in <img>-Tags. Im Ziel landen sie unter demselben Medienpfad.
• Absolute URLs werden normalisiert zu host-unabhängigen Direktiven – die Seite funktioniert im Ziel auch unter anderer Domain.
• Referenzierte CMS-Blöcke gehen zuerst. Sie werden einmalig über ihren identifier angelegt.
• Die numerische block_id im Widget wird umgeschrieben auf die lokale ID im Zielsystem.

^{Schematische Darstellung. Die tatsächliche Ausgabe steht im Job-Log und in var/log/cleverzoeger_datasync.log.}

Ehrlich bleiben: Übergroße Bilder werden vom Größen-Schutz übersprungen und im Log als Warnung vermerkt. Verschachtelte Block-in-Block-Referenzen werden in der aktuellen Version eine Ebene tief übertragen.

^{Vorher: die Seite im Editor des Quellsystem.}

^{Nachher: Die Seite im Frontend des Zielsystems – aus einem zuvor leeren Ziel heraus angelegt.}

+  FUNKTIONSUMFANG

Alles, was zwischen mehreren Instanzen gebraucht wird

Mehrere Zielsysteme

Eine Vorlage kann beliebig viele Ziele bedienen. Nur aktive Ziele bekommen Daten – zum Pausieren genügt ein Schalter.

Feldgenaue Auswahl

Per Mehrfachauswahl bestimmen, welche Attribute mitgehen. Preise im Ziel behalten, nur Texte aktualisieren? Kein Problem.

Attribute anlegen

Auf Wunsch erzeugt das Zielsystem fehlende Attribute, Attributoptionen und Attributsets selbst, statt den Vorgang abzubrechen.

Medien-Dateien

Die Produktgalerie wird direkt in der Payload mit synchronisiert. Kein separater FTP-Sync, kein nachträgliches Bilderschieben.

Fehlerfreier Import

Eindeutige Zuordnung über SKU und identifier. Wiederholte Läufe aktualisieren, sie duplizieren nicht.

Verbindungstest

Ein Klick, eine Antwort. Aus der Zielübersicht heraus oder direkt im Formular – bevor die erste echte Entität losgeschickt wird.

Logging

Jeder Lauf mit Entitätstyp, Quellentität, Status je Ziel und Zeitstempel. Nachvollziehbar auch Wochen später.

Verschlüsselt

Access Token und Admin-Passwörter werden verschlüsselt gespeichert und im Backend nur maskiert angezeigt.

Entwickler-TLS

Für lokale Ziele mit selbstsigniertem Zertifikat lässt sich die TLS-Prüfung gezielt abschalten. Extra für Dev-Systeme.

+  SICHERHEIT

Sauber abgesichert

• Die Empfängerseite stellt zwei REST-Endpunkte bereit: GET /rest/V1/cz-datasync/ping für den Gesundheitscheck und POST /rest/V1/cz-datasync/import für den eigentlichen Import.
• Beide verlangen einen Bearer Token und die ACL-Ressource CleverZoeger_DataSync::sync. Kein offener Endpunkt, keine Hintertür.
• Zugangsdaten liegen verschlüsselt in der Konfiguration und werden im Backend maskiert.
• Ein Größenlimit für Mediendaten verhindert, dass ein einzelnes Bild den Transfer sprengt.
• Die Extension lässt sich global deaktivieren, einzelne Ziele und Vorlagen separat.

+  TECHNISCHE DATEN

Auf einen Blick

+  NÄCHSTER SCHRITT

Schluss mit doppelter Pflege

Sehen Sie sich die vollständige Dokumentation an oder sprechen Sie mit uns über Ihr Setup. Beratung kostet bei uns nichts.