Virtuell tjänst
En virtuell tjänst erbjuder en anslutningspunkt per tjänstekontrakt som standardiserats genom RIVmetoden. I praktiken finns det ofta många tjänsteproducenter (regionala, landstingsspecifika 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.
Driftsätta virtualiseringar i Virtualiseringsplattformen
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.
För RTJP eller annan installation som funderar på att byta från Mule till nya VP
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örmodleigen 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.