Der Maschinenraum – DAL-Doktrin

(Teil 3 der 6-teiligen Serie „Das Migrationshandbuch“)

In Teil 1haben wir die Strategie und den Clean-Cut-Ansatz definiert. In Teil 2haben wir die Governance und die Bedeutung der Benutzeranreicherung dargelegt. Nun sind die Besprechungen beendet. Der Konferenzraum ist leer. Nur Sie, der Server und eine Datei mit Tausenden von Artikelstammdaten sind noch da.

Willkommen im Maschinenraum.

Hier trifft die Theorie auf die harte Realität von Bits und Bytes. Im Infor LN-Ökosystem wird diese Phase oft missverstanden. Viele Berater glauben, Migration sei lediglich eine Frage des Schreibens eines Skripts, um Daten in Tabellen zu übertragen. Das ist ein Irrtum. ERP-Systeme wie Infor LN sind komplexe Systeme mit ausgefeilter Geschäftslogik. Versucht man, sie mit Gewalt zu migrieren, scheitern sie.

Heute beschäftigen wir uns mit dem technischen Kern der Migration: dem Exchange Framework, der unumstößlichen DAL-Doktrinund der psychologischen Falle der Fehlalarme.

Das Toolset: Mehr als nur SQL

In den Zeiten lokaler ERP-Systeme hatten wir direkten Zugriff auf die Datenbank. Wollten wir einen Kunden anlegen, konnten wir theoretisch eine SQL-Anweisung direkt in die Tabelle schreiben. Im modernen CloudSuite-Zeitalter ist dieser Zugriff nicht mehr möglich. Wir müssen die offiziellen Tools der Plattform verwenden.

Obwohl der Markt leistungsstarke externe Tools bietet und Infor selbst Alternativen wie Excel-Add-Ins (ideal für kleinere, Ad-hoc-Aktualisierungen) bereitstellt, möchten wir Exchange Schemes als primäres Mittel zur Migration erwähnen, da es sich um eine integrierte Lösung handelt, die bereits für alle verfügbar ist.

Exchange-Schemata stellen den optimalen Kompromiss zwischen Leistung und Datenintegrität dar. Als natives, direkt in Infor LN integriertes Tool verarbeitet es Daten lokal auf dem Server und berücksichtigt dabei vollständig die Validierung der Geschäftslogik (DAL). Es ist die leistungsstarke Lösung, die genau für diesen Zweck entwickelt wurde.

Exchange Schemes ist nicht nur ein einfaches Importtool, sondern eine Übersetzungs-Engine. Sie ermöglicht die Zuordnung Ihrer Flatfiles zu den internen Tabellenstrukturen von LN und führt die Konvertierungen automatisch durch. Unabhängig davon, ob Ihre Quelldatei bestimmte Datumsformate verwendet oder eine komplexe Feldzuordnung erfordert, konvertiert Exchange sie automatisch in die interne Logik von LN. Zudem ermöglicht es die Stapelverarbeitung, sodass Sie Importe gruppieren und Abhängigkeiten berücksichtigen können, beispielsweise Artikelgruppen vor den Artikelstammdaten laden.

Die DAL-Doktrin: Geschwindigkeit vs. Sicherheit

Dies ist das wichtigste technische Konzept der gesamten Reihe. Infor LN basiert auf einer Datenzugriffsschicht (Data Access Layer, DAL). Dabei handelt es sich um eine Softwareschicht, die zwischen der Benutzeroberfläche (bzw. dem Importtool) und den physischen Datenbanktabellen liegt.

Für technische Details darüber, wie das DAL die Geschäftsintegrität aufrechterhält, verweisen wir auf die offizielle Infor LN DAL-Übersicht.

Wenn Sie einen Produktionsauftrag manuell in einem Bildschirm anlegen, geben Sie nicht nur Daten ein. Die Datenverarbeitungslogik (DAL) führt im Hintergrund Validierungen durch und stellt sicher, dass der Artikel existiert. Sie verwaltet Standardwerte und füllt das Lager automatisch anhand der Artikelgruppenlogik. Vor allem aber verarbeitet sie Trigger.
Das Anlegen eines Kopfes kann beispielsweise die Erstellung von Standard-Routingvorgängen auslösen oder die Bestandszuordnung in einer völlig anderen Tabelle bewirken.

Seien wir ehrlich: Die Datenzugriffsschicht (DAL) hat Vor- und Nachteile. Der größte Nachteil ist die Geschwindigkeit, da die Validierung der Logik Datensatz für Datensatz rechenintensiv ist. Durch Deaktivieren der DAL wird die Migrationsgeschwindigkeit drastisch erhöht, sodass Millionen von Zeilen in wenigen Minuten geladen werden können. Diese Geschwindigkeit hat jedoch ihren Preis: die Sicherheit.

