Dokumenthistorik 

Innehåll

Datum

Om Releasen

Inga schema-förändringar görs av Tjänstekontrakt i denna release. Det är dock ändå viktigt att se över hur förändringarna kan påverka dig som ansluten kund. Notera särskilt förändringen hos REST-tjänsten SearchPersonsByFile.

I denna release tillkommer och ändras även stöd för ett flertal lokala reservidentiteter (LRID), samt att förändringar görs i hur data för testpersoner importeras via tabbseparerad fil i det grafiska gränssnittet PU GUI.

Tillkomna och förändrade LRID

Stöd för följande lokala reservidentiteter (LRID) har införts eller förändrats. Fullständig dokumentation av formatet på respektive LRID dokumenteras här: 

https://inera.atlassian.net/wiki/spaces/PU/pages/3413475352

Tillkomna LRID

Förändrade LRID

Förändringar i Tjänsten

Följande förändringar gäller funktionalitet via Tjänstekontrakt, REST-tjänster eller generell funktionalitet i Personuppgiftstjänsten. Alla förändringar gäller samtliga domänversioner, om ingenting annat anges. I de fall tjänstekontrakt finns i både en variant “Unrestricted” och en variant utan det suffixet så gäller förändringarna båda varianterna, om ingenting annat anges.

SearchPersonsForProfile: Ger inte längre felaktigt meddelande om för många sökträffar

Tjänstekontraktet SearchPersonsForProfile supporterar max 500 sökträffar, och om en sökning resulterar i fler än 500 sökträffar så returneras istället ett felmeddelande “Förfrågans maxgräns överskriden”. Tidigare har det funnits ett fel i hur den maxgränsen applicerades så att tjänstekontraktet ibland, främst i testmiljö, har returnerat felmeddelandet även i fall då det faktiska antalet sökträffar var inom maxgränsen. Problemet är nu åtgärdat så att maxgränsen 500 sökträffar appliceras korrekt.

Open

Figur: Exempel på svar där maxgränsen 500 träffar överskridits

SearchPersonsForProfileByOrder: Införd maxgräns för antal sökträffar

Kriteriesökningar via tjänstekontraktet SearchPersonsForProfileByOrder har kunnat formuleras så att träffar fås på ett obegränsat antal personposter, ända upp till totala antalet personposter i Personuppgiftstjänstens databas. Personuppgiftstjänsten är dock inte ämnad för så stora enskilda datauttag och har inte heller prestanda anpassad för sådana sökningar. Därför införs nu en teknisk möjlighet för förvaltningen av Personuppgiftstjänsten att begränsa maxantalet sökträffar som kan lämnas av SearchPersonsForProfileByOrder. Om en ställd sökfråga resulterar i fler sökträffar än detta maxantal så kommer ett felmeddelande “Förfrågans maxgräns överskriden” att returneras istället för personposter. Rekommenderad åtgärd av anropande part blir då att omformulera frågan så att den ger en mer begränsad mängd sökträffar.

Maxantalet kommer initialt att vara satt till 250.000 träffar, då tjänsten i nuläget har prestandaproblem vid stora sökresultat. När prestandan förbättrats kommer vi att öka detta värde.

Open

Figur: Exempel på felmeddelandet som ges då antalet sökträffar är större än maxgränsen

SearchPersonsByFile: requestedPersonRecord returneras även för personer som inte ger någon sökträff

REST-tjänsten SearchPersonsByFile har tidigare fungerat så att om träff saknas på ett sökt id-nummer så returneras inget requestedPersonRecord för detta id-nummer i svaret. Detta beteende har då varit annorlunda än hur tex GetPersonsForProfile fungerar, som alltid returnerar ett requestedPersonRecord oavsett om en träff ficks på ett id-nummer eller ej. Nu är SearchPersonsByFile ändrad så att även den alltid returnerar ett requestedPersonRecord oavsett om träff fås på ett id-nummer eller ej.

Dokumentationssidan om REST-tjänster för filhantering (tidigare döpt Filhantering) har uppdaterats med denna förändring.

UpdatePerson: Attributet linkedIdentity inkluderas i personposten i svaret

