...

Kopiregisterservicen tager følgende input:

Kaldet til Kopiregisterservicen er formelt specificeret i WSDL’en stamdata_krs.wsdl, der kan rekvireres ved henvendelse til NSP-operatøren. En komplet gennemgang af tilgængelige registre, datatyper samt versioner er at finde i dokumentet ”Registerspecifikation for Anvendere”.

...

Hvis alt går som forventet og forespørgslen bliver godkendt, modtages et svar:

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
         …
  </S:Header>
  <S:Body>
    <ns1:ReplicationResponse xmlns:ns1="http://nsi.dk/2011/10/21/StamdataKrs/">
      <atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns="http://nsi.dk/-/stamdata/3.0/cpr">
        <atom:id>tag:nsi.dkersonLookupWithSubscriptionIntegrationTest.java,2011:cpr/person/v1</atom:id>
        <atom:updated>2011-10-25T07:02:08.045Z</atom:updated>
        <atom:title>Stamdata Registry Feed</atom:title>
        <atom:author>
          <atom:name>National Sundheds IT</atom:name>
        </atom:author>
         …
      </atom:feed>
    </ns1:ReplicationResponse>
  </S:Body>
</S:Envelope>

...

Opstår der derimod en fejl, bliver en DGWS 1.0.1 Fault sendt tilbage, f.eks.:

<soapenv:Envelope ...>
  <soapenv:Header>...</soapenv:Header>
  <soapenv:Body>
  <soapenv:Fault>
     <faultcode>Server</faultcode>
     <detail>
       <medcom:FaultCode>expired_idcard</medcom:FaultCode>
     </detail>
     <faultstring>The ID card has expired.</faultstring>
   </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

3.5  

...

 Detaljeret svar fra KRS

Her følger et mere detaljeret output fra KRS. Tolkning af dette er beskrevet i afsnittet efter.

  <atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns="http://nsi.dk/-/stamdata/3.0/cpr">
    <atom:id>tag:nsi.dk,2011:cpr/person/v1</atom:id>
    <atom:updated>2011-11-07T09:56:12.278Z</atom:updated>
    <atom:title>Stamdata Registry Feed</atom:title>
    <atom:author>
      <atom:name>National Sundheds IT</atom:name>
    </atom:author>
    <atom:entry>
      <atom:id>tag:nsi.dk,2011:cpr/person/v1/13206597710000000085</atom:id>
      <atom:title/>
      <atom:updated>2011-11-07T09:56:11.000Z</atom:updated>
      <atom:content type="application/xml">
        <person>
          <cpr>0102451234</cpr>
          <koen>M</koen>
          <fornavn>Hans</fornavn>
          <mellemnavn/>
          <efternavn>Hansen</efternavn>
          <coNavn></coNavn>
          <lokalitet/>
          <vejnavn>Ligusterv&#xE6;nget</vejnavn>
          <bygningsnummer>42</bygningsnummer>
          <husnummer>123</husnummer>
          <etage>12</etage>
          <sideDoerNummer>th.</sideDoerNummer>
          <bynavn>Enby</bynavn>
          <postnummer>1448</postnummer>
          <postdistrikt>N&#xF8;ddebo</postdistrikt>
          <status>01</status>
          <gaeldendeCPR>3105459876</gaeldendeCPR>
          <foedselsdato>1947-12-24T00:00:00+01:00</foedselsdato>
          <stilling/>
          <vejKode>740</vejKode>
          <kommuneKode>314</kommuneKode>
          <validFrom>2011-11-07T10:56:21+01:00</validFrom>
          <validTo>2012-11-07T10:56:11+01:00</validTo>
        </person>
      </atom:content>
    </atom:entry>
  </atom:feed>

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. Hvert entry element har et ’content’-element som indeholder alt domæne-data. I eksemplet ovenfor er det datatypen ’person’ som er indeholdt.

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øgle. Unikke nøgler for de enkelte datatyper er beskrevet i listen over registre i dokumentet "Registerspecifikation for Anvendere”.

3.6.2      Revisionsnummer

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:sor/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.

1.2.3      DateTime

DateTime’s i data vil som udgangspunkt være repræsenteret som lokal tidszone, altså fx ”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 angivelse.

1.3     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.

Det er muligt at angive hvor mange records man højest ønsker i et svar fra servicen ved at sætte parameteren maxRecords i ReplicationRequest forespørgelsen. Der er på serveren en øvre grænse på denne parameter der overskriver for høje værdier i en forespørgelse. Hvis parameteren ikke specificeres i kaldet indsættes denne grænse som antal records.

2      Registre

Da der løbende kommer nye registre er beskrivelserne af de enkelte registre flyttet til:

https://www.nspop.dk/display/web/SKRS+-+Stamdata+Kopi+Register+Service#SKRS-StamdataKopiRegisterService-Registeroversigt

Fejl: