Introduksjon
Denne siden gir noen generelle anbefalinger om hvordan du som leverandør av medlemssystem bør håndtere medlemsdata, og hvordan du bør bygge en robust integrasjon.
Medlemsinformasjon
Profilhåndtering
Dersom leverandørene ønsker det, kan de selv berike medlemsdata fra NIF med kontakt og adresseinformasjon, som lagres lokalt i egen database. NIF besitter og utleverer primært opplysninger som er vasket mot Folkeregisteret. Dette innebærer at medlemmer kan ha en annen bostedsadresse hos NIF, enn der de faktisk oppholder seg. Feks. studenter. NIF krever at selve personobjektet og dets medlemsskap er synkronisert.
Adressesperre i Folkeregisteret
Adressesperre i Folkeregisteret er et tiltak for å beskytte trusselutsatte personer. Det er to offentlige etater som kan beslutte å gi personer adressesperre og legge dette inn i Folkeregisteret. Politiet og fylkesnemda for barnevern og sosiale saker. Adressesperringen skjer i Folkeregisteret. Det er to varianter av adressesperre. Kode 7, “Fortrolig adresse” og Kode 6 “Strengt fortrolig adresse”.
Personer med adressesperre har også rett til å bedrive idrett. NIF har ikke adresseinformasjon til disse personene, og dermed utleveres heller ikke adresseinformasjon til 3.parter. Dersom leverandør av medlemssystem har beriket adresseinformasjon i sine løsninger, er det leverandøren selv som har ansvar for at personer med adressesperre ikke eksponeres.
Betalingsinformasjon
Innrapportering av betalingsobjekter
NIF anbefaler at leverandørene innrapporterer betalingsobjekter APIet umiddelbart etter at transaksjonen har gått igjennom i leverandørens systemer. På denne måten er informasjonen anvendbar i andre systemer i idrettens økosystem. Les mer om innrapportering av betalingsobjekter her.
Implementasjon - Generelle tips
Håndtering av meldinger og oppdateringer i sekvens
Prosessering av informasjon sendt via API’et kan enkelte ganger ta noe tid. Dette skyldes at det er flere operasjoner som skal foregå i sekvens, både ved innmelding og utmelding av medlemmer. For å ikke skape utfordringer for medlemmet kan det være hensiktsmessig å legge en sperre for ytterligere oppdateringer på personen til leverandøren har fått bekreftelse på meldingskøen på at behandlingen har blitt behandlet riktig av NIF.
Eksempel på en typisk feilsituasjon:
Eksternt medlemssystem melder Mikro Midas inn i et idrettslag med add membership. Mikro Midas finnes fra før i Idrettens Sentrale Database, men han ligger registrert med feil organisasjonstilknytning og medlemskapet kunne ikke opprettes maskinelt. Medlemskapet til Mikro Midas i dette idrettslaget er ikke å anse som opprettet før leverandøren har fått en FunctionId i retur på Subscription Queue.
Eksternt medlemssystem melder Mikro Midas ut av et idrettslag med cancel membership. Medlemssystemet forsøker å melde Mikro Midas inn i samme idrettslag igjen. Dersom prosesseringen av den første utmeldingen ikke er klar, vil innmelding feile. Utmelding er ikke fullstendig før leverandøren har fått FunctionId med IsPassive=1 i retur på Subscription Queue.