OS2sofd

- Om OS2sofd: https://www.sofd.io/
- Brugervejledning: https://www.sofd.io/brugervejledning/
- Arkitektur: https://www.sofd.io/arkitektur/
- Implementeringsdrejebøger: https://www.sofd.io/implementation-guides/
- Drejebog: OPUS-kommune: https://www.sofd.io/implementation-guides/opus-loen-integration/
- Drejebog: SD-kommune: https://www.sofd.io/implementation-guides/sd-loen-integration/
- Brugerstyring: https://www.sofd.io/idm/
- Forudsætninger og forberedelse: https://www.sofd.io/idm/prerequisites/
- Processer og hændelser: https://www.sofd.io/idm/processes/
- Personinaktivering: https://www.sofd.io/idm/person-inactivation/
- Konfiguration: https://www.sofd.io/idm/configuration/
- Login og SAML: https://www.sofd.io/login/
- API: https://www.sofd.io/api/
- OData (læsning): https://www.sofd.io/api/odata/
- REST-API: https://www.sofd.io/api/rest/
- Fremtidig API-udvikling: https://www.sofd.io/api/strategi/
- Integrationer: https://www.sofd.io/integrationer/
- On-premise agenter: https://www.sofd.io/agents/
- Brugerkonto Agent: https://www.sofd.io/agents/user-account-agent/
- AD Writeback Agent: https://www.sofd.io/agents/ad-writeback-agent/
- AD Replikator Agent: https://www.sofd.io/agents/ad-replikator/
- AD indlæsningsintegration: https://www.sofd.io/agents/ad-indlaesningsintegration/
- OPUS indlæsningsintegration: https://www.sofd.io/agents/opus-indlaesningsintegration/
- Indlæsning af skoleelever: https://www.sofd.io/agents/skoleelev-indlaesning/
- OS2vikar - Brugerkonto Agent: https://www.sofd.io/agents/os2vikar-agent/
- Download: https://www.sofd.io/downloads/
- Ændringslog: https://www.sofd.io/changelog/
- Support og kontakt: https://www.sofd.io/support/


OS2sofd er bygget i tre lag: et centralt modul, der ejer data og forretningsregler,
middleware der håndterer de enkelte integrationer, og on-premise agenter, der står
for kontakten til kommunens lokale systemer.

## De tre lag

### Centralmodul

Det centrale modul ejer alle data, håndhæver forretningsreglerne og opbevarer fuld
ændringshistorik. Det leverer brugergrænsefladen og API'et, udstiller en hændelseskø
til udgående integrationer, og afvikler de skedulerede jobs (fx beslutning om primær
ansættelse og bestilling af nye konti). Driftes hos driftleverandøren.

### Middleware

For hver integration findes et selvstændigt middleware-modul. Det indeholder
forretningslogikken for netop den integration og bruger centralmodulets API (det
har ikke direkte adgang til databasen). Driftes hos driftleverandøren sammen med
centralmodulet. Fordelene er frit teknologivalg pr. modul, uafhængig skalering og
drift, samt afkobling: et modul kan fejlrettes eller genstartes uden at påvirke de
øvrige.

### Agenter

For at respektere netværksgrænserne mellem driftleverandørens middleware og
kommunens interne netværk udfører on-premise agenter selve integrationen til de
lokale systemer. Agenterne holder så lidt forretningslogik som muligt og er den
initierende part i al kommunikation, så der ikke er behov for indgående åbninger i
kommunens netværk. Se [On-premise agenter](../agents/).

## Samlet systemlandskab

{{< mermaid >}}
flowchart LR
    subgraph onprem["On-premise (kommune)"]
        ADK[AD-kildeagent]
        OPK[OPUS-kildeagent]
        ADU[AD/Exchange-opdateringsagent]
    end
    subgraph drift["Driftleverandør"]
        ADM[AD middleware]
        OPM[OPUS middleware]
        C[(OS2sofd centralmodul)]
        UDM[Udgående middleware]
    end
    ADK --> ADM --> C
    OPK --> OPM --> C
    C --> UDM --> ADU
{{< /mermaid >}}

Pilene viser den retning, data primært flyder. I nogle tilfælde sendes en status
tilbage, men forretningsdata flyder i pilens retning.

## Dataflow og hændelser

OS2sofd samler data fra kildesystemerne efter en prioriteret rækkefølge for fælles
felter (se [Om OS2sofd](../)). Data beriges centralt og stilles til rådighed for
andre fagsystemer på to måder: via [API'et](../api/), som kan læses direkte, og via
en **hændelseskø**. Når data ændrer sig centralt, lægges ændringen i køen, som de
udgående middleware-moduler læser og sender videre til modtagersystemerne. Al
ændringshistorik bevares, så det altid kan ses hvornår og fra hvilken kilde et felt
er ændret.

Centralmodulet afvikler desuden skedulerede processer: blandt andet beslutning om
primær ansættelse og automatisk brugerstyring, der danner kontoordrer, som
on-premise agenterne henter og udfører (se [Brugerstyring](../idm/)).

## Sikkerhed og login

Brugere logger ind via **SAML** mod kommunens Identity Provider (typisk AD FS,
OS2faktor eller en tilsvarende), og adgang styres af roller (se
[Login og SAML](../login/)). Integrationer mod API'et autentificeres med
API-nøgler, der kan begrænses pr. nøgle (se [API](../api/)).

On-premise agenterne er altid den **initierende** part i kommunikationen og henter
og afleverer data udefra og ind. Derfor kræves der ingen indgående åbninger i
kommunens netværk, hvilket holder angrebsfladen lille.

## Integrationer

OS2sofd integrerer med en lang række kilde-, modtager- og kommunikationssystemer via
middleware-moduler og on-premise agenter. Se [Integrationer](../integrationer/) for
den fulde oversigt, og [On-premise agenter](../agents/) for de agenter, kommunen selv
installerer.