SHS version 2.0 Håkan Svenson, CTO

Vad är SHS? Toppledarforum 1996 ”Gemensamma IT-plattformar för informationsutbyte” SHS = Spridnings och HämtningsSystem” Några år senare ”återfann” man begreppet då RFV, RSV och Statskontoret specificerade och upphandlade en ”produkt” för säker kommunikation Det är en teknisk specifikation och har också blivit ett begrepp

Bakgrund SHS tuffar på i det tysta, säkert och med stora volymer Men det har länge funnits ett behov och ett tryck att modernisera konceptet SHS NG har länge varit i vardande European eLink FGS Verva projekt SHS 2.0 Samarbete med vården på G med RIV 1.0… … men det blev verklighet kring RIVTA 2.0 Det har hänt en del sedan 1998. Det fanns saker som behövde moderniseras

Bakgrund Försäkringskassan har tagit över ansvaret för SHS-specifikationen från Kammarkollegiet 2010 Ett SHS-råd med myndigheter och leverantörer har bildats och träffats ett par gånger per år En hopsamling och uppstädning av specifikationen kallad ”SHS 1.3” Arbetat med SHS version 2.0 Under våren 2013 fastslog man version 2.0 av SHS

Utgångspunkter Samarbeta/samordna med liknande arbeten inom vården (Inera) dvs RIVTA 2.0 Stärk SHS där det behövs, behåll det som är bra Undvika stora ingrepp i såväl specifikation som implementeringar Ta ett steg i taget

SHS starka och svaga sidor Styrkor Känd säkerhet Filöverföring, speciellt stora filer Ostrukturerat innehåll Asynkron hantering Svagheter Direktåtkomst/synkron hantering Strukturerat innehåll

SHS-stacken från version 2.0 Katalog Web Service (från RIVTA) ”Classic” Sync-engine Async-engine Gemensamt SHS (produkttyp, avsändare, mottagare, katalog, adressering, spårbarhet…)

SHS version 2.0 Tillägg till specifikationen (SOAP-based protocol) Baserat på Inera’s RIVTA 2.0 (och i någon mån SSEK) Som är baserat på WS-I Basic Profile 1.1 Som är: The WS-I Basic Profile (official abbreviation is BP), a specification from the Web Services Interoperability industry consortium (WS-I), provides interoperability guidance for core Web Services specifications such as SOAP, WSDL, and UDDI. (Wikipedia) Samt hantering av bilagor enligt XOP/MTOM Mappning till SHS-koncepten Samt allt från ”Classic” SHS

Användningsscenarie 1 Infrastruktur Stor aktör kommunicerar med en annan stor aktör via sina SHS-noder Inblandade verksamhetssystem kommunicerar alltid via noderna Soap:Header med Adressinformation, korrelationsid mm Typ direktåtkomst mellan myndigheter Klassiskt SHS scenario Bilateralt (eller många till en) med routing

Användningsscenarie 2 Liten aktör Liten aktör kommunicerar med stor aktörs SHS-nod Det är ett verksamhetssystem knutet till noden som tar emot eller besvarar Man vill använda renodlad Web Service, d.v.s. utan soap:Header Typ FK Tanden Bilateralt eller många till en, utan routing Saknad shs.label = ”implicit addressing”

Tjänsteinteraktionstyper Fråga-svar (requset-response) Alltid ett helt igenom synkront anrop beskrivet i ett tjänstekontrakt Informationsspridning (oneway) I grunden ett synkront anrop beskrivet i ett tjänstekontrakt. Svaret har ingen semantisk betydelse utöver ok eller fel. Hanteras SHS-mässigt synkront. Genom lokal konfiguration (regel) i den nod som servar anropet kan man välja om ev. fortsatt bearbetningen skall vara synkron eller asynkron men det är utanför specifikationen Uppdrag-resultat (request-reply) Två från varandra fristående synkrona anrop, oftast av typen Informationsspridning Hanteras SHS-mässigt synkront. Genom lokal konfiguration (regel) i den nod som servar uppdrag eller resultat-anropet kan man välja om ev. fortsatt bearbetningen skall vara synkron eller asynkron men det är utanför specifikationen De inblandade noderna behöver inte ha någon kunskap om att en relation finns mellan uppdraget och resultatet. En stark rekommendation är dock att av spårbarhetsskäl relatera dessa med varandra genom samma värde på korrelationsid Allt är i grunden synkront (Web Service är i grunden synkront)

