Så bygger ni en Business Central-integration som håller

Ni känner säkert igen läget. En skärm visar order, priser och lager i Business Central. En annan visar webben, och siffrorna stämmer inte riktigt. Då blir det tydligt att en Business Central-integration är en del av er verksamhetsinfrastruktur.

Det är där många projekt börjar gå snett. Problemen börjar i ägarskapet. Ni behöver bestämma ägarskapet för artikelnummer, priser, lagersaldo och förändringar när fält ändras i ett uppgraderat affärssystem eller i en portal.

Därför är Business Central-integrationen er nya infrastruktur

En handelschef öppnar Business Central och ser ett saldo. Kollegan på webben ser ett annat. Båda tror att de jobbar med samma sanning, men de tittar på olika tidsbilder. När det händer i produktion beror problemen ofta på ett otydligt integrationskontrakt.

Svenska företag använder redan digitalisering brett för administration. Enligt Tillväxtverkets undersökning uppgav 55,3 procent att de i stor utsträckning använde IT eller digitalisering för administration, medan 16,2 procent gjorde det i stor utsträckning för affärsutveckling. Det säger mycket om var värdet brukar hamna. Många har redan digitaliserat det interna flödet, men inte kopplat ihop det med försäljning, produktdata och självservice.

Det är vanligt att Business Central-integrationen börjar som en export av kunder eller order. Den fungerar, men den bär bara en liten del av verkligheten. Så snart priser, lagerstatus, orderrader och återkoppling ska röra sig åt båda håll blir lösningen en infrastrukturfråga.

Det är också därför stora bolag ofta märker nyttan senare än de tror. Administrationen är redan digital i många fall, men affärsnyttan uppstår när samma grund används för fler kanaler och fler flöden. Då behöver systemen vara överens om vad som är sant, när det är sant och vem som får ändra det.

Börja med en kanonisk datamodell

Ni vinner tid först när ni bestämmer vad som ska vara gemensam sanning. För artiklar, kunder, priser, lager och order behövs en kanonisk datamodell innan någon börjar bygga. Annars får varje kanal sin egen tolkning av samma affärsobjekt.

Börja med de svenska affärsreglerna. Kundnummer, enheter, moms och prislistor ska mappas mot Business Centrals standardentiteter. Därefter avgör ni vad som hör hemma i affärssystemet, vad som ska berikas i PIM och vad som ska styras i webb eller portal.

Microsofts API-vägledning för Business Central pekar på REST API-stacken som den rekommenderade integrationsvägen. Den är utgångspunkten och kräver att ni dokumenterar varje fält, varje ägare och varje skrivregel.

Här blir det ofta fel i praktiken: moms och enheter tolkas olika mellan system, prislistor bygger på olika regelverk i kanal och affärssystem, lagerfält blandas ihop med reserverat lager eller disponibelt saldo, och orderstatus blir ett lokalt språk som ingen annan del av flödet förstår.

Ni behöver också veta vad som inte ska ligga i standardobjekten. Om något affärsobjekt saknas, ska det få en egen AL-baserad API-yta. Microsofts dokumentation om API-utveckling i Business Central visar att API-sidor och API-frågor inte går att utöka direkt. Saknas fält, krävs en kopierad och anpassad AL-API-lösning.

För den som vill fördjupa arbetssättet kring produktdata finns vår genomgång av product data management system, där samma princip om ägarskap och struktur återkommer i produktflödena.

Så flödar produkter, priser, lager och order

Enligt SCB är digital försäljning redan etablerad i flera svenska branscher. Totalt bedrev 30 procent av företagen webbförsäljning via egen webbplats, app eller e-handelsplattform, och 8 procent sålde via en gemensam marknadsplats. För tillverkningsindustrin var andelen 21 procent via egen digital kanal, med ytterligare 4 procent via gemensamma marknadsplatser. Det gör själva flödet affärskritiskt.

Produktdata och artikelnummer är ofta masterdata. De ska därför ha en tydlig ägare. Priser behöver oftare ett annat upplägg, eftersom kundspecifika prislistor ändras löpande. Här är fältet LastModifiedOn användbart för inkrementell synkronisering i Business Central online enligt Microsofts dokumentation om uttag av data.

En första full laddning och den löpande synken måste hållas isär. Det är en av de vanligaste missarna. Första körningen bygger basen. Därefter ska ändringar flöda med tydliga filter och avgränsade uppdateringar.

Lagerstatus är tidskritisk. Om den släpar tappar köpet trovärdighet direkt. Orderflödet kräver dessutom idempotens, extern nyckel och tydlig status, eftersom samma order kan komma flera gånger när ett nätverk eller ett gränssnitt strular.

Microsoft beskriver webhooks som sättet att få besked när en entitet ändras i Business Central. Webhooks fungerar för de entiteter som stöder det. Den löpande synken ska bygga på förändring och händelser.

