Arkitektur

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.

Samlet systemlandskab#

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

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, 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).

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). Integrationer mod API’et autentificeres med API-nøgler, der kan begrænses pr. nøgle (se 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 for den fulde oversigt, og On-premise agenter for de agenter, kommunen selv installerer.