Add-ons

Migrationsanforderungen liegen häufig zwischen zwei Extremen. Die standardmäßig unterstützte Migration kann strukturell passen, während das Unternehmen dennoch genauer steuern muss, welche Datensätze migriert werden, in welchem Feld bestimmte Werte landen oder wie ausgewählte Werte verändert werden sollen, bevor sie den Zielshop erreichen. Genau dafür dienen Add-ons innerhalb der Next-Cart Migration Services.

Die entscheidende Frage lautet nicht nur, ob ein Add-on thematisch passend klingt. Jedes Add-on löst eine andere Art von Datenverarbeitungsproblem. Mehrere Add-ons können zusammenwirken, wenn eine Migrationsanforderung mehrere Verarbeitungsschritte umfasst. Wer diese Unterschiede versteht, kann unterstützte Erweiterungen sauber von umfassenderer Arbeit im Rahmen von Custom Service trennen.

Add-ons lösen klar abgegrenzte Datenverarbeitungsanforderungen

Add-ons erweitern die unterstützte Migrationsverarbeitung, ohne den grundlegenden Migrationspfad zu ändern. Eine sinnvolle Add-on-Anforderung beginnt mit dem geschäftlichen Ergebnis, das erreicht werden muss, und identifiziert anschließend den konkreten Verarbeitungsschritt, der dafür erforderlich ist.

Vier Fragen grenzen die Standard Add-ons klar voneinander ab:

• Welche Datensätze sollen in der Migration weiterverarbeitet werden? Das ist eine Frage für Data Filter.
• Welches kompatible Zielfeld soll ein unterstütztes Quellfeld aufnehmen? Das ist eine Frage für Advanced Data Mapping.
• Erfordert die Anforderung eine unterstützte Zuordnung von Feldern oder Datenbankspalten, wenn sowohl Quell- als auch Zielplattform Open-Source sind? Das ist eine Frage für Advanced Database Mapping.
• Wie soll ein ausgewählter Wert in einem Zielfeld während der Migration verändert werden? Das ist eine Frage für Data Transformation.

Diese Funktionen hängen zusammen, sind aber nicht austauschbar. Filterung verändert, welche Datensätze zum Migrationsumfang gehören. Mapping verändert das Ziel eines Werts. Datenbank-Mapping kann innerhalb seiner unterstützten Grenzen auf der zugrunde liegenden Datenbankebene arbeiten. Transformation verändert den ausgewählten Zielwert.

Vier Standard Add-ons, vier verschiedene Entscheidungen

Die vier Standard Add-ons lassen sich am besten danach unterscheiden, welche Ebene des Migrationsergebnisses sie steuern. Es handelt sich nicht um vier Varianten derselben Funktion. Eines steuert, welche Datensätze teilnehmen, zwei steuern, wo unterstützte Werte abgebildet werden, und eines steuert, welcher endgültige Zielwert entsteht.

Standard Add-on	Hauptaufgabe	Typisches Einsatzsignal	Rolle in einem kombinierten Ablauf	Festpreis
Data Filter	Auswählen, welche Datensätze migriert werden, indem unterstützte feldbasierte Bedingungen auf eine Datenkategorie angewendet werden.	Das Unternehmen benötigt nur eine definierte Teilmenge ansonsten zulässiger Datensätze.	Wird zuerst ausgeführt und legt die Datensatzmenge fest, die alle späteren Add-ons erhalten.	$50
Advanced Data Mapping	Ein unterstütztes Quellfeld einem kompatiblen Zielfeld neu zuordnen, ohne den Wert im Mapping-Schritt zu verändern.	Der Quellwert ist bereits korrekt, soll aber in einem anderen unterstützten Zielfeld landen.	Wird nach der Filterung ausgeführt und legt unterstützte Feldziele vor dem Datenbank-Mapping fest.	$50
Advanced Database Mapping	Unterstützte Felder und zugrunde liegende Datenbankspalten kompatiblen Zielfeldern oder Zielspalten zuordnen, einschließlich zulässiger plattformspezifischer und benutzerdefinierter Felder.	Die Anforderung hängt von einer Darstellung auf Datenbankebene und nicht nur von der unterstützten Feldebene ab.	Wird nach Advanced Data Mapping ausgeführt und kann den Wert oder das Ziel festlegen, das Data Transformation anschließend erhält. Nur verfügbar, wenn beide Plattformen Open-Source sind.	$100
Data Transformation	Ausgewählte Werte von Zielfeldern während der Migration transformieren.	Der endgültige Zielwert muss durch eine unterstützte Regel neu berechnet, normalisiert, umformatiert oder anderweitig verändert werden.	Wird zuletzt ausgeführt und arbeitet mit dem Zielwert, der nach den Mapping-Schritten vorliegt.	$50

Die Tabelle ist hilfreich, weil dieselbe geschäftliche Anforderung mehrere dieser Signale gleichzeitig enthalten kann. Die Anforderung „nur diese Products migrieren, einen Quellwert in ein anderes Feld legen, einen benutzerdefinierten Datenbankwert als Price verwenden und anschließend eine Marge anwenden“ ist kein einzelnes, unscharfes Anpassungsproblem. Sie besteht aus vier unterschiedlichen Operationen, die separat geprüft und anschließend in der erforderlichen Verarbeitungsreihenfolge kombiniert werden können.

Data Filter: die Datensatzmenge steuern

Data Filter ist der richtige Ausgangspunkt, wenn das Unternehmen über unterstützte feldbasierte Bedingungen beschreiben kann, welche Datensätze zum Migrationsergebnis gehören sollen.

