Test API-kontrakten før leverandøren bytter versjon
Koble en API-versjonsendring til konkrete økonomiske akseptanseprøver før den nye kontrakten tas i bruk.
En API-oppgradering kan bevare feltnavn og samtidig endre hvilke poster som leveres. Den kan også endre obligatoriske verdier, statuskoder eller betydningen av null. En kontrakttest må kontrollere økonomisk tolkning i tillegg til syntaks.
Syntetisk prøvepakke
Et lokalt testsystem skal overføre åpne fakturaer. Prøvene bruker oppdiktede dokumenter med kjent forventning.
| Test | Grunnlag | Forventning etter oppgradering |
|---|---|---|
| Delbetaling | Faktura 8 000, betaling 3 000 | Restbeløp 5 000 |
| Kreditnota | Faktura 2 000, full kreditering | Ingen åpen fordring |
| Tomt resultat | Ingen poster i vinduet | Gyldig tom leveranse |
| Ugyldig tilgang | Tilgang uten leserett | Ingen data utleveres |
Kjør samme grunnlag mot gammel og ny kontrakt der dette er mulig. Et avvik er ikke automatisk en feil: den nye versjonen kan rette tidligere feil. Da må forventningen oppdateres med en begrunnelse som både fagansvarlig og teknisk ansvarlig kan kontrollere.
Dokumenter hva dere faktisk bruker
OpenAPI-spesifikasjonen beskriver et format for API-definisjoner. En forskjell mellom to definisjoner er nyttig, men viser ikke alene konsekvensen for integrasjonen. Lag en liste over brukte ressurser, felt, filtre og statuskoder. Endringer i ubrukte ressurser kan være mindre relevante enn en liten endring i et sentralt restbeløpsfelt.
Ta med responsrekkefølge og sidegrenser når klienten er avhengig av dem. Prøv også feilsvar: en ny feilkode kan føre til at en klient gjentar en permanent avvisning eller stopper på en midlertidig feil.
Avtal overgangsperioden. Hvis gammel og ny API-versjon kan brukes samtidig, bør dere hindre at begge utfører samme skrivejobb. Parallelle leseprøver kan være nyttige; parallelle bilagsopprettelser krever en særskilt kontroll mot dobbeltregistrering.
Beslutning om overgang
- Bevar testen med dato og konkret kontraktversjon.
- Forklar alle endringer i antall, beløp og status.
- Prøv gjenopptakelse med en jobb startet før versjonsbyttet.
- Bekreft ansvar for tilbakeføring eller manuell reservebehandling.
- Overvåk første avtalte periode etter overgang.
Godkjenn byttet når de brukte funksjonene har bestått prøvene og kjente forskjeller er akseptert. En leverandørs generelle beskjed om kompatibilitet kan ikke erstatte denne lokale vurderingen.
Ta med felt som klienten bruker indirekte, eksempelvis en status som avgjør neste jobb. Et ubrukt visningsfelt kan endres uten økonomisk virkning, mens en liten kodeendring kan styre hvilke dokumenter som blir sendt videre til registrering.
Ved vurdering av ReAI bør integrasjonsbehovet beskrives med prøvepakken, slik at støtten kan avklares for de aktuelle operasjonene. Se testvektorer og endringer i felt.