OpenPeppol har overtatt Peppol SML: Derfor gir oppslag mot EU-kommisjonens gamle sone umerkelig utdaterte svar

2. september 2026 fullførte OpenPeppol overtakelsen av Service Metadata Locator (SML), den DNS-baserte katalogen som forteller et avsendende aksesspunkt hvor metadataene til en mottaker er publisert. Frem til da var SML driftet av EU-kommisjonen under edelivery.tech.ec.europa.eu. Nå driftes den av OpenPeppol under participant.sml.prod.tech.peppol.org. Teknisk sett er endringen liten - det er snakk om en annen DNS-sone - men den har en bivirkning som er lett å overse: Den gamle sonen svarer fortsatt, men svarene blir stadig mer feilaktige.

Hva ble endret, og når?

• 19. mars 2026 - migreringsvinduet åpnes, og den nye OpenPeppol-sonen begynner å speile EU-kommisjonens sone.
• 31. mai 2026 - frist for SMP-leverandører til å flytte registreringskallene sine (administrasjonskallene) til OpenPeppol-endepunktet.
• 31. august 2026 - frist for aksesspunkter og andre oppslagsklienter til å flytte DNS-oppslagene til den nye sonen.
• 2. september 2026 - OpenPeppols SML blir primærsystemet, og EU-kommisjonens miljø er ikke lenger en del av produksjonskjeden.
• September 2026 - EU-kommisjonens sone skal avvikles etter Kommisjonens eget skjønn.

Hvorfor den gamle sonen er farlig, ikke bare utdatert

En avviklet sone ville feilet tydelig: Alle oppslag ville returnert «ikke funnet», og enhver overvåking ville ha fanget det opp i løpet av få minutter. EU-kommisjonens gamle sone gjør noe verre. Den fortsetter å returnere oppføringer, men SMP-leverandører som har fullført migreringen, skriver ikke lenger til den. For en klient som fortsatt spør mot den gamle sonen, skjer tre ting uten noen feilmelding:

• Deltakere som er registrert gjennom en migrert SMP etter overgangen, finnes ikke - oppslaget returnerer «ikke registrert».
• Deltakere som har byttet fra én leverandør til en annen, ser ut til fortsatt å være hos den gamle leverandøren.
• Deltakere som er avregistrert av en migrert SMP, ser fortsatt ut til å være registrert.

Det oppstår ingen feil. Dataene slutter ganske enkelt å bli oppdatert for en stadig større del av nettverket, én SMP om gangen.

Slik så det ut i våre egne data

Vi skriver om dette fordi det skjedde med oss. Leverandørtilordningen vår og markeringen «kan rutes / kan ikke rutes» på hver deltakerside bygger på SML-oppslag. Mellom 2. og 14. september 2026 gikk disse oppslagene fortsatt til den gamle sonen. Vi oppdaget det da Michael Walther fra The Invoicing Hub sendte oss tre eksempler der siden vår ikke samsvarte med referanseoppslaget på peppol.helger.com - én deltaker ble vist som ikke rutbar selv om den åpenbart var det (registrert gjennom en migrert SMP 13. september), mens to deltakere ble vist med sin tidligere leverandør etter å ha flyttet til henholdsvis Pennylane og ITEMS.

14. september flyttet vi alle oppslag til OpenPeppol-sonen og slo opp hele nettverket på nytt i løpet av natten. Tallene viser hvor raskt de to sonene glir fra hverandre:

• Av rundt 183 000 deltakere som vi hadde merket som «ikke rutbare» og kontrollerte på nytt i løpet av natten, var 3 532 (rundt 1,9 %) faktisk registrert i nettverket - de var usynlige for oss bare fordi SMP-en deres allerede hadde migrert.
• Blant deltakere som ble registrert i uken før rettingen, var bildet langt verre: I et utvalg av nylige «ikke funnet»-resultater var 9 av 10 feil.
• Fra én dag til den neste steg antallet deltakere med en leverandørtilordning med rundt 39 000 - omtrent tre ganger så mye som på en vanlig dag - og 18 800 deltakere som hadde vært oppført med «ukjent» leverandør, fikk tilordnet en leverandør. De største økningene kom hos Pennylane (+8 558), Indy (+6 826), Banqup/Jefacture (+6 719), Saphety (+3 089) og Axway (+2 362). Noe av dette skyldes vanlig daglig vekst, mens resten skyldes at de to sonene kom på linje med hverandre.

SMP-ene der de to sonene avvek mest i våre data, var de som migrerte tidlig - blant andre Pennylane, Jefacture (Banqup), peppolint (ITEMS), eezi, Odoo, Storecove og Myflowin. Registreringer gjennom SMP-er som migrerte sent, eller gjennom de store nasjonale SMP-ene, var fortsatt identiske i begge soner.

Dette har to konsekvenser for dem som bruker statistikken vår: Leverandørtallene og tallene for «ikke rutbare» deltakere endret seg 15. september av tekniske årsaker, ikke på grunn av organisk vekst eller utskifting. Dessuten bør enhver sammenligning av våre data fra 2.-14. september med det aktive nettverket ta høyde for dette.

Hvis du gjør dine egne Peppol-oppslag

Alle som har bygget deltakerverifisering, overvåking eller analyse på SML - integratorer, ERP-leverandører, ID-kontrolltjenester og forskere - bør kontrollere hvilken sone koden deres spør mot. Produksjonssonen er iso6523-actorid-upis.participant.sml.prod.tech.peppol.org, mens testsonen (SMK) er iso6523-actorid-upis.participant.sml.test.tech.peppol.org. Hashingen av deltakeridentifikatoren (Base32 av SHA-256, U-NAPTR-oppføring) er uendret, så byttet krever bare én linje med konfigurasjonsendring. En rask måte å kontrollere et resultat på er deltakeroppslagsverktøyet på peppol.helger.com, som allerede spør mot OpenPeppol-sonen.

Lærdommen vi trekker, gjelder mer enn denne ene migreringen: En oppslagstjeneste som fortsetter å svare etter at den har sluttet å være autoritativ, utgjør et datakvalitetsproblem, ikke et tilgjengelighetsproblem. Det krever en annen type kontroll enn overvåking av oppetid. På vår side spør vi nå SML på nytt umiddelbart hver gang en SMP ikke lenger kjenner igjen en deltaker. Vi oppdaterer også innen en time alle deltakersider som åpnes med data eldre enn tre dager, og viser datoen for «Sist verifisert» på hver deltakerside.

Takk

Vi takker Michael Walther fra The Invoicing Hub, som for andre gang tok seg bryet med å sammenligne deltakersidene våre med det aktive nettverket og sende oss presise, reproduserbare eksempler. Uten dem ville vi først ha oppdaget avviket da Kommisjonen slo av den gamle sonen.