Typische Fragen sind:

• Sollen nur aktive Products einbezogen werden?
• Sollen Orders auf einen definierten Geschäftszeitraum oder eine Statusbedingung begrenzt werden?
• Sollen nur Customers weiterverarbeitet werden, die eine vereinbarte Feldbedingung erfüllen?
• Soll eine Inhalts-Datenkategorie auf die für den neuen Shop relevanten Datensätze eingeschränkt werden?

Die entscheidende Grenze: Data Filter verändert die Teilnahme von Datensätzen, nicht ihr Zielfeld oder ihren Wert. Ein durch den Filter ausgeschlossener Product-Datensatz erreicht für diesen Migrationsumfang keine späteren Add-on-Schritte. Ein Product, das den Filter besteht, wird mit seinen unterstützten Daten an die folgenden Mapping- und Transformationsschritte weitergegeben.

Damit ist Data Filter bei kombinierten Anforderungen besonders wichtig. Soll eine spätere Mapping- oder Transformationsregel nur einen Teil des Katalogs betreffen, legt die Filterung diese Datensatzmenge zuerst fest. Ein späteres Add-on muss dann nicht Datensätze unterscheiden, für deren Auswahl es nicht vorgesehen ist.

Entity Points bleiben ein getrenntes Kapazitätskonzept. Products, Customers, Orders und Blog Posts können entsprechend ihrer festgelegten Gewichte Entity Points verbrauchen. Die Anzahl der Entity Points legt jedoch nicht fest, welche einzelnen Datensätze migriert werden sollen. Diese Auswahlentscheidung übernimmt Data Filter.

Eigenständige Anwendungsfälle für Data Filter

Anwendungsfall: nur aktivierte Products migrieren. Ein Händler nimmt eingestellte und deaktivierte Katalogdatensätze außer Betrieb und möchte nur Products in den Migrationsumfang aufnehmen, deren unterstütztes Statusfeld sie als aktiviert kennzeichnet. Data Filter ist hier passend, weil die geschäftliche Entscheidung bestimmt, welche Product-Datensätze teilnehmen, und nicht, wohin ihre Werte zugeordnet oder wie diese Werte verändert werden. Die konkrete Bedingung hängt weiterhin von den unterstützten Feldern und Operatoren des ausgewählten Migrationspfads ab.

Anwendungsfall: Orders auf einen definierten Geschäftszeitraum begrenzen. Ein Unternehmen benötigt für das Migrationsprojekt möglicherweise nur Orders, die nach einem vereinbarten Datum erstellt wurden, während ältere historische Orders bewusst außerhalb des Umfangs bleiben. Wenn das erforderliche Datumsfeld und der Vergleich unterstützt werden, kann Data Filter diese Datensatzmenge festlegen, bevor spätere Mapping- oder Transformationsregeln ausgewertet werden. Die Filterung verändert nicht die Bedeutung der ausgewählten Orders, sondern entscheidet, welche Datensätze weiterverarbeitet werden.

Advanced Data Mapping: Wert beibehalten, unterstütztes Ziel ändern

Advanced Data Mapping passt, wenn der Quellwert korrekt ist, aber nicht im vorgesehenen unterstützten Zielfeld landen soll.

Das Grundmodell ist eine direkte Neuzuordnung:

supported source field -> compatible target field

Unterstützt der gewählte Migrationspfad beispielsweise sowohl Product Short Description als auch Description, kann die Anforderung lauten, den Wert aus Short Description in der Quelle als Descriptionim Ziel zu verwenden. Der Wert selbst muss nicht neu berechnet werden. Benötigt wird lediglich ein anderes unterstütztes Ziel.

Die Abgrenzung ist in der Praxis hilfreich:

• „Diesen unterstützten Quellwert in dieses kompatible Zielfeld legen“ deutet auf Advanced Data Mapping hin.
• „Diesen Wert verändern, bevor er den Zielshop erreicht“ deutet auf Data Transformation hin.
• „Der Wert liegt in einer zugrunde liegenden Datenbankspalte und erfordert Verarbeitung auf Datenbankebene“ kann bei einem geeigneten Plattformpfad auf Advanced Database Mappinghindeuten.

In einem kombinierten Ablauf erhält Advanced Data Mapping nur die Datensätze, die Data Filter passiert haben. Es legt unterstützte Feldziele fest, bevor Advanced Database Mapping und Data Transformation ausgeführt werden. Wenn spätere Schritte ein verwandtes oder identisches Ziel betreffen, bestimmt die Reihenfolge, welcher Wert für die weitere Verarbeitung verfügbar ist.

Auch Advanced Data Mapping hat Grenzen. Quell- und Zielfeld müssen unterstützt und kompatibel sein. Tax-Daten liegen außerhalb des Standard-Mapping-Umfangs. Eine Änderung des Zielfelds garantiert außerdem nicht, dass Anwendungen, Themes, Erweiterungen oder Geschäftslogik auf der Zielplattform den zugeordneten Wert auf eine bestimmte Weise verwenden.

Eigenständige Anwendungsfälle für Advanced Data Mapping

Anwendungsfall: Product Short Description als Ziel-Description verwenden. Der Quelltext ist bereits korrekt, der Zielshop benötigt diesen unterstützten Wert jedoch in einem anderen kompatiblen Feld. Advanced Data Mapping passt, weil es sich um eine direkte Zieländerung handelt: Short Description -> Description. Der Mapping-Schritt erhält den Wert, statt ihn umzuschreiben.

