SHS version 2.0

1. SHS version 2.0 Håkan Svenson, CTO

2. 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

3. 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 • EuropeaneLink • 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

4. 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

5. 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

6. 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

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

8. SHS version 2.0 • Tillägg till specifikationen (SOAP-basedprotocol) • 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

9. 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

10. 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”

11. 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)

12. 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

13. Hur bestäms produkttyp? Root-element och/eller root-elementets namespace slås upp i en regeltabell som ger produkttyp. <soapenv:Envelopexmlns: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="SubmitClaim 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>

14. Felhantering • Den totala bilden är ganska komplex • 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

15. 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

16. Att komponera tjänstekontrakt(mycket översiktligt) SHS header elementsschema WSDL MyServiceRequestschema MyServiceRequestMessage MyServiceResponseMessage MyServiceResponseschema MyServiceFaultMessage SHSServiceFaultMessage MyServiceFaultschema SHSServiceFaultschema

17. 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

18. 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

19. 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