Produkttyper och adressering SHS-label Kan utelämnas. Det tolkas som till den lokala noden Avsändare. Kontrolleras mot certifikat (funktion från SSEK) alternativt skapas från certifikat Mottagare Produkttyp (skapas av 1’a nod) TxId (skapas av 1’a nod) CorrId (optionellt) Fysisk Adressering Sker via katalogen pss som tidigare, dvs en ändpunkt slås upp i adressobjektens attribut ”shsDelieveryMethods” med mottagare och produkttyp som nyckel

Hur bestäms produkttyp? <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tan="http://fk.se/SHS/xsd/tanden"> <soapenv:Body> <tan:FK.TV.TestRoundTripRequest organization-number="1234567898" request-id="a4924e42-4214-ba93-0014-98739237ba27" shs-invoked-interface="Submit Claim v2" vendor-name="Klinik X" product-name="Undersökning Y" version-number="1" user-id="197701011234"> <tan:clinic-id>33312341</tan:clinic-id> </tan:FK.TV.TestRoundTripRequest> </soapenv:Body> </soapenv:Envelope> Root-element och/eller root-elementets namespace slås upp i en regeltabell som ger produkttyp.

Felhantering Den totala bilden är ganska komplex Vi vill ha : Två skikt är inblandade, SHS och applikation. Behoven i dessa är olika och vi vill inte heller att de ska blanda sig i varandras göranden I applikationerna används olika verktyg och programvaror som har sina olika egenheter i t.ex. hur exceptions hanteras i genererad kod Vi har två olika scenarier med olika målgrupp av utvecklare Vi vill ha : Bra felhantering inom SHS Möjlighet till bra felhantering appl till appl Möjlighet till bra mappningar av fel till exceptions i olika verktyg Att i största möjliga mån slippa se något av SHS-skiktet vid utveckling av tjänster i applikationer Man kanske inte alltid kan få allt utan måste kompromissa

Att se eller inte se SHS I det här enkla scenariot vill vi helst inte se något alls av SHS i tjänstekontrakten. Varken header eller faultMessages. Risken för SHS-relaterade fel är även ganska liten I det mer komplexa scenariot måste vi hantera ett schema för SHS headerelement i tjänstebeskrivningen. Då är det ingen stor sak att även hantera ett extra faultMessage för SHS

Att komponera tjänstekontrakt (mycket översiktligt) SHS header elements schema WSDL MyServiceRequest schema MyServiceRequestMessage MyServiceResponseMessage MyServiceResponse schema MyServiceFaultMessage SHSServiceFaultMessage MyServiceFault schema SHSServiceFault schema

Felhantering Interna fel inom SHS hanteras med en fördefinierad faultData-struktur som innehåller relevanta uppgifter om felet Specifikationen innehåller ett schema för faultData Felhantering mellan applikationer end-to-end är öppet för tjänsteutvecklarna att själva bestämma Använda soapFault eller… …använda andra (egna) mekanismer för felhantering Felhantering mellan applikationer är inte svart eller vitt utan ett ganska så grått område. Det finns goda skäl att i olika fall hantera det på olika sätt SHS version 2.0 tillåter olika felhanteringsstrategier i applikationsutvecklingen

Smått och gott Skillnader mot RIVTA minimala Interoperabilitet mellan statliga myndigheter, kommuner och landsting inom räckhåll Samarbetsgrupp SHS-RIVTA diskuteras Promotas av e-delegationen och passar in i EU’s arkitektur-ramverk (EIF) Från RIVTA har SHS ärvt en handboksdel med riktlinjer om hur man konstruerar scheman mm för tjänster FK kommer att ta fram en exempeltjänst inklusive en guide för utvecklare av tjänster

SHS version 2 till iipax 5.3 Som ny protokollmodul Stöd för SHS 2.0 standarden Samt Produkttypsmappning från url (finns i spec WSGW men inte SHS 2.0) Standardplugin för vidareanrop Web Service Standardplugin för lokal lagring (asynkron överföring) Protokollbryggningar