Jämförda versioner

Nyckel

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

...

En virtuell tjänst erbjuder en anslutningspunkt per tjänstekontrakt som standardiserats genom RIVmetoden.
I praktiken finns det ofta många tjänsteproducenter (regionala, landstings-specifika eller gemensamma för ett antal vårdgivare)
för ett standardiserat tjänstekontrakt. Virtuella tjänster döljer detta förhållande för tjänstekonsumenter.

...

Nya tjänster/tjänstekontrakt kan läggas till utan förändringar i VP:s kod under förutsättning att den som skapar tjänsten följer den av Inera publicerade standarden för wsdl:er.
Det enda som krävs då är att kontraktet är TAK:at. Men för att VP skall kunna publicera Wsdl:en för ett specifikt kontrakt behöver dessa ligga i en katalog under vp.
Detta förenklar för parter som vill ansluta till tjänsten. Per default ska kontrakten ligga i mappen wsdl under config i installationen.
Det går att använda en annan mapp genom att konfigurera värdet wsdlfiles.directory i application-custom.properties.

...

Befintliga kontrakt bör fungera som vanligt, men som nämnts behöver WSDL:erna för respektive kontrakt finnas tillgängliga.
Skulle det visa sig att det inte går att komma WSDL:n för något ett befintligt kontrakt trots att det ligger i avsedd katalog beror detta på att
namnrymden för WSDL:n inte följer mönstret som VP förväntar sig och/eller att anrops adressen dom VP härleder från denna inte blir den förväntade.
Det finns då en möjlighet att konfigurera en Json-fil (wsdl.json.file i application-custom.properties för kontrakt med avvikande struktur. Den är till för att äldre tjänstekontrakt ska fungera.

...

Ett annat fel som kan uppså är att VP returnerar WSDL:n men att det inte går att hämta en tillhörande XSD.
Detta beror förmodligen på att schema filen inte finns och eller att sökvägen (som skall vara relativ i förhållande till WSDL:n) är fel.

...