Page History

...

...

    <ns1:ReplicationRequest xmlns:ns1="http://nsi.dk/2021/03/03/StamdataRfs/">
        <register>cpr</register>
       <datatype>person</datatype>
       <version>1</version>
       <registerVersion>1</registerVersion>
       <idList>
           <id>1112579876</id>
           <id>2211657418</id>
       </idList>
   </ns1:ReplicationRequest>

  </S:Body>

</S:Envelope>

Headeren skal indeholde en DGWS 1.0.1 header.

Bemærk at registerVersion-parameteren er frivillig. Hvis den udelades, svarer det til angive værdien 1.

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

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

Fejl:

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

/id>
       </idList>
   </ns1:ReplicationRequest>

  </S:Body>

</S:Envelope>

Headeren skal indeholde en DGWS 1.0.1 header.

Strukturen af responses og faults er den samme som for KRS, og vil gerfor ikke blive gennemgået igen.

3.5     Detaljeret svar fra KRS

...

3.6     Parsing af output

Responset fra SKRS og SRFS 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å ud 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 forretningsobjekt kan have flere versioner, hvilket er repræsenteret med elementerne ValidFrom og ValidTo. 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.

Bemærk at der kun returneres historiske versioner i SKRS. SRFS returnerer altid den gældende version af et objekt.

F.eks. for datatypen Person, hvis forretningsobjekter identificeres af CPR-numre, kan en ændring af efternavn resultere i følgende versioner:

...

Bemærk at pagineringsmekanismen kan bruges til at lave deltaudtræk, f.eks. hver nat, ved at man holder styr på det seneste revisionsnummer man har modtaget.

Bemærk i øvrigt at der ikke kan anvendes paginering i SRFS.

3.8 Opslagskolonner i SRFS

...