Anwendungsfall: einen unterstützten Customer-Kontaktwert neu zuordnen. Eine Migration kann ein unterstütztes Customer-Kontaktfeld enthalten, dessen Wert in einem anderen kompatiblen Ziel-Kontaktfeld landen muss, weil die beiden Plattformen Customer-Informationen unterschiedlich organisieren. Sind beide Felder unterstützt und kann das Ziel den Quellwert korrekt darstellen, kann Advanced Data Mapping diese Neuzuordnung vornehmen, ohne aus einem Feldzielproblem eine Transformation oder eine Custom-Service-Anforderung zu machen.

Advanced Database Mapping: mit zulässiger Darstellung auf Datenbankebene arbeiten

Advanced Database Mapping wird relevant, wenn sich eine Anforderung nicht allein als Übertragung eines unterstützten Anwendungsfelds in ein anderes unterstütztes Feld beschreiben lässt. Es erweitert das unterstützte Mapping auf zulässige Felder und zugrunde liegende Datenbankspalten, einschließlich plattformspezifischer und benutzerdefinierter Felder, sofern sie innerhalb der Standardfunktion liegen.

Die Verfügbarkeit ist bewusst enger gefasst, weil Verarbeitung auf Datenbankebene von der Architektur auf beiden Seiten der Migration abhängt. Sowohl die Quellplattform als auch die Zielplattform müssen Open-Source sein. Ist eine der beiden Plattformen Non-Open-Source, steht Advanced Database Mapping nicht zur Verfügung.

Diese Architekturvoraussetzung beantwortet nur die erste Frage der Eignungsprüfung. Ein grundsätzlich geeigneter Plattformpfad macht nicht automatisch jedes Feld oder jede Spalte zuordenbar. Die konkrete Anforderung muss weiterhin geprüft werden auf:

• Teilnahme eines unterstützten Quellfelds oder einer unterstützten Datenbankspalte;
• ein kompatibles Zielfeld oder eine kompatible Zielspalte;
• ausreichende Kompatibilität des Datentyps;
• unterstützte Beziehungen und Datenbedeutung;
• Ausschluss von Tax-Daten aus dem Standard-Mapping-Umfang.

Das Add-on ist daher besonders sinnvoll, wenn das Unternehmen den zu erhaltenden Wert auf Datenbankebene, den kompatiblen Platz im Zielshop und die Nachweise für ein nutzbares Mapping-Ergebnis klar benennen kann.

In der Verarbeitungsreihenfolge läuft Advanced Database Mapping nach Advanced Data Mapping und vor Data Transformation. Diese Position ist wichtig, wenn das Datenbank-Mapping einen Wert festlegt, der anschließend neu berechnet oder umformatiert werden soll. Data Transformation erhält das Ergebnis, das nach beiden Mapping-Schritten vorliegt. Damit kann das Datenbank-Mapping zur direkten Eingabe für die abschließende wertverändernde Regel werden.

Datenbank-Mapping bleibt außerdem von der Implementierung auf der Zielseite getrennt. Das erfolgreiche Speichern eines Werts in einem kompatiblen Zielfeld oder einer Zielspalte beweist nicht, dass ein Theme, eine Erweiterung, ein Anwendungsablauf, eine Steuerregel oder eine Storefront-Funktion diesen Wert wie vorgesehen interpretiert oder anzeigt. Diese Ergebnisse benötigen eine eigene Validierung.

Eigenständige Anwendungsfälle für Advanced Database Mapping

Anwendungsfall: eine unterstützte benutzerdefinierte numerische Product-Spalte als Zielpreis verwenden. Auf einem zulässigen Open-Source-zu-Open-Source-Pfad kann ein Händler eine unterstützte benutzerdefinierte Datenbankspalte wie regional_base_price besitzen, deren Wert ein kompatibles Ziel-Preisfeld oder eine Zielspalte befüllen soll. Advanced Database Mapping ist relevant, weil der Quellwert auf Datenbankebene liegt. Die Architekturvoraussetzung allein genügt jedoch nicht: Die konkrete Quellspalte, das Ziel, die Datentypkompatibilität und der Standardumfang müssen weiterhin bestätigt werden.

Anwendungsfall: einen unterstützten plattformspezifischen Datenbankwert erhalten. Eine Open-Source-Quellplattform kann einen wichtigen Product-Wert in einer plattformspezifischen Datenbankspalte statt in der Standardfeldebene speichern. Verfügt die gewählte Open-Source-Zielplattform über ein kompatibles unterstütztes Ziel und bleibt die Anforderung eine direkte, werterhaltende Zuordnung, kann Advanced Database Mapping diesen Wert in das vorgesehene Zielfeld oder die Zielspalte übertragen. Daraus folgt nicht, dass jedes Theme, jede App, jede Erweiterung oder jeder Arbeitsablauf auf der Zielplattform den gespeicherten Wert automatisch nutzt.

Data Transformation: den endgültigen Zielwert verändern

Data Transformation passt, wenn das Ziel bereits feststeht, aber sich der dort zu speichernde Wert verändern muss.

Typische Muster sind:

• Anwenden einer Rechenregel auf einen numerischen Wert;
• Hinzufügen, Entfernen oder Umstrukturieren von Text durch einen unterstützten Ausdruck;
• Normalisieren von Werten in eine vereinbarte Zieldarstellung;
• Berechnen eines endgültigen Werts aus Daten, die ein vorheriger Mapping-Schritt festgelegt hat.

