Integrasjonsarkitektur for anskaffelsesplattform
En anskaffelsesplattform bør eie en stabil intern prosessmodell og koble eksterne tjenester gjennom avgrensede adaptere.
En anskaffelsesplattform kobler sammen kunngjøring, virksomhetsdata, identitet, dokumenter, arkiv, økonomi og analyse. God integrasjonsarkitektur hindrer at en endring hos én ekstern tjeneste stopper hele prosessen.
Stabil kjerne, utskiftbare adaptere
Plattformens interne modell bør bruke egne objekter for konkurranse, kunngjøring, delkontrakt, leverandør, tilbud, evaluering, kontrakt og hendelse. Adaptere oversetter mellom disse objektene og eksterne API-er.
Eksempler:
- Doffin-adapter for innsending og status
- TED-adapter for søk og kunngjøringsdata
- virksomhetsdata-adapter for registeroppslag
- Altinn-adapter for systembruker og støttede ressurser
- arkivadapter for kundens Noark- eller sakssystem
- økonomiadapter for ordre, faktura, forbruk og prosjektdata
Ikke la Doffins eller TEDs feltnavn bli domenemodellen for hele produktet. Bevar råpayloaden, men oversett til en stabil intern modell.
Asynkron behandling
Publisering og arkivering kan ta tid eller feile midlertidig. Bruk kø og eksplisitte statuser fremfor å holde brukerens nettforespørsel åpen.
Hver jobb bør ha idempotensnøkkel, antall forsøk, neste forsøkstid, korrelasjons-ID og endelig feilkø. Automatisk retry skal bare brukes når operasjonen er trygg å gjenta.
Hendelser og avstemming
Når en kunngjøring publiseres, kan systemet sende en intern hendelse som oppdaterer tidslinje, varsling og analyse. Hendelser gjør modulene mindre tett koblet, men de erstatter ikke avstemming.
Kjør planlagte kontroller som spør:
- Finnes alle lokalt «publiserte» kunngjøringer eksternt?
- Har ekstern status endret seg uten at webhook eller polling ble behandlet?
- Er alle arkivpliktige dokumenter kvittert i arkivet?
- Er kontraktsforbruket oppdatert fra økonomisystemet?
Autentisering per integrasjon
Ikke bygg én generell «offentlig API-nøkkel». TED Search API er åpent, TED Publication bruker API-nøkkel, Doffin har egen onboarding, og enkelte Altinn-integrasjoner bruker Maskinporten .
Isoler hemmeligheter per kunde, miljø og adapter. Produkttjenesten bør be en sentral token-/secret-komponent om kortlivet tilgang i stedet for å lese alle nøkler direkte.
Observability som brukerstøtte
Tekniske målinger bør knyttes til forretningsobjekt. Support må kunne søke på kunngjørings-ID eller konkurranse-ID og se status uten å få tilgang til tilbudsinnhold. Varsle på fastlåste statuser og avstemmingsavvik, ikke bare HTTP-feil.
En realistisk byggeorden
- Domene- og tilgangsmodell.
- Dokumentlager, versjon og revisjonsspor.
- Åpent TED-søk og kildevisning.
- Konkurransearbeidsflyt og eForms-validering.
- Doffin-onboarding og innsending.
- Arkiv og full dataeksport.
- Kontrakt, økonomi og Altinn-integrasjoner.
- KI-funksjoner over kontrollerte kilder.
Les hvordan bygge en anskaffelsesplattform og offentlige API-er .
Offisielle kilder
Bruk Doffins API-portal , TEDs utviklerdokumentasjon og Digdirs Maskinporten-guide som autoritative innganger til de respektive integrasjonene.