EMS - Implementeringsguide
Introduksjon
Denne siden skal forklare kort hvordan man bør gå frem rundt implementering av EMS
Generelt om EMS
EMS er et tjenestelag for håndtering av medlemmer, organisasjoner og grupperinger innen idretten. Tjenestene er bygget etter en modell hvor du som systemleverandør kan inngå en avtale med idrettslag om å håndtere deres medlemmer på et systemteknisk nivå på vegne av idrettslaget.
EMS er bygget slik at man som teknisk leverandør kan være i synk med idrettens sentrale database (ISD). Det betyr at EMS leverer tjenester og endepunkter slik at leverandøren kan påse at idrettslagets medlemsregister er likt og synkronisert med medlemsregisteret hos NIF. Dette er essensielt for at idrettslaget skal rapportere riktig antall medlemmer fra sin organisasjon. EMS er primært bygget for kontroll og verifisering, ikke direkte oppslag mot ISD. NIF krever at idrettslagets medlemssystem skal fungere uavhengig av om NIF sine tjenester er tilgjengelig eller ikke. Se mer om dette under eksempelarkitektur og komponentbeskrivelser.
MERK: Med tilgang til å bruke EMS for å synkronisere mot ISD, har man en godkjent NIF- integrasjon. NIF godkjenner ikke medlemssystemer. Du kan lese mer om dette her.
Tilgangskontroll
Tjenestene er bygget etter et privacy by design-prinsipp som er skissert opp slik at leverandører kun har tilgang til de medlemmer som er tilknyttet det idrettslaget leverandøren har en avtale og databehandleravtale med. Hvis personen er medlem i flere idrettslag vil leverandøren ikke motta opplysninger om disse medlemskapene, med mindre leverandøren har en avtale med dette idrettslaget også. Leverandøren vil da ha samme personobjekt, men dette vil være knyttet til flere idrettslag og grener.
Organisasjonstyper
I EMS har vi støtte for følgende organisasjonstyper:
Organisasjon | Organisasjonstype-ID | Overliggende organisasjonstype-id | Forklaring |
|---|---|---|---|
Idrettslag | 5 |
| Idrettslag (juridisk enhet) |
Gruppe | 6 | 5 | Gruppe for særidrett. F.eks SKI |
Gren | 14 | 6 | Greninndeling under gruppe for særidrett. F.eks langrenn, hopp, alpint |
Bedriftsidrettslag | 15 |
| Idrettslag for bedriftsidrett (juridisk enhet) |
Bedriftsidrettsgruppe | 60 | 15 | Gruppeinndeling under bedriftsidrettslag, grenspesifikk. |
Eksempelarkitektur og komponentbeskrivelser
Skissen under gir et bilde på hvordan EMS kan implementeres for å ivareta et synkronisert medlemskap.
Komponentoversikt NIF Services:
Tjenester i skissen | Forklaring |
|---|---|
EMS | Her finnes tjenester for å legge til medlemskap, fjerne medlemskap, innsending av betalingsinformasjon, lese lisenser, lese organisasjonstrukturen til de idrettslagene leverndøren har tilgang til. |
EMS Read | Tjenester for å hente ut medlemmer på idrettslagsnivå, organisasjonsstrukturer med medlemslister, tilgang til betalte lisenser og medlemskap. |
EMS Updates | Dette er en Azure Service Bus Message Queue pr leverandør. Her vil leverandøren motta ulike meldinger som håndterer endringer og oppdateringer for et medlem eller en organisasjon som leverandøren har tilgang til. |
ISD (Idrettens Sentrale Database) | Dette er masterdatabasen hvor all informasjon om medlemmer og organisasjoner finnes. |
Min idrett | Min idrett er tjenesten som alle medlemmer i norsk idrett har tilgang til, forutsatt at de har opprettet Idrettens ID. Min idrett er det eneste stedet for å redigere sine personopplysninger. Her kan informasjon som telefonnummer, epost og andre kontaktopplysninger legges til. Medlemskap knyttet til idrettslag som bruker NIFs medlemssystemer, kan administreres herifra. Endringer av personinformasjon som gjøres i Min idrett, vil sendes til meldingskøen til relevante mottakere (leverandører). |
Komponentoversikt for Buypass Services
Tjenester i skissen | Forklaring |
|---|---|
Idrettens ID | Idrettens egen identifikasjon- og innloggingstjeneste. Denne tjenesten benyttes i de fleste løsninger som et medlem benytter seg av innenfor sin idrett. Det er et krav om at Idrettens ID skal benyttes som en eller flere valgmuligheter for pålogging til medlemssystemer fra eksterne leverandører. Se mer om Idrettens ID her. |
Buypass payments, Isonen etc.. | Buypass tilbyr en rekke tjenester til norsk idrett. Blant annet betalingsløsninger og arrangementsløsningen Isonen. |
Komponentoversikt for Third party services
Tjenester i skissen | Forklaring | Valgfrihet? | Logging og anbefalt hvor lenge |
|---|---|---|---|
CurrentState sync tjeneste | Leverandøren må implementere noe funksjonalitet for å laste ned medlemmer via les-API’et når tilgang til idrettslag er gitt. Dette er måten leverandøren kan verifisere eventuelle medlemsregistre som finnes fra før. | Nei | N/A |
Add/Delete og Payments | Leverandøren må implementere funksjonalitet for å registrere, fjerne og håndtere medlemskap for idrettslag og gren. Det anbefales at leverandøren logger alle requests som sender til NIFs API’er. Dette for å gjøre eventuell feilsøking enklere. | Nei | Ja, 90 dager |
Read Queue functions | Leverandøren må implementere funksjonalitet for å håndtere alle endringer på medlemmer og organisasjonsendringer som mottas på meldingskøen. Det sendes en rekke meldinger og leverandøren må sette deg godt inn i hva de ulike meldingstypene betyr, og hvilke som bør håndteres. En del meldinger behøver kanskje ikke behandles av leverandøren. Det anbefales at leverandøren lagrer meldingene selv, før de behandles. På denne måten sikres det at meldingene er lastet ned riktig. | Nei | Ja, 90 dager |
3P Database | EMS er ikke bygget for at leverandører skal håndtere medlemmer med direkte oppslag igjennom API’er. Det er laget for at leverandører skal og kan synkronisere mot ISD. Med andre ord må leverandører ha sin(e) egen(e) database(r) som det bygges applikasjoner rundt. | Nei | N/A |
Merk at alle tjenestene som er i eksempelarkitekturen på leverandørens side er forslag, ikke en fasit.