Page History

...

3.6     Parsing af output

Det mest interessante ved et response er ’entry’-elementerne. Hvert ’entry’-element indeholder et snapshot af en record fra registret. Med snapshot menes, at det var sådan data så ud på et bestemt tidspunkt. Stamdata bruger fuld historik når man laver et udtag. Det vil sige at man f.eks. kan få information om hvordan en person record så ud for 1 år siden – med adresse, navn etc. Der er ingen garanti for hvor langt tilbage i tiden stamdata har information. Historiske ændringer styres af ValidFrom og ValidTo elementer.

Hvert entry element har et ’content’-element som indeholder alt domæne-data. I eksemplet ovenfor er det datatypen ’person’ som er indeholdt.

Responset fra SKRS består af et antal metadata-felter, som indeholder overordnet information om de data der er i responset, samt en række entry-elementer. Et entry-element beskriver hvordan et forretningsobjekt så i en bestemt periode, repræsenteret ved ValidFrom- og ValidTo-felterne. Med forretningsobjekt menes her en instans af en datatype. Et forretningsobjekt er f.eks. instansen af datatypen 'Person' i CPR-registret med cpr-nummer '0102451234'. Et forretningsobjekt beskrives således af et antal entry-elementer, ét for hver version.

Et udtræk indeholder den fulde historik for det register der forespørges påDet er to slags nøgler som identificerer en record: Unikke nøgler (indeks) og versionsnumre.

3.6.1     Unikke

...

nøgler

Hver datatype har et nøgleelement som unikt bestemmer en record. Eksempelvis identificeres en person unikt ved sit CPR-nummer i CPR-registret. Derfor vil man, når man persisterer records fra cpr/person/v1 bruge cpr-elementet som unik nøgleen nøgle, som identificerer et forretningsobjekt. F.eks. identificeres et Person-objekt i CPR-registret ved sit CPR-nummer. Unikke nøgler for de enkelte datatyper er beskrevet i listen over registre i dokumentet dokumentet "Registerspecifikation for Anvendere”.

3.6.2    

...

Revisionsnumre

Hvert entry-element indeholder et revisionsnummer, som unikt identificerer den version af forretningsobjektet, der ligger under content-elementet. Dette kan sammenlignes med en primærnøgle i en database, som identificerer en bestemt række.

Revisionsnummeret ligger under entry'ets id-element. I eksemplet fra afsnit 3.5 er der f.eks. følgende id-element, hvor revisionsnummeret er markeret med rød.

<atom:id>tag

Revisionsnumre bestemmer en record unikt indenfor en given datatype. Man kan se det som en primær nøgle i en database. Et revisionsnummer er også en slags historisk ID. Det vil sige at det bestemmer en record unikt i historien, i modsætning til unikke nøgler.

Revisionsnummeret kan findes ved at kigge på entry-elementernes id-element. F.eks. i

tag:nsi.dk,2011:sorcpr/apotek/v1/168763721800723

er 1687637218007236 revisionsnummeret.

Med andre ord, bestemmer en unik nøgle en bestemt entitet, revisionsnummeret bestemmer et snapshot af den entitet. Begge disse numre er vigtige på flere måder. Den unikke nøgle kan optræde i flere forskellige entry-elementer. Det er på grund af at en entitet ændre sig med tiden, men revisionsnumre vil altid være forskellige.person/v1/13206597710000000085</atom:id>

3.6.3     ValidFrom- og ValidTo-elementer

Historiske ændringer styres af Et forretningsobjekt kan have flere versioner, hvilket er repræsenteret med elementerne ValidFrom og ValidTo. Hvert entry-element har et ValidFrom og ValidTo element. Dettte gælder for alle register og datatyper. ValidFrom og ValidTo representer en tidslinie af ændringer for den samme primær nøgle for en datatype. Der er ikke overlap mellem de tidsintervaller representeret ved ValidFrom og ValidTo for en specifik primær nøgle.Et forretningsobjekt kan ikke have versioner med overlappende gyldighedsperioder, og der kan ikke være "huller" i historikken. Der gives ingen garanti for, hvor langt tilbage historikken rækker.

F.eks. for datatypen Person, hvis forretningsobjekter identificeres af CPR-numre, kan en ændring af efternavn resultete i følgende versioner:For Person datatypen er den primær nøgle CPR nummer og en ændring af f.eks. efternavn vil resulter i disse 2 records.

<person>
          <cpr>0102451234</cpr>
          ...
          <efternavn>Hansen</efternavn>
          ...
          <validFrom>2000-01-01T01:01:01+01:00</validFrom>
          <validTo>2010-10-10T10:10:10+01:00</validTo>
</person>

<person>
          <cpr>0102451234</cpr>
          ...
          <efternavn>Jensen</efternavn>
          ...
          <validFrom>2010-10-10T10:10:10+01:00</validFrom>
          <validTo>2999-01-01T00:00:00+01:00</validTo>
</person>

...

/validTo>
</person>

3.6.4     DateTime

DateTime’s i data Data af typen DateTime i svaret fra SKRS vil som udgangspunkt være repræsenteret som angivet i lokal tidszone, altså fx ”2018f.eks. '2018-07-11T08:16:47+02:00”, bemærk dog at for datoer ældre end 1894 anvendes UTC, da de moderne tidszoner ikke var indført den gang.Klienter bør derfor altid være i stand til at forstå datoer tider uanset tidszone angivelse00'. Der kan dog være tilfælde hvor der anvendes UTC, og anvendere skal derfor kunne håndtere begge datoformater.

3.7     Paginering

Antallet af records i et register kan være meget stort, i visse tilfælde flere millioner records. Derfor bliver man nødt til at opdele et udtræk i flere kald. Response fra det tidligere eksempel, er et eksempel på en page. Når man er klar til at hente næste page sender man et request med nyt offset i ReplicationResponse beskeden. Offset-parameteren i næste request sættes til det sidste versionsnummeret man har modtaget.

...