De machinekamer – DAL-doctrine

(Deel 3 van de 6-delige serie "Het migratiehandboek")

In deel 1hebben we de strategie en de Clean Cut-aanpak gedefinieerd. In deel 2hebben we de governance en het belang van gebruikersverrijking vastgesteld. Nu zijn de vergaderingen voorbij. De vergaderzaal is leeg. Het zijn alleen u, de server en een bestand met duizenden records van artikelstamgegevens.

Welkom in de machinekamer.

Dit is waar het theoretische plan botst met de harde realiteit van bits en bytes. In het Infor LN-ecosysteem wordt deze fase vaak verkeerd begrepen. Veel consultants denken dat migratie slechts een kwestie is van een script schrijven om data in tabellen te plaatsen. Ze hebben het mis. ERP-systemen zoals Infor LN zijn een complex organisme van bedrijfslogica. Als je probeert er data in te persen, loopt het vast.

Vandaag duiken we in de technische kern van de migratie: het Exchange Framework, de niet-onderhandelbare DAL-doctrineen de psychologische valkuil van valse positieven.

De toolset: meer dan alleen SQL

In de tijd van on-premise ERP-systemen hadden we directe toegang tot de database. Als we een klant wilden aanmaken, konden we in theorie een SQL-statement rechtstreeks in de tabel invoeren. In het moderne CloudSuite-tijdperk is die mogelijkheid niet meer beschikbaar. We moeten de officiële tools van het platform gebruiken.

Hoewel de markt krachtige externe tools biedt en Infor zelf alternatieven zoals Excel-invoegtoepassingen (perfect voor kleinere, ad-hoc updates), noemen we Exchange Schemes als het belangrijkste middel voor migratie, omdat het een ingebouwde oplossing is die al voor iedereen beschikbaar is.

Exchange Schemes vertegenwoordigt het beste compromis tussen prestatie en integriteit. Als een native tool die direct in Infor LN is geïntegreerd, verwerkt het gegevens lokaal op de server, maar respecteert het volledig de validatie van de bedrijfslogica (DAL). Het is de krachtige tool die precies voor dit doel is ontworpen.

Beschouw Exchange Schemes niet als een simpele importtool, maar als een vertaalengine. Hiermee kunt u uw platte bestanden koppelen aan de interne LN-tabelstructuren, waarbij de conversies direct worden uitgevoerd. Of uw bronbestand nu specifieke datumformaten gebruikt of complexe veldtoewijzing vereist, Exchange converteert het automatisch naar de interne LN-logica. Het biedt ook de mogelijkheid tot batchbeheer, zodat u importen kunt groeperen en rekening kunt houden met afhankelijkheden, zoals het laden van artikelgroepen vóór de artikelstamgegevens zelf.

De DAL-doctrine: snelheid versus veiligheid

Dit is het meest cruciale technische concept in de hele reeks. Infor LN is gebaseerd op een Data Access Layer (DAL). Dit is een softwarelaag die zich bevindt tussen de gebruikersinterface (of de importtool) en de fysieke databasetabellen.

Voor technische details over hoe de DAL de bedrijfsintegriteit waarborgt, raadpleegt u het officiële Infor LN DAL-overzicht.

Wanneer u handmatig een productieorder aanmaakt in een scherm, typt u niet alleen gegevens in. De DAL (Data Access Line) werkt op de achtergrond om validatie uit te voeren en te controleren of het artikel bestaat. Het systeem verwerkt standaardwaarden en vult het magazijn automatisch in op basis van de logica van de artikelgroep. Het belangrijkste is dat het triggers.
Het aanmaken van een header kan bijvoorbeeld de aanmaak van standaard routingbewerkingen activeren of de toewijzing van voorraad in een volledig andere tabel.

Laten we eerlijk zijn: de DAL heeft voor- en nadelen. Het grootste nadeel is de snelheid, omdat het valideren van de logica record voor record rekenkundig zeer kostbaar is. Het uitschakelen van de DAL verhoogt de migratiesnelheid aanzienlijk, waardoor je miljoenen rijen in enkele minuten kunt laden. Deze snelheid heeft echter een hoge prijs: veiligheid.

