SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA

Transkript

1 26. marts 2014 NOTAT SAPAs forretningsmæssige behov i relation til Dialogintegration Dette notat beskriver SAPAs specifikke forretningsmæssige behov i forhold til integration med relevante ESDH-/fagsystemer, i form af muligheden for at understøtte en smidig transport af en bruger fra SAPA it-løsningens brugergrænseflade til brugergrænsefladen i en anden it-løsning. Notatet beskriver Dialogintegrationsbegrebet, SAPAs konkrete behov i forhold til integration, samt det arkitekturmønster der tænkes anvendt og de forudsætninger dette stiller til de enkelte kildesystemer. SAPAs behov for Dialogintegration SAPA-systemet er at betragte som en glasplade, dvs. en web-portal, der samler og sammenstiller information om sager, parter og ydelser fra en række kommunale ESDH- /fagsystemer og udstiller denne information til dets brugere. De relevante ESDH-/fagsystemer føder løbende opdateret information om deres respektive sags-, dokument og ydelsesdata via en fastlagt system-grænseflade til Sags- og Dokumentindeks og Ydelsesindeks. SAPA har en snitflader til disse fælleskommunale indekser og udstiller således kun metadata om de enkelte sager, ydelser og dokumenter (id er, parter, sags-status, sags-ejere mv.). Egentlig sagsbehandling udføres og hører hjemme i de respektive ESDH-/fagsystemer. Dialogintegration er en del af SAPA-systemet idet SAPA tillader en sagsbehandler, der arbejder i SAPA-systemet, at hoppe fra en konkret sag, ydelse, eller dokument i SAPAs brugergrænseflade til den konkrete sag eller dokument i det ESDH-/fagsystem, hvor sagen bor. Behovet opstår, såfremt brugeren har behov for yderligere detaljer end det der vises i SAPA eller der er behov for videre sagsbehandling med konkret registrering af oplysninger direkte i ESDH-/fagsystemet. Denne funktionalitet vurderes at kunne lette sagsbehandlerens arbejdsgang betydeligt, da det vil spare den enkelte sagsbehandler for dobbeltindtastning, udsøgning og navigation i multiple it-systemer. Fordele ved brug af dialogintegration i SAPA Ideelt set vil en fuldt udviklet 1 dialogintegrations-funktionalitet give SAPAs brugere følgende fordele: Automatisk viderestilling til det relevante it-system: SAPA kan på basis af metadata identificere det it-system (i form af en URL/ endpoint ), som brugeren skal videresendes til. Det betyder i praksis, at brugeren automatisk kan blive viderestillet ( hoppe ) fra SAPAs brugergrænseflade til det ESDH- /fagsystem som ejer data og se yderligere oplysninger om sagen/parten, 1 Se venligst afsnittet Understøttelse af hop fra SAPA, for uddybning. KOMBIT A/S Halfdansgade København S Tlf CVR Side 1/6

2 såfremt vedkommende har de nødvendige rettigheder til kildesystemet. Dermed spares tid og klik til at åbne det relevante fagsystem, da dette sker via hop direkte fra SAPA brugergrænseflade. Overførsel af kontekst: SAPA kender metadata på det objekt (sag, ydelse, dokument), som brugeren klikker på, hvilket giver mulighed for at gå direkte til den pågældende brugergrænseflade-dialog i det relevante ESDH-/fagsystem. Dermed får brugeren sin kontekst med over i det relevante it-system og kan med de rette parametre blive viderestillet direkte til de relevante oplysninger om f.eks. parten eller sagen. Derved undgås manuelle udsøgninger, navigation og traversering af menuer. Single sign-on eller adgang efter login-prompt: SAPA medsender information om den aktuelle bruger, som det modtagende system kan benytte til autentifikation og autorisation. Afhængig af de tekniske muligheder i det modtagende it-system, er der basis for single sign-on. Brugeren kan dermed springe processen med at skulle logge på det pågældende system helt eller delvist over og blive viderestillet direkte til de relevante oplysninger om f.eks. parten eller sagen. Integrationsform I sin kerne handler dialogintegrations -begrebet om integration mellem heterogene applikationer/systemer. For at kunne hoppe fra SAPA-systemet til et andet system i det kommunale systemlandskab kræves en eller anden form for integrationsmekanisme mellem de to systemer. Typisk etableres denne integration på data-niveau eller på metode- og service-niveau. Dialogintegration, som beskrevet ovenfor, adskiller sig fra mere traditionelle integrationsformer på mindst to områder: 1) Antallet af og forskelligheden i de ESDH-/fagsystemer, der er i scope for SAPA, gør individuelle (system-til-system) integrationer mindre attraktive 2) Den enkelte bruger er ansvarlig for at drive interaktionen og dermed adgang til data og logik, hvorfor det giver mening at foretage integrationen på brugergrænseflade-niveau Med henblik på at understøtte dialogintegration i SAPA, er der udarbejdet et konkret arkitekturmønster (ikke en del af det offentliggjorte materiale). Dette mønster, der reflekterer SAPAs behov for dialogintegration, har mange lighedspunkter med den integration, der er udviklet til brug med KMDs systemer: Hop fra SAPA til et modtagende it-system er underlagt sikkerheden i sidstnævnte. Brugerens kontekst overføres fra SAPA til det modtagende it-system i form af parametre. Hop fra SAPA giver ikke brugeren rettigheder til at se information, som denne ikke i forvejen har adgang/rettigheder til at se i det modtagende it-system. Er brugeren ikke kendt i modtagersystemet og i besiddelse af de fornødne rettigheder, vil brugeren blive mødt af en fejlside i det modtagende it-system. KOMBIT A/S Halfdansgade København S Tlf CVR Side 2/6

