Microsoft Dynamics 365 Business Central
SOAP på standardsidor försvinner:
det här bör ni kontrollera före version 29
Business Central 2026 release wave 2 tar bort möjligheten att publicera Microsofts egna sidor som SOAP-webbtjänster. Vår erfarenhet är att integrationerna på dessa endpoints sällan är de någon bevakar — det är bankfiler, EDI-flöden och punktintegrationer från NAV-tiden som tyst har fungerat i tio år.
Vad som faktiskt förändras
Från version 29.0 — uppdateringen i 2026 release wave 2 — går det inte längre att exponera Microsofts egna UI-sidor som SOAP-webbtjänster. Microsofts motivering är värd att förstå, eftersom den förklarar varför det alltid skulle sluta så här: en UI-sida är inte ett kontrakt. Microsoft ändrar de sidorna när en release kräver det, utan att betrakta ändringen som breaking — från deras sida är den inte det. Från er sida slutar integrationen fungera ändå.
Var noga med omfattningen, för det är inte mycket av rapporteringen. Det är inte SOAP som tas bort ur Business Central. Era egna sidor, publicerade som SOAP-webbtjänster från en extension, fungerar fortfarande i version 29. Det som försvinner är specifikt möjligheten att peka ett SOAP-endpoint mot en sida som Microsoft levererar. SOAP som helhet är separat utfasat och kommer att tas bort längre fram, men Microsoft har inte angett någon version.
Tidslinjen över fyra versioner
Det har varit aviserat sedan 2024. Det är sista steget som bryter något.
Version 24 — aviserat
Microsoft publicerade utfasningen i plattformsnoterna för 2024 release wave 1 och pekade redan då ut version 29.0 som borttagningspunkt. Inget ändrades i praktiken; det var en förvarning.
Version 26 — avstängt som standard
En feature key, 'Disable SOAP web services on Microsoft UI pages', kom påslagen för alla användare och blockerar publicering av Microsoft-sidor som SOAP. Observera riktningen: nyckeln måste stängas AV för att det gamla beteendet ska fungera. Tenants som aldrig rört den har varit blockerade sedan 2025 release wave 1.
Version 29 — borttaget
Möjligheten försvinner, och det gör även feature key:en. Det finns ingen brytare att slå om och inget stöttat sätt att hålla ett befintligt endpoint vid liv. Anrop mot dessa endpoints slutar fungera.
När version 29 når er
Release wave 2 blir allmänt tillgänglig från 1 oktober, men det faktiska datumet då era miljöer uppdateras beror på land och region samt det uppdateringsfönster som är satt i admin center. Kontrollera ert eget datum i stället för att räkna med 1 oktober.
Vad som inte förändras
SOAP-endpoints på era egna extension-sidor fungerar fortfarande. OData och REST-API:erna är opåverkade. Använder era integrationer redan API-sidor eller queries kostar förändringen er ingenting.
Vilka som berörs
Mönstret är genomgående: ju äldre integrationen är, desto större är risken att den står på listan.
- Installationer uppgraderade från NAV eller Navision, där SOAP var den normala integrationsvägen på den tiden
- Bankfils- och betalningsintegrationer som läser eller skriver via en standardsida
- EDI-uppsättningar med order, följesedlar och fakturor till och från handelspartner
- Lager-, scanner- och produktionssystem som pratar med standardsidor för artiklar och dokument
- Excel- och Power Query-rapporter som pekar mot SOAP-endpoints i stället för API-sidor
- Middleware och iPaaS-flöden — Logic Apps, BizTalk, tredjepartsmäklare — byggda innan API-sidorna fanns
- Varje integration byggd av en partner som inte längre är involverad, vilket är där den verkliga risken finns
“En UI-sida är inte ett API.”
Varför det är svårare än det ser ut
Själva förändringen är enkel. Att ta reda på vad den träffar är det inte.
Ingen har en lista
SOAP-endpoints har publicerats ett i taget under år, ofta av personer som sedan slutat eller av partner som inte längre är engagerade. Webbtjänstsidan visar vad som är publicerat — inte vad som fortfarande anropas, av vem, eller om någon skulle märka om det slutade.
Felen blir tysta och sena
En nattlig bankfil eller ett EDI-flöde för följesedlar säger inte ifrån när det stannar. Det upptäcks dagar senare av en leverantör som efterlyser en order eller en betalning som aldrig kom — oftast av någon utanför IT.
Feature key:en döljer ert verkliga läge
Om någon stängde av nyckeln i version 26 för att få en integration att fortsätta fungera, så fungerar det endpointet i dag och slutar i version 29. De tenants som är mest exponerade är precis de där förändringen såg ut att vara hanterad.
Ersättningen är inte alltid ett rakt byte
En standard-API-sida exponerar sällan exakt de fält som ett sidbaserat SOAP-endpoint returnerade. Vissa migreringar är en URL-ändring; andra kräver att en API-sida byggs, eller att Microsoft-sidan replikeras i en extension, och att det anropande systemet anpassas.
Fönstret är kortare än kalendern antyder
Att testa mot en preview-sandbox, samordna ändringar med banker, EDI-partner och externa leverantörer och få deras releasecykler att matcha era tar längre tid än själva åtgärden.
Osäkra på vilka av era integrationer som berörs?
Skickar er miljö telemetri till Application Insights har Business Central registrerat svaret sedan version 26. Det tar en eftermiddag att läsa.
Så kartlägger ni er exponering
Det mesta kan ni göra själva, och första steget är det som betyder mest. Vi tittar gärna med om ett extra par ögon hjälper.
- 1
Läs telemetrin Microsoft redan samlar in
Från version 26 skickar Business Central en dedikerad händelse, 'Deprecated endpoint called' — event ID RT0053 — varje gång något träffar ett berört endpoint. Skickar er miljö telemetri till Application Insights finns svaret redan där, med endpoint, objekt och miljö. Det är den snabbaste ärliga bilden av er exponering och betydligt bättre än att läsa webbtjänstsidan. En praktisk varning: Microsofts egen exempelfråga stavar fältet 'depricationMessage', vilket ger tomma resultat mot det dokumenterade 'deprecationMessage'.
- 2
Skilj det levande från det övergivna
Publicerat är inte samma sak som använt. Jämför händelserna mot den generella webbtjänsttelemetrin filtrerad på SOAP-kategorin för att se vilka endpoints som faktiskt har trafik, hur ofta och varifrån. Att stänga ett oanvänt endpoint är gratis, och listan är oftast kortare än den publicerade.
- 3
Välj rätt ersättning per endpoint
Microsoft pekar ut tre vägar: gå över till de inbyggda REST-API:erna, vilket är det rekommenderade alternativet och normalt snabbast för standardentiteter; gå över till OData V4; eller kopiera Microsoft-sidan till en per-tenant extension och publicera den som SOAP-endpoint, vilket bevarar det befintliga kontraktet när ni inte kan ändra det anropande systemet. Det tredje alternativet är det pragmatiska för bank- och EDI-integrationer som någon annan äger.
- 4
Testa mot en preview-sandbox innan uppdateringen landar
Microsoft tillhandahåller preview-miljöer inför general availability. Peka varje åtgärdad integration mot en och bekräfta att den fungerar innan er produktionsmiljö uppdateras — inte efter. Om en extern partner måste ändra något i sin ände, inled den dialogen nu, eftersom deras releasecykel är den begränsning ni inte styr över.
Vad ni får ut av att göra det ordentligt
Utöver att inte gå ner den dag uppdateringen landar.
- En dokumenterad förteckning över vad som faktiskt integrerar med Business Central — något de flesta saknar
- Döda endpoints avvecklade i stället för migrerade, vilket minskar både arbete och angreppsyta
- Snabbare integrationer, eftersom API-sidor är byggda för ändamålet medan standardsidor bär UI-overhead vid varje anrop
- Förvarning i god tid till banker, EDI-partner och leverantörer i stället för ett incidentsamtal
- Ett rent utgångsläge inför nästa utfasning, eftersom SOAP som helhet går samma väg
- Trygghet i att oktoberuppdateringen är rutin snarare än något att spänna sig inför
“De endpoints som går sönder är de ingen minns att de publicerade.”
Vanliga frågor
Det vi oftast får frågor om kring den här förändringen.
Vill ni ha ett extra par ögon på ert integrationslandskap?
Vi arbetar med Business Central-installationer i Sverige, Danmark och övriga Norden — många av dem med NAV-historik. Behöver ni hjälp att läsa er telemetri eller planera migreringarna tittar vi gärna med.