WMS-integration hos Constellation Cold Logistics: från databasskrivningar till en datamodell

En delad mapp och filer som skrevs rakt in i databasen

Utgångsläget var en gemensam SFTP-mapp på en lokal server, kopplad till AS/400. Alla kunder lämnade filer på samma ställe, och filerna hämtades och skrevs direkt in i databastabellerna, meddelande för meddelande. Det fanns inget gemensamt lager och ingen gemensam struktur. Varje kunds särdrag satt i den kod som skrev in deras filer i tabellerna, och en ny kund innebar att samma sak byggdes en gång till. En del kunder använde inte EDI alls.

Det dolda problemet

Det var inte bara datamodellen som var odokumenterad. Det var rördragningen också.

• Varje ny kundkoppling väckte samma frågor: hämtar vi filen, eller levererar de den? SFTP eller ett API som vi själva ska hämta från? Och vilket format finns egentligen i filen?
• Kunskapen satt hos enskilda personer, inte i dokumentation. De ursprungliga integrationerna var byggda av ett fåtal mycket erfarna personer, och när de går vidare försvinner skälen bakom besluten med dem.
• Gamla kundprofiler sparades som mallar, enbart för att nästa onboarding skulle ha något att kopiera från.
• AS/400-tabellerna som allt skrevs in i var lika odokumenterade som filerna som kom in.

Det är som att ärva ett hus utan ritningar, där hälften av rören sitter inne i väggarna. Innan man kan dra nya rör måste man ta reda på var de gamla faktiskt går.

En intern modell per meddelandetyp

Kärnan i lösningen är en kanonisk datamodell, på engelska en canonical data model eller CDM, för varje meddelandetyp: ordrar, leveransaviseringar, inleveranser, justeringar med flera. Det är ett standardiserat internt format som Constellation själva har full kontroll över. Modellen definierades utifrån stora mängder riktiga produktionsdata från de olika kunderna, analyserade med hjälp av AI, så att den håller generellt och inte är formad efter en enskild kunds särdrag. Den fastställer de fält som minst måste finnas för att en kund över huvud taget ska kunna kopplas på.

Se det som ett gemensamt arbetsspråk inom diplomatin. I stället för att varje land ska ha en tolk till varje annat land har varje land en tolk: från det egna språket till det gemensamma och tillbaka. Tillkommer ett nytt land tillkommer en tolk. De andra rör man inte.

Så ser en order ut i modellen

Två nivåer i raderna, pall och under den kolli, gör att spårbarheten kan ligga på den nivå som den enskilda kunden spåras på. Onboarding är just den här övningen, en enda gång: kundens fält till modellen, in och ut. Allt längre fram i kedjan finns redan.

Så skickar kunderna det, och så kräver modellen det

Varje meddelande kan spåras, och varje särdrag är inkapslat

Varje meddelande i modellen bär sina egna metadata: källsystem, modellversion, status och tidsstämpel. Går något fel (felaktiga data från en kund, ett fält som saknas, en leverans som misslyckas) kan det spåras till exakt vilket meddelande, vilken kund och vilken punkt i kedjan. Möjligheten att bevisa och spåra vad som hände med data, och inte bara flytta dem, var ett av de viktigaste skälen till att Constellation valde Lobster som mellanled.

• Kundspecifik logik finns i kundens egen profil, inte utspridd i kärnprocessen. En kunds undantag kan inte slå ut en annan kunds flöde, och kärnan förblir läsbar.
• En ny kund är en mappningsuppgift: kundens format till och från modellen, plus transporten. Resten av flödet finns redan, med de obligatoriska fälten definierade.
• Ingen inlåsning till ett visst lagersystem. I dag är det Infor WMS. Byts det ändras bara mappningen från modellen till lagersystemet, och ett extra lagersystem från ett förvärv är ett tillägg, inte en migrering.

Målet: onboarding på ungefär två månader

Tidigare innebar en enskild kunds onboarding månader av fram och tillbaka, oftast sex till åtta månader. Med modellen på plats är målet för en ny koppling omkring två månader, och den första kunden kopplas just nu på enligt den nya modellen. Planen är fler danska kundkopplingar och därefter koncernens andra länder. Det första lagret går enligt planen i drift på Infor WMS i november 2026, och efter månader av tester håller både standardprocesserna och undantagen runt dem.

Bort från den lokala servern och ut som API:er

Allt ovan är byggt och i drift. Det som följer är riktningen, inte leveransen.

• Kunderna flyttas bort från den AS/400-kopplade SFTP-mappen och över till Lobster: minst SFTP som hostas i Lobster, HTTP direkt för dem som klarar API. Poängen är inte att avskaffa SFTP, för Lobster talar nästan vilket protokoll som helst. Poängen är att lämna den lokala servern.
• Modellen och rapporterna exponeras som externa API:er med Lobsters egen OAuth2-tjänst och behörighetsstyrning i API Manager, så att kunderna själva kan hämta sina data när de vill.
• Onboarding via Trading Partner Manager, där partneruppsättning, transport och behörigheter samlas på ett ställe, så att en API-redo kund blir ett konfigurationssteg i stället för ett utvecklingsprojekt.
• Inte alla kunder behöver, eller har kapacitet för, en fullständig EDI-integration. Visionen är en WebEDI-portal för de mindre, där order- och lagerdata visas i webbläsaren utan att någon EDI behöver sättas upp.

Lösningen var från början tänkt för flera lager och flera länder, uppdelad per kund som en egenskap i strukturen, inte som ett tillägg. Varje förvärv i koncernen kommer med sina egna system och sin egen version av AS/400, precis som Danmark gjorde. Mönstret som har tagits fram här är alltså inte en dansk lösning, utan en återanvändbar ritning för nästa förvärv.