Microsoft Dynamics 365 Business Central
SOAP på standardsider forsvinder:
det bør I tjekke før version 29
Business Central 2026 release wave 2 fjerner muligheden for at publicere Microsofts egne sider som SOAP-webservices. Vores erfaring er, at integrationerne på de endpoints sjældent er dem, nogen holder øje med — det er bankfiler, EDI-flow og NAV-tidens punktintegrationer, der stille har kørt i ti år.
Hvad ændrer sig konkret
Fra version 29.0 — opdateringen i 2026 release wave 2 — kan Microsofts egne UI-sider ikke længere eksponeres som SOAP-webservices. Microsofts begrundelse er værd at forstå, for den forklarer, hvorfor det altid ville ende sådan: en UI-side er ikke en kontrakt. Microsoft ændrer de sider, når en release kræver det, uden at betragte ændringen som breaking — for set fra deres side er den ikke det. Set fra jeres side går integrationen i stykker alligevel.
Vær præcis omkring omfanget, for det er meget af omtalen ikke. Det er ikke SOAP, der fjernes fra Business Central. Jeres egne sider, publiceret som SOAP-webservices fra en extension, fungerer fortsat i version 29. Det, der forsvinder, er specifikt muligheden for at pege et SOAP-endpoint på en side, Microsoft leverer. SOAP som helhed er separat udfaset og bliver fjernet på et tidspunkt, men Microsoft har ikke sat version på.
Tidslinjen over fire versioner
Det har været varslet siden 2024. Det er sidste skridt, der bryder noget.
Version 24 — varslet
Microsoft offentliggjorde udfasningen i platformsnoterne til 2024 release wave 1 og pegede allerede dér på version 29.0 som fjernelsestidspunkt. Intet ændrede sig i praksis; det var et varsel.
Version 26 — slået fra som standard
En feature key, 'Disable SOAP web services on Microsoft UI pages', kom slået til for alle brugere og blokerer publicering af Microsoft-sider som SOAP. Bemærk retningen: nøglen skal slås FRA, for at den gamle adfærd virker. Tenants, der aldrig har rørt den, har været blokeret siden 2025 release wave 1.
Version 29 — fjernet
Muligheden forsvinder, og det gør feature key'en også. Der er ingen kontakt at skifte og ingen understøttet måde at holde et eksisterende endpoint i live. Kald til de endpoints holder op med at virke.
Hvornår version 29 rammer jer
Release wave 2 bliver generelt tilgængelig fra 1. oktober, men den faktiske dato, jeres miljøer opdateres, afhænger af land og region samt det opdateringsvindue, der er sat i admin centeret. Tjek jeres egen dato frem for at regne med 1. oktober.
Hvad der ikke ændrer sig
SOAP-endpoints på jeres egne extension-sider virker fortsat. OData og REST-API'erne er uberørte. Bruger jeres integrationer allerede API-sider eller -queries, koster ændringen jer ingenting.
Hvem det berører
Mønsteret er gennemgående: jo ældre integrationen er, jo større er chancen for, at den står på listen.
- Installationer opgraderet fra NAV eller Navision, hvor SOAP var den normale integrationsvej dengang
- Bankfil- og betalingsintegrationer, der læser eller skriver via en standardside
- EDI-opsætninger med ordrer, følgesedler og fakturaer til og fra handelspartnere
- Lager-, scanner- og produktionssystemer, der taler med standard vare- og dokumentsider
- Excel- og Power Query-rapporter, der peger på SOAP-endpoints frem for API-sider
- Middleware og iPaaS-flow — Logic Apps, BizTalk, tredjepartsbrokere — bygget før API-siderne fandtes
- Enhver integration bygget af en partner, der ikke længere er involveret, hvilket er dér, den reelle risiko ligger
“En UI-side er ikke et API.”
Hvorfor det er sværere, end det ser ud
Selve ændringen er enkel. At finde ud af, hvad den rammer, er det ikke.
Ingen har en liste
SOAP-endpoints er publiceret ét ad gangen gennem år, ofte af folk der siden er stoppet, eller af partnere der ikke længere er tilknyttet. Websevices-siden viser, hvad der er publiceret — ikke hvad der stadig bliver kaldt, af hvem, eller om nogen ville opdage det, hvis det holdt op.
Fejlene bliver tavse og sene
En natlig bankfil eller et EDI-følgeseddelflow siger ikke til, når det stopper. Det opdages dage senere af en leverandør, der rykker for en ordre eller en betaling, der aldrig kom — som regel af nogen uden for IT.
Feature key'en skjuler jeres reelle situation
Hvis nogen slog nøglen fra i version 26 for at få en integration til at køre videre, så virker det endpoint i dag og stopper i version 29. De tenants, der er mest eksponerede, er præcis dem, hvor ændringen så ud til at være håndteret.
Erstatningen er ikke altid en ren udskiftning
En standard API-side eksponerer sjældent præcis de felter, et sidebaseret SOAP-endpoint returnerede. Nogle migreringer er en URL-ændring; andre kræver, at der bygges en API-side, eller at Microsoft-siden replikeres i en extension, og at det kaldende system tilpasses.
Vinduet er kortere, end kalenderen antyder
At teste mod et preview-sandbox, koordinere ændringer med banker, EDI-partnere og eksterne leverandører og få deres releasecyklusser til at passe med jeres tager længere tid end selve udbedringen.
Er I i tvivl om, hvilke integrationer der er berørt?
Sender jeres miljø telemetri til Application Insights, har Business Central registreret svaret siden version 26. Det tager en eftermiddag at læse.
Sådan kortlægger I jeres eksponering
Det meste kan I selv gøre, og første skridt er det vigtigste. Vi kigger gerne med, hvis et ekstra sæt øjne hjælper.
- 1
Læs den telemetri, Microsoft allerede opsamler
Fra version 26 udsender Business Central en dedikeret 'Deprecated endpoint called'-hændelse — event ID RT0053 — hver gang noget rammer et berørt endpoint. Sender jeres miljø telemetri til Application Insights, ligger svaret der allerede, med endpoint, objekt og miljø. Det er det hurtigste ærlige billede af jeres eksponering og langt bedre end at læse Webservices-siden. En praktisk advarsel: Microsofts eget eksempelquery staver feltet 'depricationMessage', hvilket giver tomme resultater mod det dokumenterede 'deprecationMessage'.
- 2
Skil det levende fra det forladte
Publiceret er ikke det samme som brugt. Sammenhold hændelserne med den generelle webservice-telemetri filtreret på SOAP-kategorien for at se, hvilke endpoints der reelt har trafik, hvor ofte og hvorfra. At lukke et ubrugt endpoint er gratis, og listen er som regel kortere end den publicerede.
- 3
Vælg den rigtige erstatning pr. endpoint
Microsoft peger på tre veje: skift til de indbyggede REST-API'er, hvilket er den anbefalede løsning og typisk hurtigst for standardenheder; skift til OData V4; eller kopiér Microsoft-siden ind i en per-tenant extension og publicér den som SOAP-endpoint, hvilket bevarer den eksisterende kontrakt, når I ikke kan ændre det kaldende system. Den tredje mulighed er den pragmatiske for bank- og EDI-integrationer, som andre ejer.
- 4
Test mod et preview-sandbox før opdateringen lander
Microsoft stiller preview-miljøer til rådighed inden general availability. Peg hver udbedret integration mod ét og bekræft, at den virker, før jeres produktionsmiljø opdateres — ikke efter. Skal en ekstern partner ændre noget i deres ende, så start den dialog nu, for deres releasecyklus er den begrænsning, I ikke selv styrer.
Hvad I får ud af at gøre det ordentligt
Ud over ikke at gå ned den dag, opdateringen lander.
- En dokumenteret oversigt over, hvad der reelt integrerer med Business Central — noget de færreste har
- Døde endpoints lukket i stedet for migreret, hvilket reducerer både arbejde og angrebsflade
- Hurtigere integrationer, fordi API-sider er bygget til formålet, mens standardsider bærer UI-overhead ved hvert kald
- Varsel i god tid til banker, EDI-partnere og leverandører frem for en hændelsessamtale
- Et rent udgangspunkt til næste udfasning, for SOAP som helhed går samme vej
- Sikkerhed for at oktoberopdateringen er rutine frem for noget, I skal spænde op til
“De endpoints, der går i stykker, er dem, ingen husker at have publiceret.”
Typiske spørgsmål
Det, vi oftest bliver spurgt om på den her ændring.
Vil I have et ekstra sæt øjne på jeres integrationslandskab?
Vi arbejder med Business Central-installationer i Danmark, Sverige og resten af Norden — mange af dem med NAV-historik. Skal vi hjælpe med at læse jeres telemetri eller planlægge migreringerne, kigger vi gerne med.