Die wichtigste Abgrenzung ist einfach: Mapping beantwortet Wohin soll dieser Wert? Transformation beantwortet Welcher Wert soll dort am Ende stehen?

Da Data Transformation zuletzt ausgeführt wird, arbeitet es mit dem Zielwert, der nach Advanced Data Mapping und, sofern zulässig, Advanced Database Mapping vorliegt. Dadurch eignet es sich besonders als letzter Schritt einer zusammengesetzten Anforderung. Legt beispielsweise ein Datenbank-Mapping den Zielwert für Price fest, kann eine nachfolgende Transformation den endgültigen Price aus diesem zugeordneten Wert berechnen, statt von einem früheren Quellfeld auszugehen.

Data Transformation entscheidet weder, welche Datensätze teilnehmen, noch welches Zielfeld oder welche Zielspalte einen Quellwert erhalten soll. Diese Entscheidungen gehören zu den vorherigen Schritten. Eine sauber definierte Transformation beginnt daher mit einem bekannten Zielfeld, einem bekannten Eingabewert nach dem Mapping und einer klaren unterstützten Regel für das gewünschte Ergebnis.

Eigenständige Anwendungsfälle für Data Transformation

Anwendungsfall: den resultierenden Zielpreis um 12 Prozent erhöhen.Ein Händler möchte, dass der Zielwert Regular Price 12 Prozent über dem Wert liegt, den der vorherige Mapping-Schritt festgelegt hat. Data Transformation passt, weil das Ziel bereits bekannt ist und der resultierende Wert verändert werden muss. Eine unterstützte Berechnung wie Regular Price x 1.12 ist deshalb eine Transformation und keine Mapping-Entscheidung.

Anwendungsfall: einen Textwert im Ziel normalisieren. Quelle und Ziel können denselben geschäftlichen Wert mit unterschiedlichen Textkonventionen darstellen. Kann eine unterstützte Transformationsregel den endgültigen Zieltext in die benötigte Darstellung normalisieren, ist Data Transformation das passende Add-on. Die Regel arbeitet mit dem Zielwert, der nach den anwendbaren Mapping-Schritten vorliegt. Sie wählt keine Datensätze aus und entscheidet nicht, welches Zielfeld den Quellwert erhält.

Warum die Reihenfolge der Datenverarbeitung durch Add-ons wichtig ist

Wenn mehrere Add-ons gemeinsam eingesetzt werden, werden sie in einer festen Reihenfolge verarbeitet:

Data Filter -> Advanced Data Mapping -> Advanced Database Mapping -> Data Transformation

Diese Reihenfolge bietet ein klares Modell für zusammengesetzte Migrationsanforderungen:

1. Auswahl: Welche Datensätze dürfen weiterverarbeitet werden?
2. Feldziel: Wo sollen unterstützte Quellfelder abgebildet werden?
3. Ziel auf Datenbankebene: Benötigt eine zulässige Open-Source-zu-Open-Source-Migration eine unterstützte Feld- oder Datenbankspaltenzuordnung über die Standardfeldebene hinaus?
4. Endgültiger Wert: Welcher Zielwert soll nach Abschluss des Mappings entstehen?

Jeder anwendbare Schritt arbeitet mit dem Ergebnis der vorherigen Schritte. Das bedeutet nicht, dass jede Migration alle vier Add-ons benötigt oder dass jedes Add-on dasselbe Feld betreffen muss. Die Anforderung sollte jedoch als geordneter Datenfluss entworfen werden, nicht als Sammlung unabhängiger Regeln.

Häufige Add-on-Kombinationen

Viele reale Anforderungen benötigen nur zwei oder drei Schritte. Wer das Muster erkennt, kann die Eignung leichter prüfen, bevor unnötig individuelle Arbeit angenommen wird.

Muster der geschäftlichen Anforderung	Wahrscheinliche Add-on-Kombination	Warum die Kombination passt
Nur eine definierte Teilmenge von Datensätzen migrieren und anschließend einen ihrer Zielwerte verändern.	Data Filter + Data Transformation	Die Filterung bestimmt die teilnehmenden Datensätze; die Transformation verändert den erforderlichen Wert nur für diese Datensätze.
Ein unterstütztes Quellfeld an ein anderes kompatibles Zielfeld senden und anschließend den resultierenden Wert verändern.	Advanced Data Mapping + Data Transformation	Mapping legt das Ziel fest; die Transformation arbeitet danach mit dem dort vorhandenen Wert.
Einen zulässigen Wert auf Datenbankebene als Zielwert verwenden und anschließend eine Berechnungs- oder Normalisierungsregel anwenden.	Advanced Database Mapping + Data Transformation	Datenbank-Mapping legt den Zielwert fest; die Transformation erzeugt den endgültigen Wert. Für den Datenbank-Mapping-Schritt müssen beide Plattformen Open-Source sein.
Datensätze begrenzen, unterstützte Felder neu zuordnen und anschließend die resultierenden Zielwerte verändern.	Data Filter + Advanced Data Mapping + Data Transformation	Der Ablauf kombiniert Datensatzumfang, Zielsteuerung und Wertänderung, ohne Mapping auf Datenbankebene zu benötigen.
Datensätze begrenzen, unterstütztes Feld-Mapping anwenden, zulässiges Datenbank-Mapping nutzen und anschließend das Endergebnis transformieren.	Alle vier Standard Add-ons	Jeder Schritt löst einen anderen Teil derselben zusammengesetzten Anforderung und liefert das relevante Ergebnis an den nächsten Schritt.