3 SAPA er udelukkende ansvarlig for viderestillingen. Det er det modtagende itsystems ansvar, at håndtere eventuelle fejl i parametre eller andet, der måtte forhindre brugeren i at lande korrekt i det respektive system. Mens det primære behov, set fra SAPA systemet, består i at kunne hoppe fra SAPA ud til et ESDH-/fagsystem, skal det også være muligt at hoppe fra et ESDH-/fagsystem ind i SAPAs sags- eller parts-overblik. Forudsætninger Dialogintegration, som mekanisme til hop fra SAPA til ESDH-/fagsystemer, baserer sig på en række forudsætninger til de involverede kildesystemer, der er skitseret herunder: Adressering: Hop fra SAPA til et andet it-system kræver, at det modtagende systems endpoint er stillet til rådighed for SAPA på forhånd. Udveksling af parametre: De enkelte ESDH-/fagsystemer, der hoppes til fra SAPA, skal kunne modtage og forstå et foruddefineret fast sæt af parametre, der medtages som led i hoppet (fx cpr-nr., sags-id, dokumentid, etc.). Oversættelse af bruger-kontekst til relevante skærmbilleder: Det modtagende it-system skal indeholde en funktionel komponent, der ved kald/viderestilling fra SAPA, kan fortolke brugerens kontekst (i form af de medsendte parametre) med henblik på at kunne dirigere brugeren til specifikke skærmbilleder og objekter i det modtagende system. Eksempelvis sags-oversigter, sags-dialoger og dokument-detaljer. Autentifikation/autorisation: Det system der hoppes til er ansvarlig for at kunne autentificere og autorisere den enkelte bruger, hvad enten det er på basis af separat login eller ved sammenligning af de medsendte brugerparametre med systemets egen brugertabel. Heraf følger, at systemet ligeledes er ansvarlig for at afvise brugere, der har fulgt et link de ikke har rettigheder til. Understøttelse af hop fra SAPA Dialogintegration via SAPA gør en række forudsætninger gældende, for de it-systemer, der skal kunne hoppes til. Disse modtagende it-systemer udgør en heterogen gruppe af applikationer, hvoraf ikke alle nødvendigvis på nuværende tidspunkt kan leve op til de gældende forudsætninger i fuld grad. Der kan også være andre grunde til, at man måtte ønske ikke at prioritere tilpasning af eksisterende it-systemer, for at understøtte fuld dialogintegration med SAPA Grad af integration Tabellen nedenfor skitserer forskellige grader af hop til ESDH-/fagsystemer, sammenstillet med de forudsætninger de stiller til det enkelte fagsystem: KOMBIT A/S Halfdansgade København S Tlf CVR Side 3/6

4 # Grad af integration Delt sikkerhedsmodel Adressering Udveksling af parametre Mapning af brugerkontekst Autentifikation/ autorisation 1 Single sign-on Påkrævet Påkrævet Påkrævet Påkrævet Påkrævet 2 Hop til sag Påkrævet Påkrævet Påkrævet Påkrævet 3 Hop til dokument Påkrævet Påkrævet Påkrævet Påkrævet 4 Hop til sags- eller person-overblik 5 Hop til sags- eller person-overblik (bruger har aktiv fagsystem session) 6 Hop til web- eller login-side (og derefter manuel udsøgning og navigation) Påkrævet Påkrævet Påkrævet Påkrævet Påkrævet Påkrævet Påkrævet Påkrævet 7 Kopier sags-metadata til udklipsholder Som det fremgår, spænder definitionen af hop fra single sign-on (hvor den enkelte bruger sømløst bliver transporteret mellem systemer, uden eksplicit at skulle identificere sig selv) i den ene ende af spektret, til web- eller login-side (hvor det videste brugeren kan blive transporteret, er til det modtagende systems forside/loginside, vel at mærke uden brugerkontekst) i den anden ende af spektret. Kopier sagsmetadata til udklipsholder det laveste niveau af integration - repræsenterer en situation, hvor SAPA brugeren kan få kopieret sags-metadata (cpr-nummer, sags-id, system URL mm.) fra den aktuelle sag i SAPAs sags-overblik, som brugeren da kan bruge til at indsætte i sin søgning i det aktuelle ESDH-/fagsystemer. Den enkelte kommune kan sammen med de relevante leverandører finde ud af, hvilket niveau af integration de ønsker/kan tilbyde. Brugeroplevelse i forbindelse med hop fra SAPA Der er identificeret et behov for at kunne hoppe fra SAPA brugergrænsefladen til et andet it-systems brugergrænseflade. I nedenstående tabel beskrives den forventede brugeroplevelse i forbindelse med hop fra SAPA. Det forventes ikke, at 3. parts itsystemer i samme grad kan understøtte behovet, da dette vil afhænge af det enkelte systems tekniske muligheder i forhold til de ovennævnte forudsætninger der gør sig gældende for integrationen. Samtidig vil det afhænge af de behov/ønsker kommunerne har, for at kunne hoppe til en sag, et personoverblik m.m. i det pågældende system. KOMBIT A/S Halfdansgade København S Tlf CVR Side 4/6

