Om OS2sofd on OS2sofd

Drejebog: OPUS-kommune

Mon, 01 Jan 0001 00:00:00 +0000

1 Implementeringsplan for OS2sofd (med integration til OPUS) og OS2rollekatalog#

Her kører vi normalt med en 3-faset implementering, og et implementeringsprojekt tager ca. 100 timer i vores ende. Vi har desværre ikke så mange tal på, hvad I selv skal forvente af ressourcetræk, men tilsvarende (måske lidt mere) er nok ikke helt ved siden af.

2 Indlæsning og kvalitetssikring af data (Fase 1)#

Formålet med fase 1 er:

Sikre at vi indlæser alle relevante data fra kildesystemerne
Sikre at vi får filtreret væk de data som ikke giver mening (løntekniske data, ikke-relevante ansættelser m.m.)
Beslutte hvor data skal vedligeholdes fremover (OS2sofd, AD, OPUS) for de enkelte dataområder

Typisk tager fase 1 ikke særligt lang tid teknisk, men dialogen om KMD OPUS og styringen af enheder kan tage lidt beslutningstid i jeres ende.

Forudsætninger og forberedelse

Mon, 01 Jan 0001 00:00:00 +0000

Denne side samler, hvad I som kommune skal have på plads og selv klargøre, før IdM-flowet aktiveres. Arbejdsdelingen er: OS2sofd beslutter hvilke handlinger der skal ske (danner kontoordrer), og en on-premise agent udfører dem i jeres lokale systemer og melder status tilbage.

Dette er IdM-modulets egne forudsætninger. For en samlet, faseopdelt implementeringsplan for hele OS2sofd (dataindlæsning, organisation, integrationer og derefter IdM) se Implementeringsdrejebøger.

Datagrundlag#

Personer og tilknytninger indlæses korrekt i OS2sofd fra det relevante kildesystem (master), typisk løn-/HR-systemet.
Organisationen er bygget op med de organisatoriske enheder, der skal danne grundlag for kontooprettelse.
Tilknytningernes start- og slutdatoer er retvisende, da hele livscyklussen styres ud fra dem.
Hvis genaktivering (Reaktiver-ordrer) skal bruges, indlæses deaktiverede AD-konti også i OS2sofd. Uden kendskab til de deaktiverede konti kan OS2sofd ikke danne reaktiverings-ordrer for genansatte.

Beslutninger#

Træf disse beslutninger inden opsætning:

OData (læsning)

Mon, 01 Jan 0001 00:00:00 +0000

OData-API’et er et read-only API til at udlæse organisations- og identitetsdata. Det udstilles på:

https://kommune.sofd.io/odata/

API-nøglen sendes i headeren ApiKey. Det fulde skema (entiteter og felter) kan altid hentes som OData-metadata:

GET https://kommune.sofd.io/odata/$metadata

Entiteter#

Følgende entiteter kan tilgås direkte med egne endpoints:

Persons (/odata/Persons) – personer (navn, CPR, kaldenavn, persontype med videre).
OrgUnits (/odata/OrgUnits) – organisatoriske enheder (navn, CVR, EAN, type, overordnet enhed med videre).
Functions (/odata/Functions) – funktioner.

Relaterede data hentes via $expand fra disse, for eksempel:

Drejebog: SD-kommune

Mon, 01 Jan 0001 00:00:00 +0000

Denne drejebog beskriver implementering af OS2sofd med integration til SD.

1 Implementeringsplan for OS2sofd (med integration til SD)#

2 Indlæsning og kvalitetssikring af data (Fase 1)#

Formålet med fase 1 er

REST-API

Mon, 01 Jan 0001 00:00:00 +0000

Ud over OData udstiller OS2sofd et REST-API til udvalgte skrive- og udtræks-operationer. Det er dokumenteret med OpenAPI/Swagger, og den fulde, altid-aktuelle beskrivelse (endpoints, parametre og dataformater) findes i Swagger-grænsefladen:

https://kommune.sofd.io/swagger-ui.html

Alle kald autentificeres med ApiKey-headeren (se API-nøgler og adgang).

API’et er opdelt i følgende grupper:

Klassifikationer#

/api/classifications – opret, læs, opdatér og slet klassifikationer og deres items.

Organisatoriske enheder#

/api/orgUnit/... – vedligehold af visningsnavn og lokale udvidelser (localextensions) på en organisatorisk enhed.

Personer#

/api/persons/... – vedligehold af kaldenavn (chosen name) på en person.

Fremtidig API-udvikling

Mon, 01 Jan 0001 00:00:00 +0000

OS2sofd-fællesskabet har vedtaget en strategi for den fremtidige API-udvikling. Den etablerer en ny, struktureret API-flade til kundevendte integrationer, erstatter gradvist det nuværende API, og samler læseadgangen ét sted ved at udfase OData over tid. Strategien er en ramme: de detaljerede beslutninger træffes løbende.

Hovedlinjer#

Ny /openapi-flade. En ny API-flade etableres ved siden af det nuværende API og bliver fremover stedet for kundevendte API-funktioner. Den afgrænses indledningsvist til grund-stamdatatyperne (Person, Affiliation, User, OrgUnit) og udvides derfra.
Gradvis migrering uden tvang. Nye kundevendte endpoints bygges på den nye flade, og eksisterende endpoints migreres, når de alligevel skal opdateres. Ingen tvinges til at migrere på en bestemt dato.
Samlet læseadgang; OData udfases over tid. Kunder får ét skema at integrere mod for både læsning og skrivning. OData fortsætter uændret, indtil dens brugere kan flyttes over.
Struktureret versionering. URL-path-versionering (/openapi/v1/...) med en konservativ ændringspolitik og lange overgangsperioder, så kunder ikke skal migrere oftere end nødvendigt.
Stabil API-kontrakt. API’et beskrives ved separate kontrakt-objekter, så ændringer i OS2sofd’s interne datamodel ikke automatisk slår igennem til kundernes integrationer.

