CRK består af et antal schedulerede jobs - hvert job indlæser definitionen af et endpoint med tilhørende actions fra en ekstern kilde, hentet via HTTP eller direkte i filsystemet (i princippet kan et job også indlæse fra classpath men dette benyttes kun til unittests).
Nedenstående oversigtsdiagram viser CRK og dens afhængigheder, og deres relation til hinanden.
CRK'en udstiller ingen eksterne snitflader.
CRK som sådan har kun en enkelt ekstern afhængighed, nemlig en database. Denne benyttes til at gemme konfigurationsdata og stille disse til rådighed for DCC'en.
CRK'en er så konfigureret med et antal jobs, som hver indlæser en endpoint definition fra en ekstern kilde -- enten via HTTP eller filsystemet.
Der er følgende krav til den eksterne kilde (http):
Den konfigurerede url skal være tilgængelig fra NSP og tilbyde HEAD og GET requests.
http headeren Last-Modified skal være samme som eller senere end det tidsstempel som er defineret i indholdet.
Der er følgende krav til den eksterne kilde (filsystem):
Filens tidsstempel skal være samme som eller senere end det tidsstempel som er defineret i indholdet.
Såfremt kravene er overholdet, vil indholdet blive hentet. Kilden genindlæses hvis tidsstemplet i filen er senere end seneste indlæsning.
CRK består af nogle få komponenter (eller services), som konfigureres via Spring. For nærmere detaljer omkring konfigurationen henvises til installationsvejlednignen.
Komponenterne indkapsler følgende funktionalitet:
EndpointService: Forretningslogik til indlæsning af endpoint, herunder versionering.
CRK anvender databasen til dels at læse eksisterende endpoint definitioner, dels til oprettelse af nye definitioner og deaktivering af ældre versioner.
Databasen består af 2 tabeller, som tilsammen udgør en versioneret retræsentation af de eksterne endpointdefinitioner.
Indeholder følgende vigtige felter
externaltime: Tidsstempel defineret i den eksterne kilde. Benyttes ved genindlæsning til at kontrollere om der er sket ændringer.
version: Ved genindlæsning oprettes altid en ny version (række i tabellen), og de foregående deaktiveres.
Indeholder følgende vigtige felter
name: uri på den angivne action - Hentet fra ekstern definition og benyttes af DCC
timeout: angiver den maksimalt tilladelige svartid for den eksterne service der kaldes gennem DCC.
useProxy: Angiver hvorvidt DCC'en må sende forespørgslen gennem en proxy (SOSI-GW). Indlæst fra ekstern kilde.
proxyOverride: (valgfri) Vedligeholdes af driften og giver mulighed for at overskrive useProxy.
idcardmaxage: (valgfri) Medsendes til gateway, såfremt en sådan benyttes, og anvendes til check for udløbne id-kort.
inheritedEndpoint: Såfremt en action "forsvinder" fra den eksterne kilde, bevares den som udgangspunkt i konfigurationen, med angivelse af hvor den er kopieret fra.
active. Angiver hvorvidt pågældende action er aktiv eller ej. Kan f.eks. benyttes af driften til helt at fjerne actions, der forsvinder fra den eksterne kilde.
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-4539cbe4-505f-4d31-95a5-95a7633d79bf.html" name="test" height="420" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Procedure for (gen)indlæsning af endpoint definition
lastModified for jobbets eksterne kilde kontrolleres op mod lastModified for evt tidligere indlæsning (via HTTP If-Modified-since eller tidsstempel i filsystemet). Såfremt der allerede findes en endpoint version med pågældende configId med et nyere samme eller nyere lastModified, så afsluttes, ellers fortsættes.
Stop hvis nyeste aktive version af pågældende endpoint har externalTime nyere end tidsstempel defineret i XML'en.
Alle AKTIVE actions som fandtes i den gamle version men er bortfaldet i den nye, kopieres til den nye.
Hvis en action findes i både ny og gammel version, kopieres evt. gammel `proxyOverride` til den nye definition.
CRK applikationen er en J2EE web applikation, som deployes til driftsmiljøerne som et WAR-arkiv. Applikationen deployeres sammen med konfigurationsartefakter, som bestemmer runtime egenskaber, herunder logning, databaseadgang og opsætning af jobs.
For nærmere detaljer omkring konfigurations- og deploymentmuligheder henvises til installationsvejledningen.