Page History

...

Ovenstående sekvensdiagram ignorerer to yderligere kompleksiteter, nemlig cachen af journaldata og sammenstilling af journaldata med CMS indhold. Sammenstilling af data foregår ved at data hentes fra CMS (fx i dette tilfælde ordforklaringer) og fra gm-facaden, og i mapperen plukkes data så fra hhv. CMS'ens eller gm-facadens returnerede data.

Cache

Caching foregår ved at UnstructuredJournal objektet serialiseres til JSON og gemmes i databasen. Ved senere operationer for samme borger checkes i databasen om der er en cachet værdi der kan bruges, og i så fald undgås kaldet til gm-facaden.

Svar fra gm-facaden caches i lokal database for gm-bff.  

Nøglen Nøglen til opslag i cachen er borgerens CPR (taget fra bearer token) kombineret med BFF'ens release nummer. CPR er fordi det er borgerens journal... BFF'ens release nummer er for at gamle cachede data ikke genbruges med potentielle kodeændringer, der gør man ikke kan læse det cachede korrektDette sikre at en ny version af gm-bff vil invalidere cachen og data hentes igen fra gm-facade.

Cachen er tidsbegrænset, dvs. en cachet værdi genbruges kun hvis den er hentet for nyligt. Hvor lang tid cachen skal gælde er konfigurerbart, men er i udgangspunktet konfigureret til en halv time. Dog er det lavet sådan at hver gang man bruger data nulstilles uret. Så hvis man læser journalen op og lægger den i cachen, og så læser den igen 20 minutter senere, vil den så igen gælde 30 minutter derfra, altså 50 minutter i alt, hvis den ikke tilgås igen inden.

...

For de lukkede endpoints er adgangskontrollen baseret på bearer token sikkerhed i form af json web tokens med standarden JTP-H. Tokens valideres for gyldighed, for issuer og for om de har det forventede scope. Det givne token sendes i øvrigt videre med til kald på gm-facaden.

...