Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8
Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer i version 01.05.2014 1.0 KLR / SAPA Første version offentliggjort 20.5.15 1.1 DCH / SAPA Revideret ift. udført arbejde i SAPA regi 1. Indledning og vejledning Dette notat beskriver de integrationsvilkår, der gør sig gældende for it-løsninger, der ønsker at integrere til og fra andre it-løsninger, kaldet Dialogintegration, også betegnet som hop. Dialogintegration har til formål at understøtte en smidig transport af en bruger fra en itløsnings brugergrænseflade til brugergrænsefladen i en anden it-løsning (typisk et ESDH-/fagsystem). Der er altså tale om at et menneske via en brugergrænseflade kan navigere imellem it-løsninger og ikke at it-løsninger kommunikerer eller integrerer. Dialogintegration tillader en sagsbehandler i en it-løsning at hoppe med udgangspunkt i et konkret forretningsobjekt, der vises i it-løsningens brugergrænseflade, til det konkrete forretningsobjekt i den it-løsning forretningsobjektet bor. Den it-løsning der hoppes til startes op som en ny instans, dvs. at hoppes fra eks SAPA til KY vil SAPA og KY være aktive samtidig. Eksemplet neden for viser de generelle forudsætninger når der hoppes fra et afsender system til et modtagende system. Lokal sikkerhedsmodel Lokal sikkerhedsmodel Afsendersystem Modtagende system Forudsætninger for dialogintegration: 1) Modtagersystemets end points hentes via støttesystemet Organisation 2) Der oprettes en sikker forbindelse over HTTPS 3) Den protokolsatte parameterudveksling følges Forudsætninger for dialogintegration: 1) Systemets End points indsættes og vedligeholdes korrekt i støttesystemer organisation 2) Det angivne end point udstilles via HTTPS 3) Systemet håndterer for autentificering af brugeren 4) Den protokolsatte parameterudveksling forstås 5) Baseret på parametrenes indhold vises brugerens for relevante dele af løsningen Dialogintegration, som mekanisme til hop fra en it-løsning til en anden, baserer sig på en række forudsætninger til de involverede systemer, der er skitseret herunder: Adressering: Hop fra en it-løsning til en anden it-løsning kræver, at den modtagende it-løsning har et såkaldt endpoint stillet til rådighed for hop. Udveksling af parametre: De enkelte it-løsninger der kan hoppes til skal understøtte det aftalte format uanset hvordan it-løsningen teknisk set er skruet sammen og kunne understøtte de forretningsobjekter der kan indgå i parameterlisten.
Oversættelse af bruger-kontekst til relevante skærmbilleder: Den modtagende it-løsning skal indeholde en funktionel komponent, der ved hop kan fortolke de angivne parametre med henblik på at kunne dirigere brugeren til specifikke skærmbilleder og objekter i den modtagende itløsning. Eksempelvis sags-oversigter, sags-dialoger og dokument-detaljer. Det er op til den modtagende it-løsning at beslutte hvilket skærmbillede der skal vises. Autentifikation/autorisation: Den it-løsning system der hoppes til er ansvarlig for at kunne autentificere og autorisere den enkelte bruger. Heraf følger, at it-løsningen ligeledes er ansvarlig for at afvise brugere, der har forsøgt et hop de ikke har rettigheder til. 1.1 er Begreb Kaldende it-løsning Modtagende it-løsning Dialogintegration Den it-løsning der initierer en dialogintegration. Den it-løsning der modtager og afvikler dialogintegration. Dialogintegrationen sker i brugergrænsefladen og er defineret som en situation hvor brugeren eksekverer en handling, hvorigennem brugeren ledes fra en dialog (skærmbillede) i den kaldende it-løsning over i en dialog (skærmbillede) i den modtagende it-løsning. Dialogintegration omtales også som hop mellem brugergrænseflader i it-løsninger. Med andre ord er Dialogintegration både et koncept og en række it-tekniske forudsætninger der tilsammen muliggør en brugers navigering imellem brugergrænseflader. Endpoint Det specifikke endpoint i form af URL/sti (se http://www.w3.org/addressing/url/url-spec.txt) udstillet af den modtagende it-løsning, hvortil brugeren og dennes kontekst i form af parametre, videresendes. Parametre overføres til den modtagende it-løsning, ved at eksekvere en https request, som beskrevet i afsnit 2.2 Den modtagende it-løsning er ansvarlig for at kunne fortolke de medsendte parametre og dirigere brugeren videre til den ønskede dialog i it-løsningen (eksempelvis til den konkrete sag eller dokument). Endpoints skal være registrerede i det fælleskommunale støttesystem Organisation, se 2.1
Parametre De medsendte parametre fra den kaldende applikation, som beskrevet i afsnit (Denny henvisning tak) Forretningsobjekt De typer af objekter, eks. Sag, Part og Dokument (se 1.1 nedenfor for en komplet liste) der kan udføres dialogintegration for HTTPS Secure Hypertext Protocol, en kommunikations protokol der muliggør dialog imellem forskellige it-løsninger 2. Krav til it-løsninger for at kunne udføre dialogintegration Der er opgaver der skal løses for at en it-løsning kan indgå i Dialogintegration. Indeværende kapitel beskriver selve protokollen for Dialogintegrationen og de tekniske foranstaltninger de den kaldende og modtagende løsning skal foretage. Modtagende system Først og fremmest skal den modtagende It-løsning kunne forstå samt reagere på et HTTPS protokol kald og dernæst have et endpoint (indgang) til It-løsningen, der ud fra de modtagne parametre kan vise detail informationer, der er relevante ift. de modtagne parametre. Det er alene op til det modtagende It-løsning at beslutte hvilke detail visninger der kan hoppes til samt reaktionen på parametrene. Der stilles således ikke fra protokollens side nogle konkrete krav til hvor mange af parametrene der skal understøttes. Hvilke parametre der ud fra puljen af parametre kan behandles er op til det modtagende system. Kaldende system Tilsvarende skal den kaldende IT-løsningen kunne foretage et HTTPS kald til andre itløsninger, herunder at kunne udlæse relevant endpoint fra det fælleskommunale støttesystem Organisation (se beskrivelse af dette i afsnit 2.1). Nedenstående figur visualiserer de tekniske krav der stilles til en modtagende og kaldende It-løsning.
Modtagende system 2. Hop Kaldende system 1. Hent endpoint Serviceplatformen Organisation De to trin består i følgende handlinger: 1. Hent endpoint: Det modtagende systems Endpoint hentes via støttesystemet Organisation igennem Serviceplatformen. Værdien for Endpoint enten hentes løbende via direkte kald til støttesystemet, eller der kan oprettes et abonnement på systemets Endpoint i beskedfordeleren. 2. Når destinationen er afklaret, og det samtidig er afklaret med det modtagende system, hvilke værdier dette system skal modtage (se afsnit 2.3), kan et HOP udføres via en simpel HTTPS forespørgsel, hvor URL følger de retningslinjer der er skitseret i afsnit 2.3.1. Både modtagende og kaldende It-løsninger kan således være browserbaserede, tykke GUI klient, mainframe løsninger eller andet; det er bare op til It-løsningen at kunne modtage et HTTPS kald og starte relevant skærmbillede i It-løsningen op, uanset hvilken teknologi It-løsningen er udviklet og afvikles på. De kommende afsnit giver en yderligere præcisering af de tekniske aspekter ved Dialogintegration. 2.1 Udstilling af endpoint It-løsningen skal have et endpoint defineret i det fælleskommunale støttesystem Organisation. Objekt typen it-system skal anvendes. Navn skal være ENDPOINT + navn på system (eksempelvis ENDPOINT SAPA) og der skal være en relation til en forekomst af objekt typen Adresse af typen URL. Data indrapporteres pr. myndighed. URL skal være af format www.navn.dk eks www.sapa.dk/dialogintegration.
2.2 HTTPS protokol skal understøttes Den URL som endpoint peger på skal kunne forstå et HTTPS protokol kald samt kunne forstå og anvende de parametre der kaldes med. Der vil fra den kaldende it-løsning skulle foretages et HTTPS GET kald (se http://www.w3.org/protocols/rfc2616/rfc2616-sec9.html), der skal opfattes som et fire and forget kald. Der er altså ingen mulighed for at kommunikere tilbage til den afsendende It-løsning, eller følge op på om protokol kaldet var succesfuldt. Kaldet er at sammenligne med at brugeren i adressefeltet på en browser, selv skrev URL og parametre mv. 2.3 Protokol som den ser ud Protokollen versioneres, version indgår i kaldet. Her er listet de versioner der enten er gældende eller har været gældende: 2.3.1 Version 1 (status: gyldig version) Eksempler på et version 1 kald: https://www.sapa.dk/dialogintegration?myndighed=29189420&k ontekst=sag&objekt1=part&objektvaerdi1=1234567812&objekt2= SAG&ObjektVaerdi2=ABCDEFGH123&Version=1 https://www.sapa.dk/dialogintegration?myndighed=64942212&k ontekst=part&objekt1=part&objektvaerdi1=1234567812 Herunder er i skemaform indholdet af kaldet Parameter Myndighed Kontekst Teknisk definition Type Obligatorisk QS parameter navn Værdi datatype Værdi udfaldsrum Eksempel Type Obligatorisk QS parameter navn Værdi datatype Værdi udfaldsrum Beskrivelse Statisk parameter med én værdi Nej Myndighedsident Heltal Gyldigt CVR nummer Myndighed=29189420 Beskrivelse Statisk parameter med én værdi Nej Kontekst Tekst Følgende værdier er gyldige: PART SAG DOKUMENT
Objekter Eksempel Type Obligatorisk QS parameter navne Værdi datatype Værdi udfaldsrum Eksempel Kontekst=SAG Beskrivelse Dynamisk parameter med varierende antal værdier Nej Der benyttes et varierende antal parameternavne. For hver objekt der ønskes værdiansat tilføjes to parametre; Objekt[i] og ObjektVaerdi[i], hvor [i] er et fortløbende heltal startende fra 1. Tekst Følgende objekter er gyldige: PART SAG DOKUMENT BEVILLING GENSTAND Som udgangspunkt ønskes UID benyttet for værdierne. Det er dog det modtagende system, der endeligt fastsætter værdierne. Rækkefølgen for angivelse af værdier er valgfri. Hver værditype må kun optræde én gang Objekt1=PART&ObjektVaerdi1= 1234567812&Objekt2=SAG& ObjektVaerdi2=ABCDEFGH123 Version Beskrivelse Type Statisk parameter med én værdi Obligatorisk Nej, hvis undladt antages værdien 1 QS parameter navn Version Værdi datatype Decimal Værdi udfaldsrum Følgende værdier er gyldige: 1 Eksempel Version=1 2.4 Kontekstfortolkning og ikke-browser baserede løsninger Den modtagende it-løsnings endpoint skal indeholde en funktionel komponent, der ved kald kan fortolke parametrene og kunne dirigere brugeren til specifikke skærmbilleder og forretningsobjekter i den kaldte it-løsning. Udformning og implementering af denne funktionelle komponent påhviler leverandør af it-løsningen.
Såfremt der er tale om en it-løsning der ikke er browser baseret er det it-løsningens ansvar at sikre at relevant skærmbillede startes op. Eksempelvis kunne det være nødvendigt at have data registreret på en windows klient, her kan https://msdn.microsoft.com/library/aa767914(v=vs.85).aspx hjælpe, men det er op til it-løsningen at dirigere brugeren til det korrekte skærmbillede. Som udgangspunkt forventes det at de omtalte forretningsobjekter er genkendelige i den modtagende it-løsning. 2.5 Autentifikation/autorisation af brugere Den modtagende it-løsning er ansvarligt for at kunne autentificere og autorisere den enkelte bruger. Heraf følger, at it-løsningen er ansvarlig for at afvise brugere, der har fulgt et link de ikke har rettigheder til. Herefter er det modtagende it-løsnings rettighedsmodel der sikrer at brugerens adfærd er som defineret.