Mehrere Schritte machen ein Projekt nicht automatisch zu einem Custom-Service-Fall. Bleibt jede Operation innerhalb des unterstützten Standardumfangs ihres Add-ons, kann die kombinierte Anforderung vollständig mit Standard Add-ons umgesetzt werden. Individuelle Behandlung wird relevant, wenn eine dieser Operationen selbst eine Modifikation, nicht unterstützte Dateninterpretation, maßgeschneiderte Logik oder eine andere Funktion außerhalb der Standardgrenzen benötigt.

Eine praktische Planungsmethode arbeitet rückwärts vom gewünschten Ergebnis im Zielshop. Bestimmen Sie zuerst den endgültigen Wert oder die endgültige Darstellung. Prüfen Sie dann, ob Transformation, Mapping auf Datenbankebene, Feld-Mapping, Datensatzfilterung oder eine Kombination dieser Steuerungen erforderlich ist.

Beispiel: Vier Add-ons ergänzen sich, um eine zusammenhängende Migrationsanforderung zu erfüllen

Betrachten Sie eine OpenCart-zu-WooCommerce-Migration, bei der die erforderlichen Product-Felder unterstützt werden und die ausgewählte benutzerdefinierte Datenbankspalte die anwendbaren Mapping- und Kompatibilitätsprüfungen besteht. Beide Plattformen sind Open-Source, daher kann der Migrationspfad auf Advanced Database Mapping geprüft werden.

Der Händler möchte vier miteinander verbundene Ergebnisse erreichen:

• nur Products migrieren, die aktiviert sind und noch Bestand haben;
• Short Description aus der Quelle als Description im Ziel verwenden;
• eine unterstützte benutzerdefinierte numerische Product-Datenbankspalte namens regional_base_price als Zielwert Regular Price verwenden;
• den daraus resultierenden Regular Price während der Migration um 12 Prozent erhöhen.

Kein einzelnes Add-on löst die gesamte Anforderung.

Schritt 1: Product-Datensätze auswählen

Data Filter wendet die vereinbarten Product-Bedingungen an, beispielsweise aktivierter Status und ein Bestand größer als null. Products, die die Bedingungen nicht erfüllen, werden für diesen Migrationsumfang nicht in den verbleibenden Add-on-Schritten weiterverarbeitet.

Der Filter löst ausschließlich die Auswahlfrage. Er entscheidet nicht, wie Beschreibungen oder Preise im Zielshop dargestellt werden.

Schritt 2: das unterstützte Beschreibungsfeld neu zuordnen

Advanced Data Mapping ordnet das unterstützte Quellfeld Short Description dem kompatiblen Zielfeld Description zu.

Dadurch ändert sich das Ziel des unterstützten Werts. Der Mapping-Schritt bleibt zugleich klar von späteren Wertänderungen getrennt.

Schritt 3: den Preis aus einer Quelle auf Datenbankebene festlegen

Advanced Database Mapping ordnet den unterstützten benutzerdefinierten numerischen Datenbankwert regional_base_pricedem kompatiblen Ziel Regular Price zu.

Dieser Schritt ist im Beispiel nur möglich, weil beide Seiten des Migrationspfads Open-Source-Plattformen sind und für das konkrete Feld beziehungsweise die konkrete Spalte angenommen wird, dass die Eignungsprüfungen des Standard Add-on bestanden werden. Eine benutzerdefinierte Spalte darf nicht allein deshalb als geeignet gelten, weil Advanced Database Mapping grundsätzlich existiert.

Schritt 4: den endgültigen Zielpreis berechnen

Data Transformation wendet anschließend die erforderliche Berechnung auf Regular Price an, beispielsweise:

Regular Price x 1.12

Da Data Transformation nach beiden Mapping-Schritten läuft, arbeitet es mit dem durch Advanced Database Mapping festgelegten Regular Price und nicht mit einem anderen früheren Preiswert.

Das Endergebnis zeigt, warum Add-ons als koordinierte Verarbeitungsreihenfolge bewertet werden sollten. Data Filter bestimmt die teilnehmenden Products, die Mapping-Schritte legen fest, wo relevante Informationen dargestellt werden, und Data Transformation erzeugt den endgültig berechneten Preis.

Das migrierte Ergebnis muss weiterhin validiert werden. Das Beispiel zeigt Datenverarbeitung, garantiert aber nicht, dass jede nachgelagerte Preisregel, jedes Theme, jede Erweiterung, jedes Steuerverhalten oder jede Storefront-Darstellung automatisch durch die Migration konfiguriert wird.

Wie Add-ons interagieren, wenn sie dieselben Daten betreffen

Kombinierte Add-ons können auf unterschiedliche Weise zusammenwirken. Wichtiger als die Anzahl der Add-ons ist das jeweilige Interaktionsmuster.