Wenn Sie die Datenzugriffsschicht (DAL) umgehen (z. B. durch Tabellenaktualisierungsmodi), entfernen Sie ein Sicherheitsnetz. Das System führt beim Einfügen keine Integritätsprüfungen durch. Es akzeptiert die eingegebenen Daten ohne weitere Prüfung. Das Risiko besteht darin, dass fehlerhafte Daten zwar in der Datenbanktabelle korrekt erscheinen, aber bei der Interaktion eines Benutzers mit diesen Daten zu Problemen führen können.

Beispielsweise kann es vorkommen, dass ein Element geladen wird, aber da die Datenzugriffsschicht (DAL) nicht ausgeführt wurde, bleiben wichtige, versteckte Felder leer. Wenn ein Benutzer in der Benutzeroberfläche auf dieses Element klickt, stürzt die Anwendung ab oder es werden kryptische Fehlermeldungen angezeigt.

Meine Einschätzung: Das Umgehen der DAL ist zwar nicht verboten, erfordert aber äußerste Vorsicht. Es sollte Ausnahmefällen vorbehalten bleiben und ausschließlich von erfahrenen technischen Beratern durchgeführt werden, die genau wissen, welche versteckten Felder und zugehörigen Tabellen manuell befüllt werden müssen, um die Systemkonsistenz zu gewährleisten. Für die meisten Migrationen ist der langsamere, aber sicherere Weg über die DAL die beste Wahl.

Die Falle des falsch positiven Ergebnisses

Sobald Sie sich für die Verwendung des DAL entschieden haben, müssen Sie sich auf ein Phänomen einstellen, das Panik auslösen kann: den Fehlalarm. Der DAL ist auf Gründlichkeit ausgelegt. Beim Import einer komplexen Struktur, wie beispielsweise einer Bestellung mit 50 Positionen, validiert das System jede Position einzeln. Darüber hinaus überprüft der DAL bei jeder verarbeiteten Position häufig erneut die Logik des Headers, um Konsistenz zu gewährleisten.

Stellen Sie sich vor, Sie migrieren eine Bestellung, bei der der Lieferant mit einem Signalcode gekennzeichnet ist. Beim Laden der ersten Zeile prüft das DAL den Header und protokolliert einen Fehler: „Lieferant hat Qualitätsprobleme“. Beim Laden der zweiten Zeile wird der Fehler erneut protokolliert. Am Ende sehen Sie ein Protokoll mit 500 Fehlern. Tatsächlich haben Sie aber 10 Bestellungen erfolgreich migriert, und das System hat Sie lediglich 500 Mal an eine Warnung erinnert.

Um dies zu gewährleisten, muss das Migrationsteam die Protokolle filtern. Identifizieren Sie während Testläufen wiederkehrende, nicht blockierende Logikmeldungen und erstellen Sie eine Liste mit unbedenklichen Codes, die lediglich irrelevante Informationen enthalten. Wenn Sie diesen Mechanismus den Anwendern nicht im Vorfeld erläutern, verlieren diese das Vertrauen in die Datenintegrität, sobald sie eine Fehlermeldungen im Protokoll sehen.

Leistung vs. Integrität

Kommen wir nun zu einem anderen Aspekt. Es geht nicht nur um die reine Einfügegeschwindigkeit, sondern um die optimale Nutzung des kritischen Umstellungsfensters. Bei der Verarbeitung großer Datenmengen, wie beispielsweise der Migration Tausender offener Auftragspositionen, kann die geschätzte Verarbeitungszeit das verfügbare 48-Stunden-Fenster am Wochenende leicht überschreiten.

Die Lösung besteht nicht darin, die DAL zu umgehen, sondern Ihre Batch-Strategie durch Parallelverarbeitung. Anstatt eine große Datei sequenziell zu laden, teilen Sie Ihre Daten in kleinere, logische Blöcke auf. Führen Sie mehrere Batches gleichzeitig auf verschiedenen Datensätzen aus, die sich nicht in denselben Tabellen überschneiden. Mit diesem Ansatz können Sie die Rechenleistung des Servers voll ausnutzen und die große Arbeitslast in den Wochenendplan integrieren, ohne die Sicherheit und Integrität der DAL zu gefährden.

Abschluss

Wir haben unsere Werkzeuge ausgewählt. Wir wissen, wie wir die Protokolle lesen, ohne in Panik zu geraten. Der Motor ist bereit, aber ein Hochleistungsmotor nützt nichts, wenn man die Rennstrecke nicht kennt.

Im nächsten Teil erstellen wir die Karte. Wir werden über den Umstellungs- und Migrationsplan, das zentrale Dokument, das genau festlegt, was wann passiert und wer am kritischen Go-Live-Wochenende den Startschuss gibt.

Verfasst von Andrea Guaccio 

26. März 2026