Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.
Kommentera: Info om begränsning av sökträffar hos SearchPersonsForProfileByOrder

...

Notering om HSA-id: Personuppgiftstjänstens REST-tjänster kontrollerar vid begäran om filnedladdning att det är systemet med samma HSA-id som beställt filen. Om anropande konsument använder ett mellanlager i anslutning till NTjP, såsom en lokal tjänsteplattform, är det då viktigt för konsumenten att korrekt populera headern x-rivta-originalserviceconsumeroriginal-serviceconsumer-hsaid. Denna header skall ange det ursrungliga konsumerande systemets HSA-id, i enlighet med regel "Bevara ursprunglig avsändares identitet i http header" samt RIVTA Regel 23.

...

Personuppgiftstjänstens filhanteringstjänster är REST-tjänster som inte ingår i Inera NTjP. Behörighet för att använda dessa följer därför ett separat beställningsförfarande.

Beställning av behörighet till REST-tjänster görs genom att fylla i följande beställningsformulär, vilket skickas till Ineras kundtjänst på kundservice@inera.se. Ange i mailtexten att det gäller "Beställning Beställningen skickas som en bilaga i ett ärende till Inera. Välj att det gäller ”Personuppgiftstjänsten” och området ”Övrigt”. Ange i ärendetexten att det gäller ”Beställning av REST-tjänst för Personuppgiftstjänsten – se bilagabilaga”."

View file
nameBeställning Inera PU REST-tjänst.docx

...

Användningsfall 2 och delvis 3 följer flödet som beskrivs i ARK_0038 Refererad bilaga, medans detta inte är applicerbart i användningsfallen 1 och delvis 3 vid uppladdning av bilagor. Flöden för samtliga användningsfall specificeras i följande avsnitt.

Söka personuppgifter via fil: GetPersonsByFile/SearchPersonsByFile

...

Funktionerna finns endast som restricted-variant. Returnerar alltså inte adress m.m på sekretessmarkerade personposter.

...

Filen laddas upp via någon av REST-metoderna SearchPersonsByFile eller GetPersonsByFile, som vid lyckad uppladdning returnerar ett Order-Id. Detta Order-Id används som inparameter till tjänsten GetFilesForOrderId som returnerar ett svar om var den resulterande filen kan hämtas.

...

Resultatfilerna är ZIP:ade och innehåller en XML-fil med det urval som efterfrågats. Formatet som specificeras i TKB och XSD för strategicresourcemanagement:persons:person.

...

Exempel

SearchPersonsForProfileByOrder

...

Request

...

Begränsning i antal sökträffar: Av prestandaskäl begränsas sökningar via SearchPersonsForProfileByOrder(Unrestricted) till maximalt 250.000 sökträffar.

Image Added

Exempel

SearchPersonsForProfileByOrder

Request

Response


Kodblock
languagexml
<soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:urn="urn:riv:itintegration:registry:1"
 xmlns:urn1="urn:riv:strategicresourcemanagement:persons:person:SearchPersonsForProfileByOrderResponder:3">
  <soapenv:Header>
    <urn:LogicalAddress>SE165565594230-1000</urn:LogicalAddress>
  </soapenv:Header>
  <soapenv:Body>
    <urn1:SearchPersonsForProfileByOrder>
      <urn1:query>FROM personrecord WHERE name.givenname LIKE 'Daniel%';</urn1:query>
      <urn1:queryLanguage>SimpleQL</urn1:queryLanguage>
      <urn1:profile>P5</urn1:profile>
    </urn1:SearchPersonsForProfileByOrder>
  </soapenv:Body>
</soapenv:Envelope>



Kodblock
languagexml
<S:Envelope
 xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:SearchPersonsForProfileByOrderResponse
     xmlns:ns2="urn:riv:strategicresourcemanagement:persons:person:SearchPersonsForProfileByOrderResponder:3"
     xmlns:ns3="urn:riv:strategicresourcemanagement:persons:person:3"
     xmlns:ns4="urn:riv:itintegration:registry:1">
      <ns2:orderId>0622-TO17-09215997</ns2:orderId>
    </ns2:SearchPersonsForProfileByOrderResponse>
  </S:Body>
</S:Envelope>


...

Request

Response

https://api.pu.ineratest.org:443/purest/order/get/fd6a78ee-da71-4ec6-a099-cbccc21fe468

Statuskod: 200 OK
Content-Type: application/zip
Content-Disposition: attachment; filename="<filnamn>"
Transfer-Encoding: chunked
Content: fil (zippat xmldata enligt strategicresourcemanagement:persons:person)

Struktur för filnamn (både ZIP och XML): <orderId>_<datum>_<löpnummer>.zip (samt .xml)
Exempel: 0622-TO17-09215997_20170622_1.zip

Statuskod: 400 BAD_REQUEST
* Ogiltig context path
* HSA-id för konsument saknas
* Certifikat för OrderId matchar inte certifikat som används vid hämtning av fil
* Filen har redan hämtats

Statuskod: 401 UNAUTHORIZED
* Konsumenten saknar behörighet till tjänsten

Statuskod: 404 NOT FOUND
* Begärd referens (GUID) existerar inte

Statuskod: 500 INTERNAL SERVER ERROR
* Internt oförutsätt fel

Avvikande namespace-hantering i domänversion 4

I personuppgiftstjänstens domänversion 4 kommer svarsfilerna som genereras av SearchPersonsByFile v2 samt SearchPersonsForProfileByOrder(Unrestricted) v4 att göra namespace-deklarationer på ett avvikande sätt, vilket kan göra att inläsning/parsning av dessa filer misslyckas. Detta kan hanteras genom search-and-replace i svarsfilerna enligt arbetsstegen som redovisas nedan, innan inläsning görs.

Avvikelsen kommer inte att korrigeras i domänversion 4 för att inte påverka de kunder som redan byggt fungerande integrationer. Denna avvikelse återfinns inte från och med domänversion 5.

Expandera
titleArbetssteg för korrigering av namespace i svarsfiler tillhörande domänversion 4

Ersätt:

Kodblock
ns2:GetPersonsForProfileResponse

Mot tex: 

Kodblock
ns1:GetPersonsForProfileResponse

Ersätt: 

Kodblock
xmlns:ns2="urn:riv:strategicresourcemanagement:persons:person:GetPersonsForProfileResponder:4"

Mot tex: 

Kodblock
xmlns:ns1="urn:riv:strategicresourcemanagement:persons:person:GetPersonsForProfileResponder:4"

Ersätt:

Kodblock
ns2:requestedPersonRecord

mot:

Kodblock
ns1:requestedPersonRecord

Bilagor för reservidentitet

...