Tjänstekontraktet UpdatePerson har i sin funktion att den efter anrop returnerar hur den uppdaterade eller skapade personposten ser ut. Tidigare inkluderades då inte attributet linkedIdentity i den personpost som returnerades av tjänstekontraktet UpdatePerson, vilket gjorde att personposten i detta svar såg annorlunda ut än om den hämtats via tex GetPersonsForProfile. Nu returneras attributet linkedIdentity även av UpdatePerson.

Automatisk omlänkning görs då en existerande personpost uppdateras.

Denna förändring avser de länkningar som Personuppgiftstjänsten upprätthåller i attributet linkedIdentities. Tidigare har en förändrad personpost väntat på att ett schemalagt länkningsjobb skall utföras, vilket sker en gång var 15:e minut. Det fanns därmed fall där en uppdaterad personpost under cirka 15 minuter inte hade uppdaterade länkningar. Detta är nu ändrat så att om en personpost förändras så görs omlänkning av den personposten omedelbart, vilket då även påverkar länkningarna hos andra berörda personposter. Notera att detta inte får påverkan på hanteringen av de förändringar av personposter som sker i samband med schemalagd inläsning av aviseringsfiler från Skatteverkets Navet, vilka även fortsättningsvis länkas om under en längre tid efter det att inläsning gjorts på grund av den stora mängd omlänkningar som då behöver göras.

Personposters versionsnummer uppdateras då en länkning ändras

Denna förändring berör det attribut version som Personuppgiftstjänsten upprätthåller på varje personpost, och som är en tidsstämpel då senaste förändringen skedde på personposten. Tidigare har denna tidsstämpel inte uppdaterats om en personpost enbart fått en förändring i sina länkningar, dvs i attributet linkedIdentities. Detta är nu förändrat så att även ändrade länkningar ger en uppdaterad version-tidsstämpel, vilket underlättar bland annat vid sökningar efter förändringar som skett sedan en viss tidpunkt.

Förändringar i PU GUI användargränssnitt 

Följande förändringar gäller för det grafiska användargränssnittet PU GUI som erbjuds av Inera.

Ändrade tillgängliga attribut vid import av testpersoner via tabseparerad fil

Denna förändring gäller attributen som finns tillgängliga vid import av testpersoner via tabseparerad fil.

Tidigare så har attributet “Kon” (för kön) varit tillgängligt i mallfilen men har inte haft någon påverkan på personposten, som istället får attributet för kön (gender) satt utifrån värdet på id-numret. Attributet för kön har därför tagits bort ur den tabseparerade mallfilen.

Ett attribut “Fodelsetid” (för födelsetid) har även införts i den tabseparerade mallfilen. Tidigare har födelsetid alltid satts automatiskt utifrån värdet på id-numret, men eftersom skillnader mellan dessa kan finnas hos Skatteverket ges nu även möjlighet att skapa sådana testscenarier denna väg.

Införd formatvalidering vid import av testpersoner via tabseparerad fil

När data för testpersoner har importerats via tabseparerad fil i PU GUI så har tidigare ingen validering gjorts av att den data som importeras följer de formatregler som gäller för respektive attribut.

Följande valideringar har nu införts. Notera att valideringarna följer formatreglerna enligt Personuppgiftstjänstens Tjänstekontraktbeskrivning (TKB), medan Skatteverket kan ha mer begränsande regler för motsvarande fält.

Vid import av testperson fås inte längre "Tjänsten otillgänglig" om man använder en uppdaterad källdatafil

Via PU GUI går det att importera data för testpersoner, men tidigare fick användaren ett felmeddelande om en import gjordes via en fil följt av att användaren gjorde en uppdatering i filen och sedan försökte köra importen en gång till. Ett felmeddelande "Tjänsten otillgänglig" dök då upp. Detta beteende är nu åtgärdat, och importen fungerar utan att ge felmeddelande.

Förtydligande informationsbanner om sökkriterier ändras

Under flikarna "Kontaktinformation" och "Koppla personidentiteter" har gränssnittet varit otydligt om användaren gör följande: Först söker användaren fram en personpost, sedan gör användaren en ny sökning som inte ger en träff. Ett meddelande har visats i ett antal sekunder nere i högra hörnet om att ingen träff ficks, men all data ligger kvar för den gamla sökträffen. Nu har en funktion införts som om användaren ändrar sökparameter ger en blå informationsbanner om att “Dina sökparametrar har ändrats. Du måste göra en ny sökning.”