Teknisk leverandørspor - Serviceplatformen
Dagsorden 1. Velkomst og opfølgning 2. Brainstorm 3. Demo Administrationsmodul 4. Brugerstyring, certifikater og adgang til services 5. Integrationsmønstre 6. Testdata 7. Versions- og releasestyring 8. Orientering fra kommunedialog 9. Afsluttende spørgsmål og dialog 2
Velkomst og opfølgning
Opfølgning (1) Kan mails fra Administrationsmodulet ende i en postkasse hos Kommunen, som ingen håndterer? Vi skal understøtte både FOCES og VOCES FOCES er det mest anvendte. (de færreste leverandører har et VOCES) i forbindelse med Tilslutning af et nyt anvendersystem. Det er ok, at brugeren skal hente et certifikat. Det begrænser dog antallet af personer der kan oprette en Tilslutningsaftale, da det ikke er alle virksomheders organisationer, der ønsker at smide rundt med deres sikkerhedscertifikater. Det skal ikke være muligt selv at indtaste PID/FID numre fra certifkaterne. 4
Opfølgning (2) Der blev udtrykt ønske om at vi medtager Subject common name fra certifikatet. Det er ud fra navnet vi kan se hvilket certifikat vi har anvendt. Fjern navnefeltet på Tilslutningsfanen(det sidste) det er redundant information. Leverandørerne ønsker kun at indtaste navnet på deres system. De har ikke behov for andet. På den læsevenlige udgave: Oplysninger skal stå i samme rækkefølge som ved indtastning. Generelt: Fjern alle ikke obligatoriske felter. Aftalt på kontrolpunktsmøde at vi fjerner IP-adresse. Ønske om at få overblik over status på hvilke kommuner, i en serviceaftaleanmodning, der har godkendt/afventer. Kan f.eks. gøres ved at summere overblik på forsiden. Anvendelse af certifikater 5
Brainstorm
Brainstorm KOMBIT ønsker at brainstorme på de tekniske udfordringer og muligheder, der foreligger for at udnytte Serviceplatformen som kildesystem og i fællesskab vurdere konsekvenserne heraf. Herudover ønskes bl.a. input til om der er væsentlige forskelle på leverandører, der arbejder indenfor forskelle domæner eks. løn og personale og skoleområdet ifm. Serviceplatformen. 7
Demo - Administrationsmodul
Brugerstyring, certifikater og adgang til services
Brugerstyring på Serviceplatformen Adgang til Serviceplatformens Administrationsmodul NemID login med medarbejdercertifikater Første bruger bliver udnævnt til SPA (ServicePlatform Administrator) med alle rettigheder for leverandøren SPAer opretter flere brugere og tildeler beføjelser Vi skal bruge medarbejderens certifikat men ikke private nøgle Husk mail adresse i certifikatet. Personnummer er unødvendigt. KOMBIT forventer at oprette jeres første SPA administrativt Hertil skal KOMBIT bruge navn, kontaktinformation og MOCES certifikat informationer KOMBIT vil stå for at starte en indsamling af informationer 10
Brugerstyring på Serviceplatformen Kom godt igang tips: Hvis brugere mister deres certifikat, kan en SPA genoprette brugeren Opret gerne flere brugere og fordel arbejdet Udnævn gerne 2 SPAer (men ikke for mange) Ved fornyelse af eksisterende certifikat skal brugeren ikke genoprettes Sikr jer at DanID / NETS emails om certifikatudløb håndteres fx funktionspostkasse hertil KOMBIT regner med at udgive en guide 11
Certifikater til adgang til Serviceplatformen Anvendersystemernes adgang styres af certifikater Der oprettes en tilslutningsaftale Denne indeholder certifikat subject (F/VOCES) Serviceplatformen kigger alene på subject Det er tilslutningsaftalen, der bruges til serviceaftalerne Certifikaterne kan fornys hos DanID / NETS Dette betyder normalt at subject (FID/UID) er uændrede Fornyelse betyder dermed at tilslutningsaftalen stadig virker Dermed virker alle indgåede serviceaftaler fortsat 12
Certifikatstyring for systemerne Certifikater kan udløbe FOCES/VOCES certifikater holder normalt 2-3 år DanID / NETS advarer om udløb via mail Men kun hvis certifikatet indeholder en mail adresse Sikr jer at DanID / NETS emails om certifikatudløb håndteres fx funktionspostkasse hertil KOMBIT regner med at udgive en guide 13
Kald til Serviceplatformen Kald forudsætter tilslutningsaftale og serviceaftale Begge disse oprettes i Serviceplatformens aftale database Ved alle kald skal der refereres til disse ved UUID Dertil kommer en udpegning af kommune og ønsket service Ved hvert kald skal der derfor medleveres 4 UUID er i en kontekst Aftager (kommune) UUID Service UUID Serviceaftale UUID System (tilslutningsaftale) UUID 14
InvocationContext <InvocationContext> <ServiceUUID>8ee213c7-c3b0-11e2-8670-d4bed98c63db</ServiceUUID> <UserSystemUUID>d1fc8fae-acdc-e1e0-b4c2-465bf6bfd904 </UserSystemUUID> <ServiceAgreementUUID>dafae292-a2d2-11e2-b4c2-465bf6bfd904 </ServiceAgreementUUID> <UserUUID>cc443c16-ac1d-11e2-abcd-465bf6bfd904</UserUUID> <OnBehalfOfUser></OnBehalfOfUser> <CallersServiceCallIdentifier></CallersServiceCallIdentifier> <AccountingInfo></AccountingInfo> </InvocationContext> 15
Systemer der bruges fra flere kommuner Visse systemer udstilles til flere kommuner Medarbejdere tilgår systemet Der kan være en eller flere instanser Systemet holder hver kommunes data for sig Systemerne skal kalde en service på Serviceplatformen Det er centralt at kommunen identificeres for alle kald Man må ikke udlevere en kommunes data til en anden Indtil en kommune har tiltrådt serviceaftalen må servicen ikke kaldes for den pågældende kommune Man må ikke anvende 1 kommunes serviceaftale til at hente data til alle ens kommuner 16
Opsummering: Kald til Serviceplatformen Opnå tilslutningsaftale og serviceaftale(r) Giver ServiceAgreementUUID og UserSystemUUID Fremskaf UUIDs til kommuner og services KOMBIT informerer om disse Fremskaf WS endpoints (URLer) Opsæt en InvocationContext og kald Serviceplatformens services KOMBIT har udgivet en XSD på InvocationContext HUSK: 2 UUIDer er for den kommune man kalder for Ultimo 2013 UUID er for aftaler, services og tilslutninger vil fremgå af administrationsmodulet når aftaler er på plads URL er til endpoints fremgår af Servicekataloget 17
Integrationsmønstre
Serviceplatformens integrationer Service Omstillingsintegrationer Gennemstillingsintegrationer Replikaintegrationer Orkestreringsintegrationer Fælleskomponenter Beskrivelse Dirigerer anvendersystemet over til korrekt placering af service Foretager kald af service i kildesystem på anvendersystemets vegne Foretager opslag i lokalt, opdateret replika Koordinerer kald til en eller flere services Indkapsler kompleks funktionalitet, fx beregningskomponenter eller brokere 20
Omstillingsintegration 21
Gennemstillingsintegration 22
Replikaintegration 23
Orkestreringsintegration 24
Fælleskomponenter 25
Servicetyper og integrationer Nogle integrationstyper er mere velegnede til at implementere en given service end andre. En markering med X angiver, at en integration er velegnet til at realisere en given servicetype. En markering med (X) angiver mindre velegnet. 26
Eksempler Replikaintegrationer CPR, CVR, Sikrede registeret (sygesikring), Vejregisteret Gennemstillingsintegrationer CPR aktuelle Orkestreringsintegrationer Opdateringer ifbm sygedagpenge Fælleskomponenter Formularmotor, tilskudsberegning 27
Spørgsmål Hvilke services savner i ved udvikling af systemerne? - I har forretningsviden omkring at skulle tilgå snitflader der er svært tilgængelige eller ikke-eksisterende - Hvor vil fx et (read-only) replika hjælpe? - Hvor vil fx en fælleskomponent hjælpe? 28
Testdata
Principper for testdata Omstillingsintegrationer vi laver generelt ikke testdata Gennemstillingsintegrationer vi udnytter generelt kildesystemets test-snitflader Replikaintegrationer vi udnytter kildesystemets data hvis de findes ellers laver vi vore egne Orkestreringsintegrationer vi udnytter generelt kildesystemets test-snitflader Fælleskomponenter vi forventer at lave vores egne 32
Serviceplatformen og testdata Tilgængelige snitflader med officielle testmiljøer indeholdende testdata eller en test-snitflade: CPR CVR OIS 33
Spørgsmål Hvilke behov har I ud over Korsbæk? - I har forretningsviden omkring testdata til forskellige domæner Hvordan forestiller I jer et samarbejde om deling af testdata? - har I erfaringer andre steder fra? Hvor meget arbejde vil I (og jeres kolleger) ligge i et samarbejde? er alle interesserede? 35
Versions- og releasestyring
Services og versioneringsstrategi KOMBIT versionerer udstillede services Major versioner er ikke gensidigt kompatible Minor versioner er bagud kompatible Mikro versioner at alle kompatible (pånær fejlrettelser) Der forventes mindst 2 major versioner af en service KOMBIT orienterer leverandørerne Ved introduktion af nye majorversioner Hvis vi skal rulle en major/minor version tilbage Hvis vi skal fjerne en service Frister for orientering vil afhænge af ændringens grad KOMBIT præsenterer et udkast til næste møde 37
Orientering fra kommunedialog
Afsluttende spørgsmål og dialog
Næste møde 13. juni. Input til emner - skriv til Michel (mjs@kombit.dk) Simon (spe@kombit.dk) Input til data skriv til Mahdad (maf@kombit.dk) 40