Interaktionsmuster	Was konzeptionell geschieht	Bedeutung für den Leser
Gleiche Datensätze, unterschiedliche Felder	Data Filter legt die teilnehmenden Datensätze fest, während getrennte Mapping- oder Transformationsregeln unterschiedliche Felder dieser Datensätze betreffen.	Die Add-ons sind über den Datensatzumfang koordiniert, auch wenn sie nicht dasselbe Ziel bearbeiten.
Unterschiedliche Mapping-Schritte, dasselbe Ziel	Advanced Data Mapping und Advanced Database Mapping können beide dazu beitragen, wie ein Ziel festgelegt wird. Der später anwendbare Mapping-Schritt bestimmt den Wert, der der nachfolgenden Verarbeitung zur Verfügung steht.	Überlappende Mapping-Regeln sollten eine gemeinsame bewusste Strategie für das Endergebnis ausdrücken, nicht unabhängige Absichten.
Mapping mit anschließender Transformation	Ein Mapping-Schritt legt Zielwert oder Ziel fest, anschließend verändert Data Transformation den nach dem Mapping vorhandenen Wert.	Transformationsregeln sollten auf dem Mapping-Ergebnis basieren, nicht auf einem früheren Quellwert, der nicht mehr die relevante Eingabe ist.
Filterung mit nachgelagerter Verarbeitung	Data Filter schließt Datensätze aus der teilnehmenden Migrationsmenge aus, bevor Mapping oder Transformation beginnen.	Nachgelagerte Add-ons sollten anhand der gefilterten Datensatzmenge bewertet werden, die sie tatsächlich erreicht.

Dieses Interaktionsmodell erleichtert die Prüfung komplexer Anforderungen. Ein Händler kann eine geschäftliche Anforderung in Datensatzumfang, Ziel, Darstellung auf Datenbankebene und Logik des endgültigen Werts zerlegen und anschließend prüfen, ob sich diese Teile gegenseitig ergänzen oder widersprüchliche Annahmen erzeugen.

Besonders sensibel ist der Fall, dass mehrere Mapping-Regeln dasselbe Zielfeld oder dieselbe Zielspalte betreffen. Dann bestimmt die Verarbeitungsreihenfolge den Wert, der Data Transformation zur Verfügung steht. Der sicherste Entwurf beginnt beim gewünschten endgültigen Wert im Zielshop und verfolgt die Reihenfolge rückwärts, um zu bestätigen, welcher Schritt welches Zwischenergebnis festlegen soll.

Diese Rückwärtsprüfung ist auch hilfreich, wenn Add-ons unterschiedliche Felder betreffen. Sie macht unnötige Regeln, ungeeignete Ziele, Transformationen mit der falschen Eingabe oder Datensätze sichtbar, die vor Beginn der späteren Verarbeitung hätten ausgeschlossen werden sollen.

Kompatibilität bedeutet mehr als übereinstimmende Feldnamen

Ein Quellfeld und ein Zielfeld können ähnliche Bezeichnungen tragen, ohne kompatibel zu sein. Mapping-Entscheidungen sollten berücksichtigen, ob die Zielplattform den Quellwert korrekt darstellen kann.

Bei den Mapping-Add-ons muss das Zielfeld oder die Zielspalte ausreichende Kapazität des Datentyps für den Quellwert besitzen. Ein numerischer Quellwert kann häufig in einem Textziel dargestellt werden. Beliebiger Text kann dagegen nicht sicher als Zahl behandelt werden, nur weil einige Beispielwerte numerisch aussehen. Ist die Kompatibilität unklar, muss sie validiert und darf nicht angenommen werden.

Die Mapping-Add-ons haben außerdem funktionale Grenzen. Tax-Daten liegen außerhalb des unterstützten Umfangs von Advanced Data Mapping und Advanced Database Mapping. Anforderungen an nicht unterstützte Datenkategorien, Felder, Spalten, Beziehungen, Skripte oder Anwendungsfunktionen können eine Prüfung als Tailored Add-on, Custom Add-on oder im erweiterten Custom-Service-Umfang erfordern.

Standard, Tailored und Custom Add-ons

Benötigte Funktion und erforderlicher Grad der Anpassung sind zwei verschiedene Entscheidungen.

Add-on-Stufe	Bedeutung	Preisbehandlung
Standard Add-on	Ein vorgefertigtes Add-on, das innerhalb seines fest definierten unterstützten Umfangs verwendet wird.	Fester Katalogpreis.
Tailored Add-on	Eine Funktion eines Standard Add-on, die Abstimmung, Modifikation oder einen erweiterten Umfang über die Standardfunktion hinaus benötigt.	Prüfung und Angebot über Custom Service.
Custom Add-on	Maßgeschneiderte Add-on-Funktionalität außerhalb des Funktionsumfangs des Standard-Add-on-Katalogs.	Prüfung und Angebot über Custom Service.

Eine Anforderung wird nicht allein deshalb zu Custom Service, weil mehrere Standard Add-ons kombiniert werden. Passt jede Operation in den jeweiligen Standardumfang, kann der kombinierte Ablauf vollständig aus Standard Add-ons bestehen.

Ebenso machen die Begriffe custom field oder database column ein Projekt nicht automatisch individuell. Die Anforderung sollte zuerst anhand der unterstützten Grenzen von Advanced Data Mapping oder Advanced Database Mapping geprüft werden. Custom Service wird relevant, wenn das gewünschte Ergebnis über das hinausgeht, was diese unterstützten Steuerungen leisten können.

Add-ons und Custom Service lösen unterschiedliche Probleme

Add-ons behandeln klar abgegrenzte Anforderungen an die Datenverarbeitung. Custom Service übernimmt umfassendere individuelle oder nicht standardmäßige Arbeiten, wenn die Anforderung nicht innerhalb der unterstützten Migration und der Standard-Add-on-Funktionen erfüllt werden kann.

