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

PA1

2011-04-27

Upprättat dokumentet baserat på version 2.0. Uppdaterat dokument för begärda ändringar enligt följande trackers på Osor: 15115.

Marcus.krantz@callistaenterprise.se



A

2011-10-19

Revision fastställd


Arkitekturledningens tekniska expertgrupp, Center för eHälsa i samverkan

PC1

2011-12-16

Uppdateringar med anledning av flytt av projektplats från Osor till Google code. Endast länkar under rubriken Referenser uppdaterade

hans.thunberg@callistaenterprise.se


C

2012-01-03

Revision fastställd


Arkitekturledningens tekniska expertgrupp, Center för eHälsa i samverkan

D

2013-06-27

Ny version efter CeHis AR nya processer

CeHis AR T

CeHis AR t

2.1.1

2014-08-20

Förtydligat regel #9 och flyttat XML-exempel till bilaga.

Mattias Nordvall, Inera


2.1.1

2014-09-26

Lagt upp iinera mall och publicerat

Lennart Eriksson


2.1.2

2014-10-03

Rättat detaljer i bilaga 1.

Mattias Nordvall, Inera


2.1.3

2015-12-17

Uppdaterat länkar i referenstabell

Mattias Nordvall, Inera


2.1.4

2016-09-27

Läsande tjänster ska inte returnera logiska fel

Tommy Carlsson, Inera


2.1.52018-05-08Ändrat från "SOAP-Exception" till "SOAP Fault" för att använda korrekta termer

Lagt till att även domänprefix kan ha olika värden, var förut hårt satt till "riv:"

Förtydligat namnsättningsregler och struktur för domän resp interaktionsnivå

Uppdaterat regel #7 från bör till skall

Björn Hedman, Inera

 




1        Inledning

Detta dokument beskriver regelverket RIV Tekniska Anvisningar Tjänsteschema 2.0.

...

Namngivningsregler i detta dokument är formulerade enligt följande uppställning:

  1. Tjänstedomänens prefix: ${domänPrefix}, t ex riv eller riv-application
  2. Tjänstedomänens namn: ${tjänsteDomän}, t ex crm:schedulingex clinicalprocess:activity:request
  3. Tjänsteinteraktionens namn: ${tjänsteInteraktion}, t ex MakeBookingex GetRequest
  4. Tjänsteinteraktionsroll: ${roll} = Initiator eller Responder, motsvarande tjänsteinteraktionsroller initiativtagare och utförare
  5. Tjänsteinteraktionens version:
    m.n = förkortning av ${majorVersion}.${minorVersion}
    m = förkortning av ${majorVersion}
  6. Operationens namn: ${operation}, t ex MakeBooking

...

Attributet targetNamespace på schema-elementet för en tjänsteinteraktion skall ha ett värde som definieras av följande regel: urn:riv${domänPrefix}:${tjänsteDomän}:${tjänsteInteraktion}${roll}:${m}

(Reglerna för namnsättning av domänprefix och tjänstedomän finns mer utförligt beskrivna i dokumentet Domännamnsättning)

Motiv:

Användningen av major-version i namnrymden är en av att följa fastslagen versioneringsstrategi [R9]. Att ha en unik namnrymd per tjänstekontrakt (tjänsteinteraktion + roll) är en förutsättning för att följa WS-I Basic Profiles [R4] regel om ”operation signature”. Det också generellt goda förutsättningar för att implementera generella bryggor och tjänsteväxlar

Exempel:

Nationell domän

urn:riv:crm:scheduling:MakeBookingResponder:1

...

Schema-attributet version bör skall sättas till "m.n"

Motiv: Då namnrymden inte innehåller minor-version, ger detta en dokumentation som följer intentionen med attributet.

...

Ett tjänstekontrakt ska inte definiera några egna fel (SOAP Fault-exceptions). Istället bör följande struktur för felhantering tillämpas i svarsmeddelandet (för fråga-svar):

...

Vid ett tekniskt fel levereras ett generellt undantag (SOAP Fault-Exception). Exempel på felsituationer som rapporteras som tekniskt fel kan vara deadlock i databasen eller följdeffekter av programmeringsfel. Denna information bör loggas av tjänstekonsumenten. Informationen är inte riktad till användaren. Användaren kommer enbart att se ”tekniskt fel – inte detaljinformation. Den riktar sig till systemförvaltaren.

...