Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

...

Utgåva

Revision Datum

Beskrivning

Ändringarna gjorda av

Definitiv revision fastställd av

A

2009-10-06

Revision A fastställd av Arkitekturledningens tekniska expertgrupp.

magnus.larsson@callistaenterprise.se

johan.eltes@callistaenterprise.se

Arkitekturledningens tekniska expertgrupp

PB1

2011-04-27

Utkast för RIVTA 2.1.

Omfattar följande ändringsbegäran från tracker på Osor:

- 15114

marcus.krantz@callistaenterprise.se


PB2

2011-10-18

Korrektur



B

2011-10-19

Fastställd revision


Arkitekturledningens tekniska expertgrupp

PC1

2011-12-14

Uppdaterat dokumentet i och med byte av projektplats från Osor till Google code.

hans.thunberg@callistaenterprise.se



C

2012-01-03

Fastställd revision


Arkitekturledningens tekniska expertgrupp

D

2013-05-27

Uppdateringar…


Arkitekturledningens tekniska expertgrupp

D1

2013-11-08

Utvidgad och förändrad skrivning om adresseringsmodell (avsnitt 8.3)

johan@eltesconsulting.se


D2

2013-11-11

Uppdaterat enligt granskningskommentarer från CeHis

johan@eltesconsulting.se


E

2014-04-03

Beskrivning av källsystemsbaserad adressering samt ändrad hantering av anropsbehörighet.

Se även 1.1 Inledning till utgåva E

lars.erik.rojeras@inera.se


2.0.1

2014-12-08

Flyttade till Inera-mall

lars.erik.rojeras@inera.se


2.0.2

2015-12-17

Tagit bort stycket ”Inledning till utgåva E”.

Mattias Nordvall, Inera


2.0.32018-01-18Tagit bort kapitel 8.7 som handlade om PingForConfiguration funktionen inte längre kravställsBjörn Hedman, IneraInera A&R
2.0.42018-08-27Lagt till kapitel 8.6 HSA-baserat vägval och anropsbehörighet och 8.7 Standardval för vägval och anropsbehörighet.Lars Erik Röjerås, IneraInera A&R



1          Inledning

Detta dokument är en övergripande beskrivning för RIV Tekniska Anvisningar. Det beskriver principerna som styr utveckling av de tekniska anvisningar, vilka strategier som valts för att tillmötesgå principerna, samt övriga krav på innehållet i enskilda anvisningar.

...

I figuren ovan har man valt att låta tjänsteproducenten TjP1 genomföra kontrollen för de logiska adresserna KS1, VE10 och VE11. Det innebär att tjänsteplattformen har öppnat upp för alla tjänstedomänens tjänstekonsumenter att fritt få adressera dessa adresser (det gäller även TjK3 vilket inte framgår av bilden). För TjP2 låter man istället TP ansvara för kontrollen. Där har behörighetsinformation lagts in i TAK för att tillåta att TjK2 och TjK3 kan adressera VE20 och VE21. Anrop från TjK1 och den aggregerande tjänsten kommer inte att släppas fram till tjänsteproducent TjP2.


8.6        HSA-baserat vägval och anropsbehörighet

De logiska adresserna består i de flesta fall av ett HSA-id som representerar en verksamhet eller organisation. Genom att tillföra information till tjänsteplattformen om det hierarkiska sambanden mellan logiska adresser skapas möjligheten att utföra åtkomstkontroll och vägval via en överliggande adress i hierarkin. Underlaget består vanligen av en organisationsfil som exporterats från HSA.

När tjänsteplattformen skall söka fram ett vägval i tjänsteadresseringskatalogen utgår den från den logiska adress som återfinns i det aktuella meddelandet. Om inget sådant vägval finns explicit definierat i tjänsteadresseringskatalogen kommer tjänsteplattformen att söka uppåt i organisationshierarkin som beskrivs av organisationsfilen, från angiven adress. Om någon av de överliggande logiska adresserna återfinns i ett vägval för aktuellt tjänstekontrakt så kommer det vägvalet att användas för meddelandet.

När tjänsteplattformen skall söka fram en anropsbehörighet utgår den från den logiska adress som återfinns i det aktuella meddelandet. Om ingen sådan behörighetspost finns definierad i tjänsteadresseringskatalogen kommer tjänsteplattformen att söka uppåt iorganisationshierarkin som beskrivs av organisationsfilen, från aktuell adress. Om någon av de överliggande logiska adresserna återfinns i en anropsbehörighetspost för aktuellt tjänstekontrakt så kommer meddelandet att passera behörighetskontrollen och kunna skickas till tjänsteproducenten.

8.7        Standardval för vägval och anropsbehörighet

Tjänstekonsumenter och tjänsteproducenter använder logiska adresser på det sätt som är beskrivet ovan. I en tjänsteplattforms tjänsteadresseringskatalog kan dock som alternativ en logisk adress med värde asterisk ("*") anges. Denna adress kan användas för att ange ett standardvärde för vägval (för specifikt tjänstekontrakt) alternativt för att deaktivera kontroll av anropsbehörighet (för specifikt tjänstekontrakt och tjänstekonsument). 

Följande sker när en begäran, för ett specifikt tjänstekontrakt, med logisk adress "X" anländer till tjänsteplattformen.

Vägval:

  1. Om den logiska adressen "X" finns explicit definierad i för ett vägval i TAK kommer detta att användas.
  2. Om det inte finns ett explicit vägval registrerat görs en HSA-baserad sökning efter vägval  (enl 8.6 ovan)
  3. Om varken 1. eller 2. identifierar ett vägval så kommer istället vägvalet definierat av "*" att användas. 

Detta är bl a användbart om det enbart finns en (1) tjänsteproducent kopplat till ett verksamhetsadresserat tjänstekontrakt. Denna mekanism är också mycket användbar när en regional tjänsteplattform ska definiera vägval till den nationella tjänsteplattformen. Endast ett sådant vägval behöver TAK-as per tjänstekontrakt, i stället för ett vägval för varje logisk adress. 

Anropsbehörighet:

Om den logiska adressen "*" återfinns i en anropsbehörighet för ett tjänstekontrakt och en specifik tjänstekonsument så kommer denna tjänstekonsument att ha anropsbehörighet till samtliga logiska adresser för det tjänstekontraktet. Det innebär i praktiken att kontrollen av anropsbehörighet är deaktiverad för kombinationen av aktuellt tjänstekontrakt och tjänstekonsument. En nationell tjänstekonsument som ska nå alla logiska adresser för ett tjänstekontrakt (t.ex. alla hundratals vårdgivare i Sverige) behöver på detta sätt endast en behörighets-takning istället för hundratals. Detta är också mycket användbart för att ge tjänsteplattformar anropsbehörighet till varandra.

8.8        Namnstandards

RIV Tekniska anvisningar ska underlätta utveckling och tolkning av WSDL och tjänstescheman genom att föreslå en namnstandard. Namnstandarden ska bäras av de begrepp som ligger till grund för denna anvisning. Namnstandarden ska uttryckas som regler i de enskilda anvisningarna. I och med att profilerna bygger på varandra, finns de flesta namngivningsregler för WSDL i bas-profilen. Även anvisningen för tjänsteschema definierar namngivningsregler.

...