Custom Service wird relevant, wenn die benötigte Operation nicht mehr in das klar begrenzte Standard-Add-on-Modell passt. Typische Signale sind nicht unterstützte Daten aus Drittanwendungen oder Erweiterungen, maßgeschneiderte Skripte oder API-Verarbeitung, nicht standardmäßige Beziehungen oder Migrationslogik sowie Add-on-Funktionen, die über den Standardkatalog hinaus angepasst oder entwickelt werden müssen. Umfassendere nicht standardmäßige Anforderungen werden in den speziellen Hinweisen zu Custom Service behandelt. Entscheidend ist hier, zu erkennen, wann ein Add-on allein die Arbeit nicht mehr ausreichend beschreibt.

Eine Migration kann Standard Add-ons auch innerhalb eines umfassenderen Custom-Service-Umfangs verwenden. Custom Service verändert nicht die Funktion der einzelnen Add-ons, sondern die weitergehende Behandlung, die für projektspezifische Arbeiten erforderlich ist.

Zusammenhang zwischen Add-ons, Entity Points und Preis

Entity Points und Add-ons beantworten unterschiedliche Planungsfragen.

Entity Points messen gezählte Migrationskapazität für Products, Customers, Orders und Blog Posts. Add-ons steuern bestimmte unterstützte Verarbeitungsschritte. Ein Add-on erzeugt kein neues Entity-Points-Gewicht, und eine nicht gezählte Datenkategorie wird nicht allein deshalb gezählt, weil ein Add-on dafür verwendet wird.

Die oben angegebenen Festpreise für Standard Add-ons sind von der Entity-Points-Kapazität getrennt. Tailored Add-ons und Custom Add-ons verwenden diese festen Standardpreise nicht als endgültiges Projektangebot, weil ihre zusätzliche Arbeit im Rahmen von Custom Service geprüft wird.

Wird ein geeignetes Add-on später derselben erworbenen Migration hinzugefügt, folgt das entsprechende Upgrade dem Prinzip der reinen Preisdifferenz. Das Add-on verändert das Servicepaket dieser Migration. Es ändert weder den festen Pfad von Quellplattform zu Zielplattform noch startet es die Servicelaufzeit neu.

Eignung von Add-ons für eine reale Anforderung bewerten

Eine sinnvolle Add-on-Prüfung beginnt mit dem gewünschten Ergebnis im Zielshop und nicht mit den Namen der Add-ons. Anschließend lässt sich die geschäftliche Anforderung in die Entscheidungen zerlegen, die von den vier Verarbeitungsschritten tatsächlich gesteuert werden.

Prüffrage	Was die Antwort zeigt
Welche Datensätze sollen am Ergebnis teilnehmen?	Ob Data Filterbenötigt wird.
Ist der Quellwert bereits korrekt, soll aber in einem anderen unterstützten Zielfeld landen?	Ob Advanced Data Mapping benötigt wird.
Hängt die Anforderung von einem zugrunde liegenden Datenbankfeld oder einer Datenbankspalte ab, und sind beide Plattformen Open-Source?	Ob Advanced Database Mappinggeprüft werden sollte.
Muss sich nach Abschluss des Mappings der Zielwert selbst verändern?	Ob Data Transformationbenötigt wird.
Welche Nachweise bestätigen, dass resultierender Wert, Ziel, Beziehung und geschäftliche Bedeutung korrekt sind?	Was validiert werden muss, bevor die Anforderung als erfüllt gelten kann.

Auch die Formulierung einer Anforderung liefert oft hilfreiche Hinweise. Wörter wie einschließen, ausschließen, nur oder Bedingungbeschreiben meist Datensatzauswahl. Zuordnen, platzieren, sendenoder Ziel beschreiben meist Feld-Mapping. Hinweise auf Datenbankspalten, plattformspezifische Felder oder benutzerdefinierte Felder können Advanced Database Mapping erfordern, wenn der gesamte Plattformpfad und der unterstützte Umfang geeignet sind. Berechnen, normalisieren, anhängen, entfernen, konvertieren oder umstrukturieren weisen meist auf eine Werttransformation hin.

Diese Signale dienen der Diagnose und sind keine automatische Freigabe. Ein Feld mit der passenden Bezeichnung kann trotzdem einen inkompatiblen Datentyp besitzen. Ein benutzerdefiniertes Feld kann in ein Standard Mapping Add-on passen, während ein anderes benutzerdefiniertes Feld von nicht unterstützter Logik abhängt und Custom Service benötigt. Eine Open-Source-zu-Open-Source-Migration kann architektonisch für Advanced Database Mapping geeignet sein, während die konkrete Datenbankspalte weiterhin außerhalb des unterstützten Umfangs liegt.

Eine belastbare Anforderung beschreibt daher fünf Punkte gemeinsam: die betroffene Datenkategorie und die betroffenen Datensätze, den Quellwert, das vorgesehene Ziel, eine gegebenenfalls anzuwendende endgültige Wertregel und die Nachweise für das gewünschte Ergebnis. Sobald diese Elemente klar sind, kann die Add-on-Kombination anhand der unterstützten Grenzen bewertet werden, statt nur aufgrund eines Funktionsnamens ausgewählt zu werden.

Dieser ergebnisorientierte Ansatz verhindert zwei gegensätzliche Fehler. Er vermeidet, eine unterstützte Anforderung allein wegen mehrerer beteiligter Steuerungen zu Custom Service hochzustufen. Gleichzeitig verhindert er, ein Standard Add-on über seine unterstützte Funktion hinaus zu dehnen, nur weil der Name der Anforderung ähnlich klingt.

Fazit

