Bei einer IS-U-Migration entscheidet sich am Schlüsselkonzept, ob Testzyklen Erkenntnisse liefern oder Fehlerberge. Dieser Beitrag erklärt, wie EMIGALL Alt- und Neu-Schlüssel verwaltet und welche Designentscheidungen getroffen sein müssen, bevor die erste Migrationsdatei entsteht.
Warum Schlüssel das Rückgrat der Migration sind
Die IS-U Migration Workbench (EMIGALL) kennt die IDs Ihres Quellsystems nicht. Beim Laden vergibt SAP eigene Nummern (Geschäftspartnernummer, Vertragskontonummer, Anlagennummer) und merkt sich die Zuordnung: Alt-Schlüssel (OldKey) aus dem Quellsystem gegen Neu-Schlüssel (NewKey) in SAP. Diese Zuordnungstabellen bilden das Key & Status Management, kurz KSM; im Projektjargon spricht man auch von XREF-Tabellen (Cross-Reference).
Jede Beziehung zwischen Objekten läuft über diesen Mechanismus. Ein Vertragskonto verweist auf seinen Geschäftspartner. In der Migrationsdatei steht dort aber nicht die SAP-Partnernummer (die existiert beim Erstellen der Datei noch gar nicht), sondern der OldKey des Partners. EMIGALL löst ihn beim Laden über die XREF-Tabelle auf. Findet es den OldKey nicht, bricht der Satz mit einem Fehler der Fremdschlüsselauflösung ab.
Die Buchhaltung der Migration
Das KSM ist mehr als eine Übersetzungstabelle. Es hält pro Migrationsobjekt fest, welche Alt-Schlüssel bereits geladen wurden, und macht damit drei Dinge erst möglich: Wiederaufsetzen nach einem Abbruch, Delta-Läufe für nachgezogene Datenbestände und die Kontrolle, ob ein Ladelauf vollständig war. Wer nach dem Produktivlauf prüfen will, ob alle 250.000 Vertragskonten angekommen sind, zählt gegen das KSM, nicht gegen ein Bauchgefühl.
Technisch persistiert das KSM die Zuordnungen in der Tabelle TEMKSV. Dort steht je Migrationsobjekt und Alt-Schlüssel der zugehörige SAP-Schlüssel samt Status. Wer eine einzelne Zuordnung nachschlagen will, kommt per SE16N direkt an den Eintrag.
Erneutes Laden und Zurücksetzen
Der Status im KSM verhindert Doppelanlagen: Taucht derselbe OldKey in einem zweiten Ladelauf noch einmal auf, erkennt EMIGALL ihn als bereits migriert und legt das Objekt nicht erneut an. Das macht Wiederholungsläufe nach Teilabbrüchen gefahrlos: Nur die noch offenen Sätze werden verarbeitet.
Für einen frischen Testzyklus heißt das umgekehrt: Die Zuordnungen müssen weg, sonst lädt nichts erneut. In der Praxis setzt man Testsysteme deshalb per System- oder Mandantenkopie auf einen definierten Stand zurück, denn das Einzellöschen von KSM-Einträgen und bereits angelegten Objekten ist fehleranfällig und skaliert nicht über Millionen von Sätzen.
Nummernkreise: interne oder externe Vergabe
Die Neu-Schlüssel stammen in der Regel aus SAP-Nummernkreisen, das System zählt intern hoch. Alternativ lassen sich für einzelne Objekte externe Nummern vergeben, etwa wenn Vertragskontonummern aus Kundensicht erhalten bleiben sollen. Beides will dimensioniert sein: Nummernkreise müssen groß genug für Bestand plus Wachstum sein, und bei externer Vergabe übernimmt das Projekt die Verantwortung für Eindeutigkeit und Formatkonformität, die sonst SAP trägt.
Die 10-Zeichen-Falle
Das Dateiformat erlaubt Alt-Schlüssel bis 30 Zeichen. Das verführt zu sprechenden Konstrukten wie „PARTNER_4711_MANDANT_A". Die Falle: Mehrere zentrale Stammdatenobjekte persistieren den Alt-Schlüssel in ihren Referenztabellen nur 10-stellig. Ein längerer Schlüssel wird dort nicht sauber mitgeführt, und spätestens beim Fremdschlüsselabgleich passt nichts mehr zusammen.
Die Praxisregel: Rohe Quellsystem-IDs sind meist fünf bis sieben Zeichen lang und passen problemlos. Wer Präfixe ergänzt („PART_" plus siebenstellige ID ergibt zwölf Zeichen), reißt die Grenze unbemerkt. Deshalb gehört zur Schlüsselstrategie eine objektweise Längenprüfung und im Zweifel der Verzicht auf Präfixe zugunsten der nackten ID.
Eindeutig pro Objekt – nicht global
Ein verbreitetes Missverständnis: Alt-Schlüssel müssten über die gesamte Migration eindeutig sein. Tatsächlich führt EMIGALL die Zuordnung pro Migrationsobjekt. Der Geschäftspartner „60853" und der Vertrag „60853" kollidieren nicht, denn sie leben in getrennten XREF-Tabellen. Das vereinfacht das Design erheblich: Jedes Objekt kann seine natürliche Quell-ID nutzen.
Innerhalb eines Objekts sind Duplikate dagegen fatal. Klassisches Beispiel aus der Belegwelt: Das Quellsystem verwendet dieselbe Belegnummer für die Soll- und die Haben-Seite eines Zahlungsausgleichs. Wer beide ungefiltert in dasselbe Migrationsobjekt gibt, erzeugt OldKey-Duplikate. Hier muss die Transformationsstrecke vorab filtern oder qualifizieren.
Hausscharf oder wohnungsscharf?
Die spannendste Designfrage stellt sich bei den technischen Stammdaten. SAP trennt das Anschlussobjekt (das Gebäude) von der Verbrauchsstelle (der Wohnung). Viele Quellsysteme führen diese Trennung nicht sauber: Anschlussobjekt-IDs sind dort oft nur laufende Nummern, dieselbe Adresse kann mehrfach vorkommen.
Dann muss das Projekt einen eigenen, hausscharfen Schlüssel konstruieren: pro physischer Adresse genau ein Anschlussobjekt, darunter die wohnungsscharfen Verbrauchsstellen. Ein Haus mit fünf Wohnungen wird zu einem Anschlussobjekt mit fünf Verbrauchsstellen, nicht zu fünf Anschlussobjekten. Diese Entscheidung strahlt aus: Jedes Objekt, das auf Adressebene lebt (etwa Eigentümerzuordnungen), erbt die gewählte Granularität. Wer sie erst im dritten Testzyklus korrigiert, baut faktisch neu.
Wiederholbarkeit über Testzyklen
Eine IS-U-Migration durchläuft typischerweise mehrere vollständige Testzyklen, bevor produktiv geladen wird. Damit die Zyklen vergleichbar sind, müssen Schlüssel deterministisch sein: Derselbe Quelldatenabzug muss immer dieselben OldKeys erzeugen. Laufende Nummern aus der Extraktion, Zeitstempel oder generierte GUIDs verbieten sich, denn sie machen jeden Lauf zum Unikat und jeden Vergleich wertlos.
Deterministische Schlüssel zahlen doppelt aus: Fehlerlisten aus Zyklus zwei lassen sich gegen Zyklus drei diffen, und Delta-Läufe nach dem Produktivstart finden ihre Bezugsobjekte zuverlässig im KSM wieder.
Was schlechte Schlüssel kosten
Schlüsselfehler bleiben nie lokal. Scheitert ein Vertragskonto an einem Duplikat, scheitert der Einzug, der es referenziert, und mit ihm Abschlagsplan, Forderungsbelege und Zahlungen desselben Kunden. Aus einem Fehler in der Fundament-Schicht werden fünf Folgefehler in den Schichten darüber, und die Fehlerprotokolle zeigen zunächst nur die Symptome. Mehr solcher Ketteneffekte beschreibt der Beitrag zu typischen Stolperfallen der Datenmigration; wo die Schlüsselfrage im Gesamtprojekt verortet ist, zeigt Vorgehen & Zeitplan der IS-U-Migration.
Ein Schlüsselkonzept ist in Tagen entworfen und in Monaten korrigiert – es gehört an den Anfang des Projekts, nicht in den ersten Fehlerbericht.
Das Wichtigste in Kürze
- Das Key & Status Management (KSM) verwaltet die Zuordnung Alt-Schlüssel ↔ SAP-Schlüssel pro Migrationsobjekt und macht Wiederaufsetzen und Delta-Läufe möglich.
- Fremdschlüssel werden in Migrationsdateien als OldKeys angegeben und beim Laden über XREF-Tabellen aufgelöst.
- Alt-Schlüssel objektweise auf 10 Zeichen prüfen; Präfixe reißen die Grenze schneller als gedacht.
- Eindeutigkeit gilt pro Migrationsobjekt, nicht global; Duplikate innerhalb eines Objekts sind fatal.
- Hausscharf vs. wohnungsscharf ist eine frühe Designentscheidung mit Ausstrahlung auf viele Objekte.
- Schlüssel müssen deterministisch sein, sonst ist kein Testzyklus mit dem nächsten vergleichbar.