Wanneer je de DAL omzeilt (door gebruik te maken van tabelupdatemodi), verwijder je een vangnet. Het systeem voert geen integriteitscontroles uit op het moment van invoeging. Het accepteert blindelings alle gegevens die je invoert. Het risico is dat je mogelijk onjuiste gegevens laadt die er in de databasetabel goed uitzien, maar chaos veroorzaken zodra een gebruiker ermee probeert te werken.

Stel bijvoorbeeld dat u een item laadt, maar omdat de DAL (Data Access Log) niet is geactiveerd, blijven belangrijke verborgen velden leeg. Wanneer een gebruiker vervolgens op dat item in de gebruikersinterface klikt, loopt het scherm vast of worden er onduidelijke foutmeldingen weergegeven.

Mijn mening: het omzeilen van de DAL is niet verboden, maar vereist uiterste voorzichtigheid. Het zou alleen in uitzonderlijke gevallen moeten worden toegepast en uitsluitend door deskundige technische consultants die precies weten welke verborgen velden en bijbehorende tabellen handmatig moeten worden ingevuld om de consistentie van het systeem te waarborgen. Voor de meeste migraties is de langzamere, maar veiligere DAL-route de veiligste keuze.

De valkuil van de valse positieven

Zodra u besluit de DAL te gebruiken, moet u zich voorbereiden op een specifiek fenomeen dat paniek kan veroorzaken: de foutieve positieve uitslag. De DAL is ontworpen om grondig te zijn. Wanneer u een complexe structuur importeert, zoals een inkooporder met 50 regels, valideert het systeem elke regel afzonderlijk. Voor elke verwerkte regel valideert de DAL echter vaak ook de logica van de header opnieuw om consistentie te garanderen.

Stel je voor dat je een inkooporder migreert waarbij de leverancier is gemarkeerd met een signaalcode. Wanneer de eerste regel wordt geladen, controleert de DAL de header en schrijft een foutmelding in het logboek: " Leverancier heeft kwaliteitsproblemen". Wanneer de tweede regel wordt geladen, schrijft het systeem de foutmelding opnieuw. Tegen de tijd dat je klaar bent, zie je een logboek met 500 fouten. In werkelijkheid heb je 10 orders succesvol gemigreerd en heeft het systeem je simpelweg 500 keer herinnerd aan een waarschuwing.

Om dit te beheren, moet het team dat verantwoordelijk is voor de migratie de logbestanden filteren. Identificeer deze repetitieve, niet-blokkerende logicaberichten tijdens testruns en maak een veilige lijst van codes die in feite alleen maar ruis zijn. Als u dit mechanisme niet van tevoren aan de zakelijke gebruikers uitlegt, zullen ze het vertrouwen in de gegevensintegriteit verliezen wanneer ze een rode foutmelding zien.

Prestatie versus integriteit

Laten we het nu over een ander aspect hebben. We hebben het niet alleen over de snelheid waarmee gegevens worden ingevoerd, maar ook over het beheer van het cruciale overgangsvenster. Bij het verwerken van enorme hoeveelheden data, zoals het migreren van duizenden openstaande orderregels, kan de geschatte verwerkingstijd gemakkelijk de beschikbare 48 uur in het weekend overschrijden.

De oplossing is niet om de DAL te omzeilen, maar om uw batchstrategie door middel van parallelle verwerking. In plaats van één enorm bestand sequentieel te laden, kunt u uw gegevens opsplitsen in kleinere, logische delen. Voer meerdere batches gelijktijdig uit op verschillende datasets die elkaar niet overlappen in dezelfde tabellen. Deze aanpak stelt u in staat om de verwerkingskracht van de server volledig te benutten en de enorme werklast in het weekendschema in te passen, zonder ooit de veiligheid en integriteit van de DAL in gevaar te brengen.

Conclusie

We hebben onze gereedschappen geselecteerd. We weten hoe we de logbestanden moeten lezen zonder in paniek te raken. De motor is klaar, maar een krachtige motor is nutteloos als je het circuit niet kent.

In het volgende deel bouwen we de kaart. We bespreken het Cutover Migration Plan, het overkoepelende document dat precies voorschrijft wat er gebeurt, wanneer het gebeurt en wie de knop indrukt tijdens het cruciale Go-Live-weekend.

Geschreven door Andrea Guaccio 

26 maart 2026