När flödet fungerar brukar problemen ändå synas på tre ställen, vilket beskrivs närmare i vår genomgång av ERP-integration. Dubletter uppstår när ordern saknar stabil nyckel. Prisläckor uppstår när priset beräknas i fel system. Lager som släpar uppstår när saldot skickas för sällan eller från fel källa.

Välj middleware-mönster efter ägarskap

Valet av mellanlager handlar om ansvar, spårbarhet och hur mycket arbete som följer med varje ändring.

Filbyten passar när flödet ändras sällan och affärskritiken är låg. Ägarskapet vid fel blir ofta delat mellan två parter, och spårbarheten är vanligtvis låg till medel.

En hanterad integrationsplattform passar när ni har många flöden, många felvägar och krav på löpande övervakning. Då är ansvarsfördelningen tydligare avtalad hos en operatör, och spårbarheten är hög.

Egen middleware passar när ni vill äga mappning, versioner och återanvändning över tid. Ägarskapet ligger då hos er eller er leveranspartner, och spårbarheten kan vara hög om loggning och köhantering är genomtänkt.

Det viktiga är att mappningen lever separat från transporten. Om ni senare byter från fil till API eller från enkel lösning till mer styrd drift ska affärsreglerna leva vidare. Annars blir varje teknikbyte ett omtag på samma problem.

Det är också här en produktiserad leveransmodell kan hjälpa. Vi levererar funktioner och integrationer som fasta byggblock i Funktionsbiblioteket, där omfattning och pris definieras innan utvecklingen startar. Det passar när ni vill ha tydligt ägarskap över funktioner och återanvändning, men inte vill låsa er till en enda driftform.

Testa som om det vore en uppgradering

Ett integrationstest ska bevisa att flödet går att köra om. Därför behöver ni idempotenta skrivningar med extern nyckel, återkörbara testfall och en versionsmatris mellan affärssystemet, webbplattformen och eventuella tillägg.

Börja med att skapa ordern. Ändra den. Makulera den. Leverera den delvis. Kör samma scenario igen. Om resultatet då blir två order eller felaktiga rader finns ett kontraktsproblem.

Det är klokt att sätta egna kvalitetsmål. I det här arbetssättet är 100 procent matchning på artikelnummer, prislista och lagersaldo i testdatasetet ett projektmål, liksom noll dubbla order efter återkörning. Det är era mål, och de gör avvikelser tydliga.

Ni måste också testa svenska lokala fält. Moms, valuta, betalning och bokföring beter sig inte som generiska textfält. När en uppgradering kommer ska kontraktstesterna fånga det tidigt, innan de visar sig som supportärenden.

Den som bara kör en demo före go-live testar vanligtvis funktion. Det räcker för en första visning, men ett långlivat integrationskontrakt kräver att lösningen också klarar förändring över tid.

Driftsättning och förvaltning över tid

När Business Central-integrationen väl är i drift börjar det verkliga arbetet. Microsoft dokumenterar i sina gränsvärden för API:er att en klient kan få HTTP 429 när gränser överskrids och att återförsök med avkylningsperiod krävs. En enskild långkörande begäran får dessutom högst 10 minuter innan tjänsten returnerar HTTP 504. Microsoft anger också gränser för hur många anrop per minut en miljö tar emot. Det är därför förvaltning är en del av arkitekturen.

Ni behöver korrelations-ID, nyttolastens hash, antal försök, svarskod och köläge. Utan det blir felsökning gissning. Permanenta fel ska vidare till en dead-letter-kö, alltså en separat fellista eller felkö där meddelanden som inte kan behandlas automatiskt fångas upp för manuell och spårbar hantering.

Regionala uppdateringspaket och versionsskillnader kräver egen releaseplan. Det är därför ett avtal om löpande ansvar, som Glanser Care, kan vara rätt modell när ni vill ha versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning som en löpande funktion. Den billigaste Business Central-integrationen vid go-live blir ofta den dyraste efter första större uppgraderingen, eftersom kostnaden då flyttar från byggandet till regression, datamappning och incidenthantering.

För den som vill se hur integrationsarbete hänger ihop med bredden i en lösning finns vår artikel om Business Central och Magento-integration, där drift och gränsdragning får samma tyngd som själva kopplingen.

Tre frågor att ställa er leverantör

Fråga vilken version av integrationskontraktet som gäller när Business Central, er webbplattform eller ett tillägg uppgraderas. Svaret visar om leverantören tar ansvar över tid eller bara för själva leveransen.

Fråga vilka delar som bygger på standard och vilka som kräver kundunik AL-extension. Svaret visar hur stor del av lösningen som är versionssäker och hur mycket som riskerar regression när affärsregler ändras.

Fråga hur permanenta fel hanteras och vem som äger dead-letter-kön. Svaret visar om det finns ett verkligt driftåtagande eller bara en överlämning med ett fint namn.

På sidan om ERP och integrationer ser ni hur vi arbetar med integrationsupplägg, ansvarsfördelning och förvaltning som håller över tid.