Rettighedsmodel#

Adgang sker via API-nøgler med tre niveauer af kontrol:

Processer og hændelser

Mon, 01 Jan 0001 00:00:00 +0000

IdM i OS2sofd er bygget op om kontoordrer. En ordre beskriver en handling (opret, deaktiver, slet med videre) for en bestemt person og en bestemt kontotype. OS2sofd danner ordrerne automatisk ud fra personens tilknytninger og reglerne, og en on-premise agent udfører dem og melder status tilbage.

Kontoens livscyklus#

flowchart LR
 C["Opret<br/>(deaktiveret)"] --> RA["Reaktiver<br/>(aktivér)"]
 RA --> AKTIV[Aktiv]
 AKTIV --> DE[Deaktiver]
 DE --> OP[Oprydning]
 OP --> SL[Slet]
 DE -. "ny stilling" .-> RA
 OP -. "ny stilling" .-> RA

Opret: kontoen oprettes et antal dage før ansættelsesstart. Kontoen kan oprettes i deaktiveret tilstand (“Opret som deaktiveret”). Det gælder AD-konti.
Reaktiver (aktivér): kontoen aktiveres kort før ansættelsesstart, fx dagen før (“dage før reaktivering”).
Kontoen er aktiv i ansættelsen.
Ved fratrædelse sker følgende, i denne rækkefølge og hver for sig valgfri: Deaktiver → Oprydning → Slet. Hvert trin tidsstyres af sit eget dage-tal regnet fra fratrædelsen (se Konfiguration).

Så længe kontoen ikke er slettet (uanset om den er deaktiveret eller ryddet op), kan den reaktiveres, hvis personen får en ny stilling.

Personinaktivering

Mon, 01 Jan 0001 00:00:00 +0000

Ud over de enkelte kontoers livscyklus styrer OS2sofd også personens livscyklus. En person der ikke længere er aktiv i organisationen, bliver slettemarkeret og skjult i administrationsgrænsefladen, og efter et konfigurerbart antal måneder slettes personen helt.

Hvornår slettemarkeres en person#

En person slettemarkeres, når begge følgende er opfyldt:

Personen har ingen aktive tilknytninger.
Personen har ingen aktive brugerkonti.

Det er kun aktive konti der tæller med. En deaktiveret (spærret) konto forhindrer altså ikke slettemarkeringen. En fratrådt medarbejder, der kun har deaktiverede eller ryddede konti tilbage, bliver dermed korrekt slettemarkeret frem for at hænge som aktiv.

Konfiguration

Mon, 01 Jan 0001 00:00:00 +0000

Opslagsværk over alle konfigurationsmuligheder for IdM. Indstillingerne falder i to grupper: dem der opsættes af driftleverandøren centralt i OS2sofd Core, og dem der sættes i administrationsgrænsefladen pr. kontotype og pr. organisatorisk enhed.

Modulindstillinger#

Opsættes af driftleverandøren. Aktivering og overordnet opførsel af IdM.

Indstilling	Standard	Beskrivelse
`sofd.modules.accountCreation.enabled`	`false`	Slår hele IdM-modulet til.
`sofd.modules.accountCreation.nightlyJobEnabled`	`true`	Slår den planlagte natlige generering af ordrer til.
`sofd.modules.accountCreation.accountOrderApprove`	`false`	Kræver godkendelse (af leder) før en konto oprettes.
`sofd.modules.accountCreation.customApprovalForm`	`false`	Bruger en tilpasset godkendelsesformular.
`sofd.modules.accountCreation.allManagersApproveEnabled`	`false`	Tillader alle personens ledere at godkende, ikke kun lederen for den udløsende tilknytning.
`sofd.modules.accountCreation.reservationEnabled`	`true`	Slår reservation af brugernavne til. Kræves hvis brugernavne skal være ens på tværs af kontotyper.
`sofd.modules.accountCreation.accountOrderRetentionDays`	`35`	Antal dage en færdigbehandlet ordre bliver i køen.
`sofd.modules.accountCreation.reuseExistingUsernames`	`false`	Tillader genbrug af tidligere brugernavne.
`sofd.modules.accountCreation.forceSetEmployeeId`	`false`	Sætter medarbejder-id selv når det ikke er oplyst.
`sofd.modules.accountCreation.useCprNameForUsernameGenerator`	`false`	Bruger CPR-navnet i stedet for personens viste navn ved brugernavnsgenerering.
`sofd.modules.accountCreation.hourlyWageCode`	`"03"`	Kode der identificerer timelønnede (bruges af reglerne for timelønnede).
`sofd.modules.accountCreation.idmCloseExemptedUserRegex`	(tom)	Regex for brugere der undtages fra nedlæggelse.
`sofd.modules.accountCreation.linkSubstituteADAccountsToExchange`	`false`	Knytter stedfortræder-AD-konti til Exchange.

Generering af kontoordrer#

Opsættes af driftleverandøren. Styrer hvilke data der udløser IdM, og hvornår kørslen afvikles.