Next-Cart Add-ons sind am nützlichsten, wenn sie als unterschiedliche Schritte eines gemeinsamen unterstützten Datenverarbeitungsmodells verstanden werden und nicht als lose Funktionsliste. Data Filter wählt Datensätze aus. Advanced Data Mapping ändert unterstützte Feldziele. Advanced Database Mapping erweitert zulässiges Mapping auf unterstützte Felder und Datenbankspalten, wenn sowohl Quellplattform als auch Zielplattform Open-Source sind. Data Transformation verändert die resultierenden Zielwerte.

Die feste Verarbeitungsreihenfolge gehört zur Entscheidung. Jeder anwendbare Schritt arbeitet mit dem Ergebnis, das frühere Schritte festgelegt haben. Kombinierte Anforderungen sollten daher vom endgültigen Ergebnis im Zielshop her entworfen und als ein koordinierter Ablauf validiert werden.

Standard Add-ons bleiben klar begrenzte unterstützte Funktionen. Benötigt die Funktion eine Modifikation, erweiterte Logik, maßgeschneiderte Entwicklung oder nicht unterstützte Verarbeitung, gehört die Anforderung in den Bereich Tailored Add-on, Custom Add-on oder einen umfassenderen Custom-Service-Umfang, statt die Standardfunktion über ihre vorgesehene Grenze hinaus auszudehnen.

Häufige Fragen

Wie erkennt ein Unternehmen, ob es ein Add-on oder mehrere benötigt?

Zerlegen Sie die Anforderung in Datensatzauswahl, Feldziel, Darstellung auf Datenbankebene und abschließende Wertänderung. Enthält das geschäftliche Ziel mehr als eine dieser Operationen, können mehrere Add-ons sinnvoll sein. Entscheidend ist weniger ihre Anzahl als die Frage, ob jeder Schritt einen klar abgegrenzten, unterstützten Teil desselben Ergebnisses löst.

Können mehrere Standard Add-ons in derselben Migration ohne Custom Service verwendet werden?

Ja. Mehrere Standard Add-ons machen die Migration nicht automatisch zu einem Custom-Service-Fall. Jede Operation muss im unterstützten Standardumfang des jeweiligen Add-ons bleiben, die Schritte sollten eine zusammenhängende Verarbeitungsstrategie bilden, und das Gesamtergebnis muss anhand des vorgesehenen Geschäftsergebnisses validiert werden.

Ist die Reihenfolge wichtig, wenn mehrere Add-ons gemeinsam eingesetzt werden?

Ja. Die Verarbeitungsreihenfolge lautet Data Filter, Advanced Data Mapping, Advanced Database Mapping und anschließend Data Transformation. Jeder anwendbare Schritt arbeitet mit dem Ergebnis der vorherigen Schritte. Überlappende Regeln sollten deshalb als eine gemeinsame Sequenz geplant werden.

Ist Advanced Database Mapping verfügbar, wenn nur die Zielplattform Open-Source ist?

Nein. Sowohl die Quellplattform als auch die Zielplattform müssen Open-Source sein. Ist eine der beiden Plattformen Non-Open-Source, steht das Add-on nicht zur Verfügung.

Was ist der Unterschied zwischen Advanced Data Mapping und Data Transformation?

Advanced Data Mapping ändert das kompatible Ziel eines unterstützten Quellfelds, ohne den Wert im Mapping-Schritt zu verändern. Data Transformation verändert den ausgewählten Zielwert selbst. Werden beide eingesetzt, legt das Mapping zunächst fest, wohin der Wert gehört. Anschließend wendet die Transformation die unterstützte Regel an, die den endgültigen Wert verändert.

Können zwei Mapping-Add-ons dasselbe Ziel beeinflussen?

Sie können Teil einer Anforderung sein, die auf dasselbe Ziel zuläuft. Die Regeln müssen jedoch als eine Sequenz und nicht als unabhängige Mappings entworfen werden. Advanced Database Mapping wird nach Advanced Data Mapping ausgeführt. Daher steht der Wert aus dem späteren anwendbaren Mapping-Schritt für Data Transformation zur Verfügung.

Kann ein benutzerdefiniertes Feld oder eine Datenbankspalte trotzdem in ein Standard Add-on passen?

Möglicherweise. Ein benutzerdefiniertes Feld oder eine Datenbankspalte sollte zuerst anhand des unterstützten Umfangs von Advanced Data Mapping beziehungsweise Advanced Database Mapping geprüft werden. Das Wort custom bedeutet nicht automatisch Custom Service. Nicht unterstützte oder maßgeschneiderte Funktionsanforderungen benötigen jedoch eine zusätzliche Prüfung.

Unterstützen Advanced Data Mapping und Advanced Database Mapping Tax-Daten?

Nein. Tax-Daten liegen außerhalb des unterstützten Umfangs beider Mapping-Add-ons.

Verändern Add-ons die Berechnung der Entity Points?

Nein. Entity Points verwenden weiterhin das Modell für gezählte Products, Customers, Orders und Blog Posts. Add-ons beeinflussen unterstützte Verarbeitung und Preis getrennt von der Entity-Points-Kapazität.

Wann sollte eine Add-on-Anforderung in Custom Service übergehen?

Custom Service ist angemessen, wenn die Anforderung die unterstützten Funktionen der Standardmigration und der Add-ons überschreitet. Dazu gehören Tailored- oder Custom-Add-on-Arbeiten sowie andere maßgeschneiderte oder nicht unterstützte Datenverarbeitungslogik. Entscheidend ist die unterstützte Grenze, nicht allein das Vorhandensein mehrerer Add-ons, eines benutzerdefinierten Felds oder einer Datenbankspalte.