Page Comparison

...

Nøkkel info

...

• Feide-ldap (ved hver institusjon),

• Public360 og

• UBW.

Brukerdata fra LDAP (kan utvides til flere kildesystemer), meldingskøer med KafkaMeldingQ. LDAP-data hentes vha. LDAP-service (/wiki/spaces/IPM/pages/2610102276).

...

• Først delen (adc-app) finner alle endringer siden sist kjøring. Dette gjøres ved å hente ut en full liste over alle aktive brukere fra Feide-ldapen til hver institusjon. En hash-verdi av brukerinformasjonen sjekkes mot databasen som inneholder hash-verdi av brukere hentet sist. På den måten vil tjenesten finne ut om brukere med endring. (og de som er nye eller ikke finnes lenger)

  • Her er en JSON-schema som kan brukes til å validere strukturen i meldingen som blir videresendt til UBW og/eller P360:

    Code Block

    { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "sourceType": { "type": "string" }, "orgId": { "type": "string" }, "userId": { "type": "string", "format": "email" }, "operationType": { "type": "string", "enum": ["insert", "update", "delete"] }, "userData": { "type": "object", "properties": { "dn": { "type": "string" }, "attributes": { "type": "object", "properties": { "cn": { "type": "array", "items": { "type": "string" } }, "eduPersonPrincipalName": { "type": "array", "items": { "type": "string", "format": "email" } }, "givenName": { "type": "array", "items": { "type": "string" } }, "l": { "type": "array", "items": { "type": "string" } }, "mail": { "type": "array", "items": { "type": "string", "format": "email" } }, "mobile": { "type": "array", "items": { "type": "string", "pattern": "^\\+\\d{8,15}$" } }, "norEduPersonLIN": { "type": "array", "items": { "type": "string" } }, "postalAddress": { "type": "array", "items": { "type": "string" } }, "sn": { "type": "array", "items": { "type": "string" } }, "title": { "type": "array", "items": { "type": "string" } } }, "required": ["cn", "eduPersonPrincipalName", "givenName", "sn"] } }, "required": ["dn", "attributes"] }, "removedEntitlements": { "type": "array", "items": { "type": "string" } } }, "required": ["sourceType", "orgId", "userId", "operationType", "userData"] }

  • Forklaring:

    • sourceType, orgId, userId, og operationType er påkrevd felt med spesifikke typer.

    • operationType er begrenset til verdiene "insert", "update", eller "delete".

    • userData inneholder dn og attributes, som har egne valideringsregler.

    • attributes inkluderer flerdimensjonale arrays for felt som navn, e-post, mobilnummer osv. Format- og mønstervalidatorer sikrer korrekt struktur.

    • removedEntitlements er en valgfri liste med strenger.

• For hver endring funnet, sendes det en melding til P360 og/eller UBW køene basert på om institusjonen har den tjenesten (info om det har vi i vår config-db) og basert på entitlement på brukeren (hvis institusjonen har valgt å bruke entitlements, eller vil alle opprettes). Før meldingen sendes, utføres det en nytt kall til Feide-ldap for å hente ut brukerdata for brukeren som da legges til meldingen. Se under for komplett melding.
  Merk at om brukeren er slettet, vil man ikke kunne hente ut noe bruker-data om vedkommende. Userdata vil da være null.
  

...

• P360:

  • For hver innkommende melding:

    • slår opp brukeren kontakt-personen (Get Contact Person). Om personen finnes fra før, oppdateres den (Update Contact Person), ellers opprettes. (Synchronize Contact Person) (merk sletting er en form for oppdatering da status oppdateres til false)

    • slår opp user (Get Users). Om den finnes, oppdateres den med eventuell ny status (Synchronize User)

• UBW:

  • For hver innkommende melding:

    • slår opp brukeren (GetUsers).

      • Om operasjonen er update/insert : Sjekk om en default-bruker er definert, hvis så, leses den (GetUsers). Så sjekkes om brukeren eksisterer, hvis ikke opprettes en ny bruker med eller uten default-data lest fra default brukeren (CreateUsers / CreateUsersWithDefaults). Så oppdateres brukeren (ModifyUsers). Oppdatering skjer selv om brukeren er nylig opprettet, fordi ikke alle verdier kan settes med engang. Dette gjelder spesielt ansatt nummer. Det som skjer, er at brukeren knyttes til den “resursen” med den gitte ansatt-nummer.
        UBW har nemlig en egen import som sørger for at alle ansatte ligger inni systemet som en “resource” med ansatt-nummer som id. Som del av oppdatering av brukeren, knytter vi brukeren til den ressursen.

      • Om operasjonen er delete : Om brukeren finnes, settes status til brukeren til “Terminated” (ChangeUserStatus)

• Ved avsluttet operasjon, sendes det en kafkaMeldingQ-melding tilbare til adc-app som oppdaterer status på operasjonen. På den måten vil den kunne følge med hvilke endringer er utført eller ikke.

...