5 # Behov Brugeroplevelse 1 Single sign-on Brugeren transporteres fra SAPA direkte til den relevante skærmdialog i det modtagende system, uden yderligere brugerinteraktion. 2 Hop til sag Brugeren transporteres fra SAPA til det modtagende systems loginside. Umiddelbart efter login transporteres brugeren videre til den relevante skærmdialog for den pågældende sag i det modtagende system, uden yderligere brugerinteraktion. 3 Hop til dokument Brugeren transporteres fra SAPA til det modtagende systems loginside. Umiddelbart efter login transporteres brugeren videre til den relevante skærmdialog for det pågældende dokument i det modtagende system, uden yderligere brugerinteraktion. 4 Hop til sags- eller personoverblik 5 Hop til sags- eller personoverblik (bruger har aktiv fagsystem session) 6 Hop til web eller loginside (og derefter manuel udsøgning og navigation) 7 Kopier sags-metadata til udklipsholder Brugeren transporteres fra SAPA til det modtagende systems loginside. Umiddelbart efter login transporteres brugeren videre til sagseller personoverblikket i det modtagende system, uden yderligere brugerinteraktion. Herfra fortsætter brugeren manuelt sin udsøgning eller sags-behandling i it-systemet. En variant af 2, 3 og 4 herover, hvor en bruger, der allerede er logget på det pågældende ESDH-/fagsystem, transporteres direkte til det pågældende skærmbillede uden yderligere brugerinteraktion. Brugeren transporteres fra SAPA til en web-side eller det modtagende systems login-side. Efter login navigerer brugeren manuelt gennem de nødvendige skærmbilleder og indtaster de ønskede sags-oplysninger. Brugeren får automatisk kopieret sags-metadata (cpr-nummer, sags-id, system URL mm.) fra den aktuelle sag i SAPAs sags-overblik. Brugeren logger herefter på ESDH-/fagsystemet og kan da indsætte det kopierede indhold i sin søgning i det aktuelle system. Der er med andre ord ikke tale om et egentlig hop i dialogintegrationsforstand. Understøttelse af hop til SAPA De kommende fælleskommunale it-systemer KY og KSD har identificeret et behov for også at kunne hoppe ind i SAPAs sags- og parts-overblik, fra deres respektive systemer. Det kan ikke udelukkes, at andre tredjeparts it-systemer ønsker at tilbyde den samme funktionalitet for at lette sags-arbejdet. KOMBIT A/S Halfdansgade København S Tlf CVR Side 5/6

6 Understøttelse af denne funktionalitet betyder, at SAPA skal leve op til følgende forudsætninger: Adressering: Hop til SAPA fra et andet it-system kræver, at SAPAs endpoint er stillet til rådighed for det kaldende system på forhånd. Udveksling af parametre: SAPA skal kunne modtage og forstå et foruddefineret sæt af parametre, der medtages som led i hoppet (fx brugerident, cpr-nr. mm). Oversættelse af bruger-kontekst til relevante skærmbilleder: SAPA skal indeholde en funktionel komponent, der ved kald/viderestilling udefra, kan fortolke brugerens kontekst (i form af de medsendte parametre) med henblik på at kunne dirigere brugeren til sags-og person/overblik i SAPA systemet. Autentifikation/autorisation: SAPA er ansvarlig for at kunne autentificere og autorisere den enkelte bruger, hvad enten det er på basis af separat login eller ved sammenligning af de medsendte brugerparametre med systemets egen brugertabel. Heraf følger, at systemet ligeledes er ansvarlig for at afvise brugere, der har fulgt et link de ikke har rettigheder til. De enkelte tredjeparts-systemer, der ønsker at deres brugere skal kunne hoppe til SAPAs sags- og person-overblik, skal implementere funktionalitet, der viderestiller brugeren og dennes kontekst, såvel som den brugergrænseflade-tilpasning, det måtte kræve. KOMBIT A/S Halfdansgade København S Tlf CVR Side 6/6