Maskinrummet – DAL-doktrinen

(Del 3 av den 6-delade serien “Migrationshandboken”)

I del 1definierade vi strategin och den tydliga metoden. I del 2etablerade vi styrningen och vikten av användarberikning. Nu är mötena över. Styrelserummet är tomt. Det är bara du, servern och en fil som innehåller tusentals poster med artikelmastrar.

Välkommen till Maskinrummet.

Det är här den teoretiska planen möter den hårda verkligheten av bitar och byte. I Infor LN-ekosystemet missförstås ofta denna fas. Många konsulter tror att migrering bara handlar om att skriva ett skript för att skicka data till tabeller. De har fel. ERP-system som Infor LN är en komplex organism av affärslogik. Om du försöker tvångsmata det kommer det att kvävas.

Idag utforskar vi migreringens tekniska kärna: utbytesramverket, den icke-förhandlingsbara DAL-doktrinenoch den psykologiska fällan med falskt positiva resultat.

Verktygsuppsättningen: mer än bara SQL

Förr i tiden med lokala ERP-system hade vi direktåtkomst till databasen. Om vi ​​ville skapa en kund kunde vi teoretiskt sett skriva ett SQL-uttryck direkt i tabellen. I den moderna CloudSuite-eran är den dörren låst och bevakad. Vi måste använda de officiella verktygen som plattformen tillhandahåller.

Även om marknaden erbjuder kraftfulla externa verktyg och Infor själva tillhandahåller alternativ som Excel-tillägg (perfekt för mindre, ad hoc-uppdateringar), kommer vi att nämna Exchange Schemes som det primära verktyget för migrering eftersom det är en inbyggd lösning som redan är tillgänglig för alla att använda.

Utbytesscheman representerar den bästa kompromissen mellan prestanda och integritet. Eftersom det är ett inbyggt verktyg som är direkt inbäddat i Infor LN bearbetar det data lokalt på servern, men respekterar fullt ut affärslogikvalidering (DAL). Det är den tunga lyftaren som är utformad för just detta ändamål.

Tänk på Exchange Schemes inte som ett enkelt importverktyg, utan som en översättningsmotor. Det låter dig mappa dina platta filer till de interna LN-tabellstrukturerna och hantera konverteringarna direkt. Oavsett om din källfil använder specifika datumformat eller kräver komplex fältmappning, konverterar Exchange den automatiskt till LN:s interna logik. Det möjliggör också batchhantering, vilket säkerställer att du kan gruppera importer och respektera beroenden, till exempel att läsa in artikelgrupper innan själva artikelmallarna.

DAL-doktrinen: Hastighet kontra säkerhet

Detta är det viktigaste tekniska konceptet i hela serien. Infor LN förlitar sig på ett dataåtkomstlager (DAL). Detta är ett programvarulager som ligger mellan användargränssnittet (eller importverktyget) och de fysiska databastabellerna.

För teknisk information om hur DAL upprätthåller affärsintegritet, se den officiella Infor LN DAL-översikten.

När du skapar en produktionsorder manuellt på en skärm skriver du inte bara in data. DAL arbetar i bakgrunden för att utföra validering och säkerställa att artikeln finns. Den hanterar standardvärden och fyller automatiskt i lagret baserat på artikelgruppslogik. Viktigast av allt hanterar den utlösare.
Att skapa en rubrik kan utlösa skapandet av standardrutningsoperationer eller allokera lager i en helt annan tabell.

Låt oss vara ärliga: DAL har för- och nackdelar. Den största nackdelen är hastighet, eftersom validering av logik post för post är beräkningsmässigt dyrt. Att inaktivera DAL ökar migreringshastigheten drastiskt, vilket gör att du kan ladda miljontals rader på några minuter. Denna hastighet kommer dock till ett högt pris: säkerhet.

När du kringgår DAL (med hjälp av tabelluppdateringslägen) tar du bort ett skyddsnät. Systemet utför inga integritetskontroller vid insättningstillfället. Det accepterar blint all data du matar det med. Risken är att du kanske laddar in smutsig data som ser bra ut i databastabellen, men skapar kaos i det ögonblick en användare försöker interagera med den.

Till exempel kan du läsa in ett objekt, men eftersom DAL inte aktiverades lämnas viktiga dolda fält noll. När en användare klickar på det objektet i användargränssnittet kraschar skärmen eller det visas kryptiska fel.

Min uppfattning: att kringgå DAL är inte förbjudet, men det kräver extrem försiktighet. Det bör reserveras för exceptionella fall och endast hanteras av tekniska expertkonsulter som vet exakt vilka dolda fält och relaterade tabeller som måste fyllas i manuellt för att hålla systemet konsekvent. För de flesta migreringar är den långsammare och säkrare DAL-vägen det säkraste valet.

Den falska positiva fällan

När du väl har börjat använda DAL:n måste du förbereda dig för ett specifikt fenomen som orsakar panik: det falska positiva felet. DAL:n är utformad för att vara grundlig. När du importerar en komplex struktur, som en inköpsorder med 50 rader, validerar systemet varje rad individuellt. Men för varje rad som bearbetas validerar DAL ofta om logiken i rubriken för att säkerställa konsekvens.

Tänk dig att migrera en inköpsorder där leverantören flaggas med en signalkod. När den första raden laddas kontrollerar DAL-filen rubriken och skriver ett fel i loggen: Leverantören har kvalitetsproblem. När den andra raden laddas skriver den felet igen. När du är klar ser du en logg med 500 fel. I verkligheten har du migrerat 10 ordrar, och systemet påminde dig bara 500 gånger om en varning.

För att hantera detta måste teamet som ansvarar för migreringen filtrera loggarna. Identifiera dessa repetitiva, icke-blockerande logikmeddelanden under testkörningar och skapa en säker lista med koder som egentligen bara är brus. Om du inte förklarar denna mekanism för företagsanvändarna i förväg kommer de att förlora förtroendet för dataintegriteten när de ser en röd logg.

Prestanda kontra integritet

Låt oss gå över till en annan spelplan. Vi pratar inte bara om hastigheten för insättning av råa data, utan om att hantera det kritiska Cutover-fönstret. När man hanterar massiva datavolymer, som att migrera tusentals öppna orderrader, kan den uppskattade bearbetningstiden lätt överstiga det tillgängliga 48-timmarsfönstret för helger.

Lösningen är inte att kringgå DAL:n, utan att optimera din batchstrategi genom parallell bearbetning. Istället för att ladda en massiv fil sekventiellt, dela upp dina data i mindre, logiska bitar. Kör flera batcher samtidigt på olika datamängder som inte kolliderar på samma tabeller. Denna metod låter dig mätta serverns processorkraft och passa in den massiva arbetsbelastningen i helgens schema utan att någonsin kompromissa med DAL:ns säkerhet och integritet.

Slutsats

Vi har valt ut våra verktyg. Vi vet hur man läser loggarna utan att få panik. Motorn är redo, men en högpresterande motor är värdelös om man inte känner till banan.

I nästa del bygger vi kartan. Vi kommer att prata om Cutover Migration Plan, huvuddokumentet som dikterar exakt vad som händer, när det händer och vem som trycker på knappen under den kritiska Go-Live-helgen.

Skriven av Andrea Guaccio 

26 mars 2026