SF 2800 Fordelingskomponent - Modtag objekter Integrationsbeskrivelse - version 2.0.0

Transkript

1 SF 2800 Fordelingskomponent - Modtag objekter Integrationsbeskrivelse - version Kommunernes Datafællesskab - KDF

2 Versionshistorik Relevans Dato Initialer Version Kommentarer MVC 0.1 Første version MVC 0.2 Klar til internt review Ehe 0.3 Klar til fagprojekt review dgj 0.4 Rettelser efter projekt review Tilføjet afsnit med Use-cases EHE 0.5 Klargjort til SP MHO 0.6 Referencerettelser mm EHE Teknisk beskrivelse indarbejdet Referencer Ref Titel Kommentarer [SPref] [SIKKERHED] [STS- Sikkerhed] Se Note vedrørende servicemål for Serviceplatformen.pdf på følgende link: Use cases for brug af sikkerhedsmodeller på Serviceplatformen - v Se vilkår Bilag 2 - Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen version 2.0 på nedenstående link [SFTP] <Indsæt dokumentation af SFTP> Endnu ikke udarbejdet [WSDL] Integrationsbeskrivelsen refererer til version af WSDL, som indeholder tekniske snitfladebeskrivelser for alle snitflader i integrationen. De er placeret under de tekniske beskrivelser i samme mappe som integrationsbeskrivelsen. KOMBIT A/S Halfdansgade København S CVR Side 2 af 60

3 Indholdsfortegnelse 1 Overordnet beskrivelse Integrationens formål Forretningsbehov i relation til fordelingskomponenten Overordnet forretningsflow i integrationen Servicebetingelser for den samlede integration Teststrategi Forudsætninger for produktionssætning af integration Use cases for fordeling af journalnotater og dokumenter Kontekst for integrationsparter Kontekst for KY Kontekst for KSD Specifikation for integrationsparter Specifikation af endpoints for Modtagersystemer Beskrivelse for integrationsplatforme Beskrivelse for Serviceplatformen Services udstillet af Serviceplatformen Services udstillet af Modtager KOMBIT A/S Halfdansgade København S CVR Side 3 af 60

4 1 Overordnet beskrivelse 1.1 Integrationens formål Dette dokument beskriver modtager-siden i fordelingskomponenten. Fordelingskomponenten er en generel fordelingsmekanisme for objekter. Pt. understøttes kun journalnotater og dokumenter. Afsendersiden er beskrevet i SF2720. Dette afsnit beskriver henholdsvis formål, forretningsbehov og forudsætninger for fordelingskomponentens afsenderside. Tilsammen udgør disse forhold den overordnede ramme, som fordelingskomponenten skal fungere. 1.2 Formål med fordelingskomponenten Der er identificeret et behov for en fordelingsmekanisme i rammearkitekturen, der muliggør, at journalnotater og dokumenter kan transporteres fra sekundære systemer, i hvilke de nu kan oprettes, til de primære fagsystemer hvor de associerede sager forvaltes og behandles. Sekundære systemer dækker på nuværende tidspunkt over: SAPA, den kommende sagsportal KMD Sag Multi-fagsystemer (ESDH-systemer), der har behov for at afhænde filer til de nye fagsystemer i rammearkitekturen Fagsystemer, der lever op til de opsatte krav for afsendersystemer og ønsker at benytte fordelingsmekanismen Følgende faktorer driver behovet for en generel fordelingsmekanisme: Introduktionen af SAPA, som et sagsportal-alternativ til KMD Sag, betyder en ny kilde for oprettelse af journalnotater. SAPA er, i modsætning til KMD Sag, blot en glasplade og indeholder ikke funktionalitet til lagring af journalnotater Som led i udfasningsaftalen med KMD, holdes sagsbestanden i KMD Sag ajour med sagsbestanden i Sags- og Dokumentindekset. KMD Sag vil således indeholde såkaldte kopisager, der stammer fra fagsystemer tilknyttet Sags- og Dokumentindekset, mens Sags- og Dokumentindekset vil indeholde metadata på kopi-sager, der stammer fra KMD Sag. Man har traditionelt kunne oprette journalnoter på sager indenfor KMD Sag universet og med den kommende ajourføring, skal det også være muligt at oprette journalnotater og tilknytte dokumenter til kopi-sager, dvs. sager i fagsystemer, der ikke er tilknyttet KMD Sag. Ovenstående betyder også, at KMD Sag kopi-sager vil fremgå i SAPA man vil altså via SAPA også kunne oprette journalnotater på sager, der hører hjemme i KMD Sag universet Multi-fagsystemer har behov for at afhænde dokumenter af relevans for de nye fagsystemer i rammearkitekturen (KY, KSD mv.). Fagsystemer kan have et lignende behov KOMBIT A/S Halfdansgade København S CVR Side 4 af 60

5 Journalnotater og dokumenter hører til i de fagsystemer, hvor de associerede sager forvaltes og behandles. Uanset den oprindelige kilde, skal journalnotater og dokumenter gnidningsfrit kunne fordeles til det fagsystem, hvor de skal indgå i sagsbehandlingen Grafisk kan dette illustreres som i nedenstående figur: Figuren afspejler de tre primære kilder, der leverer input til fordelingskomponenten (KMD Sag, SAPA og Multi-fagsystemer) og det output fordelingskomponenten er ansvarlig for at fordele til de aftagende fagsystemer. Fagsystemer figurerer ikke i figuren som input-systemer, men der er principielt ikke noget der forhindrer dette, såfremt det enkelte fagsystem lever op til de generelle integrationsvilkår for fordelingskomponenten. Figuren illustrerer også forekomsten af kopisager i de to sags-repositories henholdsvis KMD Sag og Sags- og Dokumentindekset Fordelingskomponentens formål Fordelingskomponenten har til formål at overføre objekter (journalnotat eller dokument) fra et navngivent afsender-system til et entydigt identificerbart modtager-system. I denne proces, er det fordelingskomponentens ansvar, at mediere og styre udvekslingen af objekter mellem afsender-systemer og modtager-systemer. KOMBIT A/S Halfdansgade København S CVR Side 5 af 60

6 1.3 Forretningsbehov i relation til fordelingskomponenten Som det fremgår af formålsbeskrivelsen, skal fordelingskomponenten kunne adressere journalnotater og dokumenter fra tilknyttede afsendersystemer, til de fagsystemer, der skal modtage dem. I den forbindelse er der identificeret følgende forretningsbehov: # Objekt Initiator Sagstilknytning Behov B-01 Notat SAPA SI / DI Oprettelse af journalnotat på eksisterende sag B-02 Notat SAPA KMD Oprettelse af journalnotat på eksisterende sag B-03 Notat SAPA Begge Oprettelse af journalnotat uden eksisterende sag B-04 Notat KMD Sag SI / DI Oprettelse af journalnotat på eksisterende sag B-05 Notat KMD Sag Begge Oprettelse af journalnotat uden eksisterende sag B-06 Dokument KMD Sag SI / DI Tilknytning af dokument til eksisterende sag B-07 Dokument KMD Sag SI / DI Tilknytning af dokument uden eksisterende sag B-08 Notat Multi-fagsystem SI / DI Oprettelse af journalnotat på eksisterende sag B-09 Dokument Multi-fagsystem SI / DI Tilknytning af dokument til eksisterende sag B-10 Dokument Multi-fagsystem SI / DI Tilknytning af dokument uden eksisterende sag B-11 N/A Alle N/A Afgørelse af hvorvidt et IT-system er tilknyttet et specifikt kommunalt emneområde Tabellen ovenfor skelner mellem to objekttyper journalnotater og dokumenter og tre primære afsendersystemer - SAPA, KMD Sag og Multi-fagsystem(er) - der hver især initierer fordelingsprocessen med fordelingskomponenten. Som det fremgår har SAPA udelukkende behov for at afhænde journalnotater til fordelingskomponenten, mens KMD Sag og Multi-fagsystemer har behov for at føde både journalnotater og dokumenter ind i fordelingskomponenten. Som det fremgår af Sagstilknytning kolonnen skelnes mellem journalnotater og dokumenter, der skal fordeles til henholdsvis fagsystemer tilknyttet Sags- og Dokumentindekset (SI/DI) og journalnotater og dokumenter, der skal fordeles til fagsystemer tilknyttet KMD Sag. Betegnelsen Begge dækker over en situation hvor et journalnotat eller et dokument fødes ind i fordelingskomponenten, uden at der eksisterer en sag i forvejen. I modsætning til tilknytning af journalnotater og dokumenter på eksisterende sager, kan man i dette tilfælde ikke på forhånd afgøre om det modtagende fagsystem er tilknyttet Sags- og Dokumentindekset eller KMD universet. KOMBIT A/S Halfdansgade København S CVR Side 6 af 60

7 Dette forhold har ingen konsekvens for Fordelingskomponenten, men udelukkende for de modtagende fagsystemer. B-11 dækker over et generelt behov fra Afsender-systemernes side, der tillader dem at informere brugerne af deres brugergrænseflade om hvilke sager, der kan oprettes journalnotater på mm. 1.4 Forudsætninger for fordelingskomponenten KOMBIT har opsat en række forudsætninger og tilhørende integrationsvilkår, der identificerer anvender-systemernes (afsender- og modtager-systemers) ansvar i forhold til fordelingskomponenten. Disse forudsætninger yder direkte indflydelse på de krav, der stilles til fordelingskomponentens funktionalitet. Forudsætningerne skal ses i relation til den foreslåede arkitektur for fordelingskomponenten, der er skitseret herunder Forudsætninger Ud fra formålet i følger at: Afsender-systemet bærer ansvaret for, at det medsendte metadata er tilstrækkeligt i forhold til en entydig identifikation af modtager KOMBIT A/S Halfdansgade København S CVR Side 7 af 60

8 Afsender-systemet bærer ansvaret for, at det faktiske indhold er validt set fra et teknisk perspektiv (meddelelses-format og understøttet filtype) Modtager-systemet er forpligtet til at behandle indhold, der er teknisk validt. Modtagersystemet kan efter behandling afvise oprettelse af journalnoter eller tilsendte dokumenter, der bærer forretningsmæssige fejl Afsender-systemet skal kunne håndtere afvisninger af meddelelser ved forretningsmæssige fejl (fejl i emneområde eller dokumentets semantiske indhold) Entydig adressering og identifikation skal kunne afgøres alene på basis af kommunens specifikke metadata-opsætning i støttesystemet Organisation (og indirekte Klassifikation) Afsender-systemets tilknytning af dokumenter bør i videst mulig omfang indeholde identifikation af den konkrete sag i det pågældende modtager-system, for at give de enkelte modtager-systemer de bedste betingelse for at vurdere dokumentets kontekst Afsender-systemet forpligter sig til at styre, hvilke brugere der har lov til at oprette journalnotater og tilknytte dokumenter til sager via deres respektive grænseflader Modtager-systemet skal kunne håndtere, at den samme anmodning (om oprettelse af journalnotat eller dokument) kan modtages flere gange KOMBIT A/S Halfdansgade København S CVR Side 8 af 60

9 1.5 Overordnet forretningsflow i integrationen Jf. figuren nedenfor indgår følgende forretningsflow i integrationen. Afsendersystem Serviceplatform Modtagersystem Synkront kald for afsend objekt SP videresender til modtager SP returnerer Modtaget (Modtager behandler objektet) Modtager accepterer eller afviser SP returnerer Accept / Afvis FordelingsobjektAfsend FordelingskvitteringModtag FordelingskvitteringModtag FordelingsobjektModtag FordelingskvitteringAfsend Procedure for overførsel af objekter via fordelingskomponenten: - Når et kaldende system har behov for at overføre et objekt (f.eks. Journalnotat eller dokument), kaldes en synkron service på Serviceplatformen. Parallelt kan placeres et eller flere dokumenter på Serviceplatformens FTP-server, der udgør relaterede dele (f.eks. De binære filer med dokuments indhold). Kaldet returnerer en teknisk kvittering i det synkrone kald. Denne kvittering giver resultatet af en foreløbig validering udført af Serviceplatformen. - Modtageren af objektet udstiller en synkron service som Serviceplatformen kalder for at levere objektet. Hvis der er tilknyttet et dokument læser modtageren dette på Serviceplatformens FTP-server. Filens navn fremgår af det objekt Serviceplatformen fremsendte. Modtageren skal acceptere objektet, men returnerer en teknisk validering for om objektet overholder de regler der er aftalt, herunder at et tilknyttet dokument kan læses på FTPserveren. - Når Serviceplatformen har modtaget kvitteringen fra modtagersystemet, videresendes denne til afsendersystemet via den synkrone kvitteringsservice afsendersystemet udstiller. Afsenderen returnerer en teknisk kvittering der kun validerer at forretningskvitteringen har korrekt indhold. - Når modtager har behandlet objektet (eventuelt med manuel proces) kalder modtageren en synkron service udstillet af Serviceplatformen. Dette kald indeholder en forretningskvittering for det modtagne objekt (dvs. er objektet accepteret eller er det afvist). Serviceplatformen returnerer en teknisk kvittering der kun validerer at forretningskvitteringen har korrekt indhold. - Serviceplatformen kalder herefter den synkrone kvitteringsservice udstillet af afsendersystemet. Afsenderen returnerer en teknisk kvittering der kun validerer at forretningskvitteringen har korrekt indhold. KOMBIT A/S Halfdansgade København S CVR Side 9 af 60

10 1.6 Servicebetingelser for den samlede integration Servicemål Parameter Flow 1 Tidsrum Serviceplatformen driftsafvikles hele døgnet alle dage bortset fra når der udføres ændringer/hvor der er servicevinduer [SPref]. [Afklaring/KDF: Åbningstid for fagsystem kendes ikke] Svartid Serviceplatformen har forskellig SLA på svartid alt efter hvilken integrationskompleksitet, der er tale om [SPref]: Simpel = 1 sekund Mellem = 1,5 sekund Kompleks = 4 sekunder [Afklaring/SP: For beskedfordeler, SFTP mv. kendes svartid/ [Afklaring/KDF: Svartid for fagsystem kendes ikke] Tilgængelighed Servicemålene for Serviceplatformen driftseffektivitet er 99,8% for perioden 06:00-18:00 på arbejdsdage samt 98,5 % i den øvrige tid [SPref]. [Afklaring/KDF: Tilgængelighed for fagsystem kendes ikke] Spidsbelastningsperiode Spidsbelastningen for Serviceplatformen må antages at være i perioden 06:00-18:00 på arbejdsdage [SPref]. [Afklaring/KDF: Spidsbelastningsperioder for fagsystem kendes ikke] Servicevinduer Ved mindre opdateringer for Serviceplatformen: En gang om ugen i tidsrummet 05:00-06:00. Varsling: 1. uge, varighed (naturligvis) max en time. Ved større og kritiske opdateringer: Optil 1 gang om måneden i tidsrummet mandag kl. 03:00 til mandag kl. 06:00. Varsling: 1. uge, Varighed: max 3 timer Ved omlægning af miljøer, arkitektur og services for Serviceplatformen: 1 gang pr. kvartal i tidrummet søndag kl. 22:00 til mandag kl. 06:00. Varsling 1. måned, varighed max 8 timer [SPref]. [Afklaring/KDF: Servicevinduer for fagsystem kendes ikke] Service Management Eventuelle tilretninger og præciseringer i integrationens beskrivelse og specifikation, vil indtil integrationen ligger på Serviceplatformens eksterne testmiljø, blive håndteret af Kommunernes Data Fællesskab (KDF). Spørgsmål vedr. specifikation sendes til datafaellesskab@kombit.dk. KDF sørger for at involverede parter i integrationen oplyses om tilretningerne og præciseringerne. KOMBIT A/S Halfdansgade København S CVR Side 10 af 60

11 Se oversigten over hvornår de enkelte integrationer forventes at være tilgængelige i eksternt testmiljø her: Når servicen er tilgængelig i det eksterne testmiljø på Serviceplatformen, vil den overgå til Serviceplatformens governanceproces. Beskrivelse af denne tilgår senere. 1.7 Teststrategi Test i forbindelse med udvikling Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Testfaciliteter og testmiljø Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Testdata Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Test i forbindelse med produktionssætning Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. 1.8 Forudsætninger for produktionssætning af integration Nedenstående er oplysninger om forudsætninger og betingelser, der skal være på plads for at sikre succesfuld tilslutning til integrationsparter Forudsætninger for funktionalitet på Serviceplatformen Ingen identificeret Generelle forsætninger for tilslutning af ny integrationspart Leverandøren skal være oprettet som tilslutningspart i rammearkitekturens administrationsmodul, og leverandøren skal oprette en tilslutningsaftale for it-systemet i administrationsmodulet. Leverandøren skal tiltræde, og overholde, vilkårene i den til enhver tid gældende aftale for tilslutning af it-systemer til den fælleskommunale rammearkitektur. Leverandøren af It-systemet er ansvarlige for at It-systemet tilsluttes via rammearkitekturens administrationsmodul, med den, eller de, systemtyper (brugervendt system, anvendersystem og/eller serviceudbyder), der er relevante for Itsystemet jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. Leverandøren skal anmode om indgåelse af serviceaftale for de myndigheder, der skal bruge servicen, i rammearkitekturens administrationsmodul, og myndigheden skal godkender denne anmodning jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. Leverandøren skal sikre, at tilslutningsaftalen for it-systemet indeholder tilvalg af SFTP [SFTP]. KOMBIT A/S Halfdansgade København S CVR Side 11 af 60

12 [Afklaring/KDF: Tilføj yderligere dokumentation med vejledning i brug af sikkerhedsmodellen, herunder brug af Security Token Servicen, støttesystemer, mv. i Rammearkitekturen, når denne modtages fra STS] KOMBIT A/S Halfdansgade København S CVR Side 12 af 60

13 1.9 Use cases for fordeling af journalnotater og dokumenter Afsnit 1.3 beskriver, i relation til de identificerede forretningsbehov, elleve behov. I praksis, set fra fordelingskomponentens funktionelle perspektiv, kan disse elleve behov sammenfattes i seks use cases, da sondringen i forhold til sagstilknytning er uden relevans for fordelingskomponentens grundlæggende funktionalitet. Følgende, nært beslægtede use cases er identificeret i relation til et afsender-systems anmodning om oprettelse af et journalnotat eller et dokument hos et modtager-system: Figur 1 Use case diagram UC-01 til UC-04 udgør de primære use cases relateret til oprettelse af journalnotater og dokumenter. UC-05 og UC-06 er sekundære use cases, der stiller støtte-funktionalitet til rådighed for af- KOMBIT A/S Halfdansgade København S CVR Side 13 af 60

14 sender-systemer. De to indirekte use cases (UC-98 og UC-99), som omtalt i afsnit Fejl! Henvisningskilde ikke fundet. er udelukkende medtaget for overblikkets skyld. Gennemgangen af de enkelte use cases vil tage udgangspunkt i SAPA, som eksempel på et afsender-system. Princippet vil være det samme for andre afsender-systemer. Givet fordelingskomponentens rolle, som styrende mellemled imellem henholdsvis initierende afsender-systemer og associerede modtager-systemer, er der tale om use cases, der strækker sig over multiple systemer. Det er kun en delmængde af disse aktiviteter, der relaterer sig til fordelingskomponentens funktionalitet, men detaljeniveauet er beholdt med henblik på at skabe forståelse for det samlede flow. Et generelt flowdiagram, der skitserer de overordnede aktiviteter i forbindelse med oprettelse af henholdsvis journalnotater og dokumenter er at finde i afsnit og afsnit Set fra fordelingskomponentens funktionelle perspektiv, er der ikke den store forskel mellem UC- 01 og UC-02. Imidlertid er der subtile forskelle mellem at oprette journalnotater på eksisterende sager og at oprette journalnotater uden eksisterende sager særligt i forhold til afsendersystemerne. For at fange dette forhold behandles de enkelte use cases separat. De enkelte use cases vil desuden indeholde underaktiviteter (identificeret ved aktivitetsnummer x.x), der er specifikke for den enkelte use case. KOMBIT A/S Halfdansgade København S CVR Side 14 af 60

15 1.9.1 Use case overblik Use Case Beskrivelse 1. Anmodning om oprettelse af journalnotat på én eksisterende sag 2. Anmodning om oprettelse af journalnotat uden eksisterende sag 3. Anmodning om oprettelse af dokument på én eksisterende sag 4. Anmodning om oprettelse af dokument uden eksisterende sag Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et journalnotat, hos et modtager-system. Anmodningen drejer sig om én specifik, eksisterende sag i et fag-system. Efter anmodningens modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af journalnotatet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Såfremt afsender-systemet har behov for at oprette samme journalnotat på flere forskellige, eksisterende sager, sender afsender-systemet flere separate anmodninger til fordelingskomponenten. Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et journalnotat, hos et modtager-system. Anmodningen er uden reference til en eksisterende sag. Efter modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af journalnotatet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Såfremt afsender-systemet har behov for at oprette journalnotatet i flere forskellige modtager-systemer, sender afsender-systemet flere separate anmodninger til fordelingskomponenten. Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et dokument hos et modtager-system. Afsender-systemet har forinden placeret det pågældende dokument i et repository, der benyttes af fordelingskomponenten, hvor det relevante modtagersystem senere kan afhente dokumentet. Anmodningen drejer sig om en specifik, eksisterende sag. Efter modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af dokumentet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et dokument hos et modtager-system. Afsender-systemet har forinden placeret det pågældende dokument i et repository, der benyttes af fordelingskomponenten, hvor det relevante modtagersystem senere kan afhente dokumentet. Anmodningen er uden reference til en eksisterende sag. Efter modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af dokumentet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. KOMBIT A/S Halfdansgade København S CVR Side 15 af 60

16 5. Opslag af tilgængelige IT-systemer i støttesystemer på basis af KLE nummer 6. Opslag af tilgængeligt IT-system i støttesystemer på basis af KLE nummer Denne use case beskriver, hvordan et afsender-system forespørger på tilstedeværelsen af et eller flere kommunale IT-systemer inden for en given kombination af KLE emneområde og handlingsfacet, der kan modtage journalnotater/dokumenter. Fordelings-komponenten behandler forespørgslen via opslag i støttesystemet Organisation og returnerer et svar, der indeholder IT-systemernes identifikation i Organisation. Anvender-systemerne kan benytte denne funktionalitet, når de vil støtte deres brugere ved oprettelse af journalnotater/dokumenter på eksisterende sager og hvor der ikke eksisterer en sag i forvejen. Denne use case beskriver, hvordan et afsender-system forespørger på tilstedeværelsen af et specifikt kommunalt IT-system, relateret til en specifik, der kan modtage journalnotater. Fordelings-komponenten behandler forespørgslen via opslag i t Organisation og returnerer et svar (true/false). Afsender-systemerne kan benytte denne funktionalitet, når de ønsker at give deres brugere en visuel indikation af, om der kan oprettes et journalnotat for en given sag i brugergrænsefladen. KOMBIT A/S Halfdansgade København S CVR Side 16 af 60

17 1.9.2 Generelt flow-diagram for anmodning om oprettelse af journalnotater KOMBIT A/S Halfdansgade København S CVR Side 17 af 60

18 1.9.3 UC-01: Anmodning om oprettelse af journalnotat på én eksisterende sag Navn Formål UC-01: Anmodning om oprettelse af journalnotat på én eksisterende sag Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et journalnotat, hos et modtager-system. Anmodningen drejer sig om én specifik, eksisterende sag i fag-system. Efter anmodningens modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af journalnotatet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Aktører Frekvens Afsender-system Modtager-system Fordelingskomponent Støttesystemet Organisation Hver gang et afsender-system har behov for at afhænde et journalnotat til et modtager-system. Indgangsbetingelser En bruger har i afsender-systemets brugergrænseflade markeret en eksisterende sag, som denne ønsker at oprette et journalnotat på. Udgangstilstand Modtager-systemet har accepteret eller afvist anmodningen om oprettelse af journalnotat. Hovedforløb Aktivitet 1 Aktøren Brugeren opretter i afsender-systemets brugergrænseflade et journalnotat og identificerer det metadata, der skal tillade fordelingskomponenten at identificere det relevante modtager-system. Brugeren kan vælge at markere om sagsparten skal fritages for tvungen digital selvbetjening eller en tidligere fritagelse skal tilmeldes igen. 1.1 Brugeren vælger/markerer i afsender-systemets brugergrænseflade, den specifikke sag, som brugeren ønsker at tilknytte et journalnotat til. 1.2 Afsender-systemet kalder proaktivt den af fordelingskomponenten udstillede opslags-service (UC-05) med sagens KLE-nummer, handlingsfacet (hvis relevant) og Kommune-identifikation som input. Servicen returnerer det IT-system, der er opsat til at behandle fagområdet, og dets system-identifikation, som det er identificeret i støttesystemet Organisation. Såfremt der er konfigureret mere end ét IT-system for det pågældende fagområde (KLE-nummer), lader afsender-systemet brugeren udvælge det system, journalno- KOMBIT A/S Halfdansgade København S CVR Side 18 af 60

19 tatet skal sendes til. 1.3 Afsender-systemet forbereder anmodningen ved at berige denne med følgende metadata: Sags-identifikation (fra Sags- og Dokumentindekset) Parts-identifikation (fra Sags- og Dokumentindekset) KLE-identifikation (fra Sags- og Dokumentindekset) System-identifikation (som returneret fra opslags-servicen i 1.2) Brugeren udfylder journalnotatets indhold og initierer anmodningen i afsendersystemet. Afsender-systemet kalder fordelings-komponenten med de identificerede metadata. Payload udgøres af det pågældende journalnotat (og resten af strukturen fra OIO sag standarden). 2.1 Afsender-systemet kombinerer metadata fra trin 1.3, med yderligere data til brug for anmodningen: Bruger-identifikation (id på den bruger, der opretter journalnotatet) Kommune-identifikation Afsender-systemets system-identifikation (eks. SAPAs specifikke identifikation) UUID (der kommer til at udgøre anmodningens transaktionsid) 2.2 Afsender-systemet samler denne information og journalnotatet i OIO Sag XML strukturen og kalder fordelingskomponentens service. Fordelingskomponenten modtager kaldet fra afsender-systemet. Det medsendte UUID lagres som transaktions-id og medtages i alle fremtidige kald til afsender- og modtager-systemet. Såfremt det anses fordelagtigt kan fordelingskomponenten tillige lagre et eget transaktions-id. På basis af det medsendte metadata (KLE-nummer, handlingsfacet, Kommuneidentifikation, System-identifikation), afgør fordelings-komponenten ved opslag i Organisation, om et entydigt identificerbart modtager-system kan identificeres og i så fald, hvilket endpoint det kan kontaktes på. Fordelings-komponenten afgør samtidig om payload er teknisk valid, dvs. uden fejl i meddelelsesformat. Har afsendersystemet valgt proaktivt at kalde fordelingskomponentens opslagsservice (UC-05) vil input udgøres af et specifikt system-id og dermed ikke KLE og handlingsfacet. Dette system-id vil danne basis for fordelingskomponentens fordelingslogik. Såfremt et entydigt modtager-system ikke kan afgøres på basis af det tilsendte metadata, eller anmodningen ikke er teknisk valid, kommunikeres en fejl-meddelelse tilbage til afsender-systemet. Da afsender-systemer har mulighed for at implementere et mønster, hvor de proaktivt forespørger på modtager-systemer inden en faktisk anmodning afsendes, forventes denne type fejlbeskeder at høre til sjældenhederne. Afsender-systemet modtager den tekniske fejl og har ansvaret for at foretage de nødvendige korrektioner. Dette vil lede til oprettelse af en ny anmodning. KOMBIT A/S Halfdansgade København S CVR Side 19 af 60

20 Såfremt ét modtager-system kan identificeres og anmodningen er teknisk valid, kommunikerer fordelingskomponenten en indledende kvittering tilbage til afsendersystemet. Denne kvittering vil indeholde transaktions-id et, der vil følge transaktio- 7 nen på tværs af systemer. Denne aktivitet er det første af tre hand-shakes mellem fordelingskomponenten og afsender-systemet. Afsender-systemet modtager en indledende kvittering på anmodningen, samt transaktions-id et for det videre forløb. Dette tillader afsender-systemet at matche den 8 indledende kvittering med den oprindelige anmodning. Fordelingskomponenten distribuerer journalnotatet til det relevante modtagersystem, identificeret i aktivitet 4. Transaktions-ID et medsendes. 9 Fordelingskomponenten forventes smidigt at kunne håndtere en situation hvor en indledende kvittering er sendt til afsender-systemet (8), men hvor modtagersystemet, der skal modtage anmodningen (9/10) ikke svarer, og vice versa. 10 Modtager-systemet modtager anmodningen om oprettelse af journalnotat. Modtager-systemet kvitterer for modtagelse af anmodningen til fordelingskomponenten Fordelingskomponenten modtager kvittering på modtagelse fra modtager-systemet. Fordelingskomponenten distribuerer kvittering for modtagelse til afsender-systemet. 13 Dette er andet hand-shake mellem fordelingskomponenten og afsender-systemet. Afsender-systemet modtager kvittering for modtagelse. Afsender-systemet kan nu 14 betragte anmodningen som modtaget i modtager-systemet, men endnu ikke forretningsmæssigt behandlet. Modtager-systemet behandler anmodningen om oprettelse af journalnotat. Denne 15 behandling kan være manuel og kan principielt strække sig over flere dage. Modtager-systemets behandling af anmodningen er afsluttet og har ledt til en accept 16 eller afvisning. Modtager-systemet kommunikerer denne afgørelse til fordelingskomponenten. Fordelingskomponenten modtager accept/afvisning (den forretningsmæssige kvittering) på anmodningen om oprettelse af journalnotat. 17 Fordelingskomponenten kommunikerer den forretningsmæssige kvittering videre til 18 afsender-systemet. Dette er tredje og sidste hand-shake mellem fordelingskomponenten og afsender-systemet. Afsender-systemet modtager den forretningsmæssige kvittering, der repræsenterer den endelige accept eller afvisning på afsender-systemets oprindelige anmodning. Såfremt modtager-systemet har accepteret, kan afsender-systemet slette den midlertidige lagring af journalnotatet. Såfremt modtager-systemet har afvist anmodningen, må den oprindelige anmoder i afsender-systemet foretage evt. nødvendige 19 korrektioner. Afsender-systemet implementerer hvis det ønskes en time-out i forhold til modtagelse af forretningsmæssige kvitteringer, for at imødegå lange behandlingstider. KOMBIT A/S Halfdansgade København S CVR Side 20 af 60

21 1.9.4 UC-02: Anmodning om oprettelse af journalnotat uden eksisterende sag Navn Formål UC-02: Anmodning om oprettelse af journalnotat uden eksisterende sag Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et journalnotat, hos et modtager-system. Anmodningen er uden reference til eksisterende sager. Afhængig af det valgte KLE nummer og den pågældende kommunes opsætning af Klassifikation og Organisation, kan en anmodning om oprettelse af journalnotat lede til flere, separate anmodninger i flere modtager-systemer. Efter modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af journalnotatet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Aktører Frekvens Indgangsbetingelser Udgangstilstand Afsender-system Modtager-system Fordelingskomponent Støttesystemet Organisation Hver gang et afsender-system har behov for at afhænde et journalnotat til et modtager-system. En bruger har i afsender-systemets brugergrænseflade identificeret et behov for oprettelse af et journalnotat. Modtager-systemet har accepteret eller afvist anmodningen om oprettelse af journalnotat. Hovedforløb Aktivitet Aktøren Brugeren opretter i afsender-systemets brugergrænseflade et journalnotat og identificerer det metadata, der skal tillade fordelings-komponenten at identificere det relevante modtager-system. 1 Brugeren kan vælge at markere om sagsparten skal fritages for tvungen digital selvbetjening eller en tidligere fritagelse skal tilmeldes igen. 1.1 Da brugeren ikke i afsender-systemets brugergrænseflade kan finde en eller flere repræsentative sager, at oprette journalnotatet i relation til, indtaster brugeren i stedet et generelt KLE emneområde og eventuelt en handlingsfacet, som journalnotatet skal oprettes for. 1.2 For at støtte brugeren i identifikationen af relevant it-system, foretager afsendersystemet proaktivt et kald til fordelingskomponentens opslags-service (use case UC-05). Som input medtager afsender-systemet det respektive KLE-nummer KOMBIT A/S Halfdansgade København S CVR Side 21 af 60

22 2 3 4 samt kommuneidentifikation og modtager en liste over relevante IT-systemer og deres systemidentifikation fra støttesystemet Organisation, der modsvarer de pågældende kriterier. 1.3 Såfremt der er mere end ét relevant modtager-system, vælger brugeren det relevante IT-system i en liste populeret på basis af svaret fra fordelingskomponentens opslags-service. Er der kun én mulighed skal brugeren ikke foretage sig yderligere. Er listen tom, må det valgte KLE nummer revideres. 1.4 Afsender-systemet forbereder anmodningen ved at berige denne med følgende metadata: Parts-identifikation (fra Sags- og Dokumentindekset) KLE-identifikation (fra Sags- og Dokumentindekset) Handlingsfacet (hvis relevant) System-identifikation (som returneret fra opslags-servicen i 1.2) 1.5 Brugeren udfylder journalnotatets indhold og initierer anmodningen i afsendersystemet. Afsender-systemet kalder fordelings-komponenten med de identificerede metadata. Payload udgøres af det pågældende journalnotat (og resten af strukturen fra OIO sag standarden). 2.1 Afsender-systemet beriger anmodningen med yderligere data i relation til: Bruger-identifikation Kommune-identifikation Afsender-systemets system-identifikation UUID (der kommer til at udgøre anmodningens transaktionsid) 2.2 Afsender-systemet samler denne information og journalnotatet i OIO Sag XML strukturen og kalder fordelingskomponentens service. XML strukturen vil medtage et dummy sagsobjekt, da der ikke er en eksisterende sag at oprette notatet på. Fordelingskomponenten modtager kaldet fra afsender-systemet. Det medsendte UUID lagres som transaktions-id og medtages i alle fremtidige kald til afsender- og modtager-systemet. Såfremt det anses fordelagtigt kan fordelingskomponenten tillige lagre et eget transaktions-id. På basis af de medsendte metadata (KLE-nummer, Kommune-identifikation, System-identifikation), afgør fordelings-komponenten ved opslag i støttesystemet Organisation, om et entydigt identificerbart modtager-system kan identificeres og i så fald, hvilket endpoint det kan kontaktes på. Fordelings-komponenten afgør samtidig om payload er teknisk valid, dvs. uden fejl i meddelelsesformat. Use casen fortsætter som UC-01 frem til aktivitet 19. KOMBIT A/S Halfdansgade København S CVR Side 22 af 60

23 1.9.5 Generelt flow-diagram for anmodning om oprettelse af dokumenter KOMBIT A/S Halfdansgade København S CVR Side 23 af 60

24 1.9.6 UC-03: Anmodning om oprettelse af dokument på én eksisterende sag Navn Formål UC-03: Anmodning om oprettelse af dokument på én eksisterende sag Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et dokument hos et modtager-system. Afsender-systemet har forinden placeret det pågældende dokument i et repository, der benyttes af fordelingskomponenten, hvor det relevante modtager-system senere kan afhente dokumentet. Anmodningen drejer sig om en specifik, eksisterende sag. Efter modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af dokumentet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Aktører Frekvens Afsender-system Modtager-system Fordelings-komponent Støttesystemer SFTP på Serviceplatformen (eller andet fordelingskomponent-specifikt repository) Hver gang et afsender-system har behov for at afhænde et dokument til et modtager-system. Indgangsbetingelser En bruger har i afsender-systemets brugergrænseflade markeret en eksisterende sag, som denne ønsker at associere et dokument med. Udgangstilstand Modtager-systemet har accepteret eller afvist anmodningen om oprettelse af dokumentet. Hovedforløb Aktivitet 1 Aktøren Brugeren identificerer i afsender-systemets brugergrænseflade det metadata, der skal tillade fordelingskomponenten at identificere det modtager-system, der skal modtage anmodningen. I praksis vælger brugeren en specifik sag, som et dokument skal associeres med. Brugeren kan vælge at markere om sagsparten skal fritages for tvungen digital selvbetjening eller en tidligere fritagelse skal tilmeldes igen. 1.1 Brugeren vælger/markerer i afsender-systemets brugergrænseflade, den specifikke sag, som brugeren ønsker at tilknytte et dokument til. KOMBIT A/S Halfdansgade København S CVR Side 24 af 60

25 2 1.2 Afsender-systemet kalder proaktivt den af fordelingskomponenten udstillede opslags-service (UC-05) med sagens KLE-nummer, handlingsfacet og Kommune-identifikation som input. Servicen returnerer det IT-system, der er opsat til at behandle fagområdet, og dets system-identifikation, som det er identificeret i støttesystemet Organisation. Såfremt der er konfigureret mere end ét IT-system for det pågældende fagområde (KLE-nummer), returneres den fulde liste af systemer. Afsender-systemet lader brugeren udvælge det specifikke system, dokumentet skal sendes til. 1.3 Afsender-systemet forbereder anmodningen ved at berige denne med følgende metadata: Sags-identifikation (fra Sags- og Dokumentindekset) Parts-identifikation (fra Sags- og Dokumentindekset) KLE-identifikation (fra Sags- og Dokumentindekset) System-identifikation (som returneret fra opslags-servicen i 1.2) 1.4 Brugeren uploader lokalt (i afsender-systemet) det pågældende dokument og initierer anmodningen i afsender-systemet. Afsender-systemet placerer det relevante dokument på Serviceplatformens SFTP, eller en anden fælles repository/lagringsmekanisme anvendt af fordelingskomponenten. 3 Serviceplatformens SFTP modtager filen og genererer en fil-reference. 4 Serviceplatformens SFTP kvitterer for modtagelse hos afsender-systemet og medsender en fil-reference, der angiver hvor filen kan hentes. 5 Afsender-systemet modtager kvittering fra SFTP, samt fil-reference Efter succesfuld upload kalder Afsender-systemet fordelings-komponenten med de identificerede metadata. Payload udgøres af XML-strukturen fra OIO sag standarden, samt fil-referencen. 6.1 Afsender-systemet kombinerer metadata fra trin 1.3, med yderligere data til brug for anmodningen: Bruger-identifikation (id på den bruger, der opretter dokumentet) Kommune-identifikation Afsender-systemets system-identifikation (eks. SAPAs specifikke identifikation) UUID (der kommer til at udgøre anmodningens transaktions-id) Fil-reference til placering, hvor modtager-systemet kan afhente filen 6.2 Afsender-systemet samler denne information i OIO Sag XML strukturen og kalder fordelingskomponentens service. Fordelingskomponenten modtager kaldet fra afsender-systemet. Det medsendte UUID lagres som transaktions-id og medtages i alle fremtidige kald til afsender- og modtager-systemet. Såfremt det anses fordelagtigt kan fordelingskomponenten tillige lagre et eget transaktions-id. På basis af det medsendte metadata (KLE-nummer, handlingsfacet, Kommuneidentifikation, System-identifikation), afgør fordelings-komponenten ved opslag i støttesystemet Organisation, om et entydigt identificerbart modtager-system kan identificeres og i så fald, hvilket endpoint det kan kontaktes på. Fordelings- KOMBIT A/S Halfdansgade København S CVR Side 25 af 60

26 komponenten afgør samtidig om payload er teknisk valid, dvs. uden fejl i meddelelsesformat. Har afsendersystemet valgt proaktivt at kalde fordelingskomponentens opslagsservice (UC-05) vil input udgøres af et specifikt system-id og dermed ikke KLE og handlingsfacet. Dette system-id vil danne basis for fordelingskomponentens fordelingslogik. Såfremt et entydigt modtager-system ikke kan afgøres på basis af det tilsendte metadata, eller anmodningen ikke er teknisk valid, kommunikeres en fejl-meddelelse tilbage til afsender-systemet. 9 Da afsender-systemer har mulighed for at implementere et mønster, hvor de proaktivt forespørger på modtager-systemer inden en faktisk anmodning afsendes, forventes denne type fejlbeskeder at høre til sjældenhederne. Afsender-systemet modtager den tekniske fejl og har ansvaret for at foretage de 10 nødvendige korrektioner. Dette vil lede til oprettelse af en ny anmodning. Såfremt ét modtager-system kan identificeres og anmodningen er teknisk valid, kommunikerer fordelingskomponenten en indledende kvittering tilbage til afsendersystemet. Denne kvittering vil indeholde transaktions-id et, der vil følge transaktio- 11 nen på tværs af systemer. Denne aktivitet er det første af tre hand-shakes mellem fordelingskomponenten og afsender-systemet. Afsender-systemet modtager en indledende kvittering på anmodningen, samt transaktions-id et for det videre forløb. Dette tillader afsender-systemet at matche den 12 indledende kvittering med den oprindelige anmodning. Fordelingskomponenten distribuerer anmodningen til det relevante modtagersystem, identificeret i aktivitet 8. Transaktions-ID et medsendes Modtager-systemet modtager anmodningen om oprettelse af journalnotat. Modtager-systemet afhenter dokumentet på SFTP serveren/fordelingskomponentens repository Dokumentet slettes efter afhentning. Efter afhentning af dokumentet, kvitterer modtager-systemet for modtagelse af anmodningen til fordelingskomponenten Fordelingskomponenten modtager kvittering på modtagelse fra modtager-systemet. Fordelingskomponenten distribuerer kvittering for modtagelse til afsender-systemet. 19 Dette er andet hand-shake mellem fordelingskomponenten og afsender-systemet. Afsender-systemet modtager kvittering for modtagelse. Afsender-systemet kan nu 20 betragte anmodningen som modtaget i modtager-systemet, men endnu ikke forretningsmæssigt behandlet. Modtager-systemet behandler anmodningen om oprettelse af dokument. Denne 21 behandling kan være manuel og kan principielt strække sig over flere dage. Modtager-systemets behandling af anmodningen er afsluttet og har ledt til en accept eller afvisning. Modtager-systemet kommunikerer denne afgørelse til forde- 22 lingskomponenten. Fordelingskomponenten modtager accept/afvisning (den forretningsmæssige kvittering) på anmodningen om oprettelse af 23 dokument. KOMBIT A/S Halfdansgade København S CVR Side 26 af 60

27 24 25 Fordelingskomponenten kommunikerer den forretningsmæssige kvittering videre til afsender-systemet. Dette er tredje og sidste hand-shake mellem fordelingskomponenten og afsender-systemet. Afsender-systemet modtager den forretningsmæssige kvittering, der repræsenterer den endelige accept eller afvisning på afsender-systemets oprindelige anmodning. Såfremt modtager-systemet har accepteret, kan afsender-systemet slette den midlertidige lagring af dokumentet. Såfremt modtager-systemet har afvist anmodningen, må den oprindelige anmoder i afsender-systemet foretage evt. nødvendige korrektioner. Afsender-systemet implementerer, hvis det ønskes, en time-out i forhold til modtagelse af forretningsmæssige kvitteringer, for at imødegå lange behandlingstider. KOMBIT A/S Halfdansgade København S CVR Side 27 af 60

28 1.9.7 UC-04: Anmodning om oprettelse af dokument uden eksisterende sag Navn Formål UC-04: Anmodning om oprettelse af dokument uden eksisterende sag Denne use case beskriver, hvordan et afsender-system anmoder om oprettelse af et dokument hos et modtager-system. Afsender-systemet har forinden placeret det pågældende dokument i et repository, der benyttes af fordelingskomponenten, hvor det relevante modtager-system senere kan afhente dokumentet. Anmodningen er uden reference til en eksisterende sag. Efter modtagelse overtager fordelings-komponenten den generelle styring af processen (transaktionsspor, kvitteringer, genfremsendelse) med henblik på transport af dokumentet til det korrekte, modtagende fagsystem. Use casen kan have to udkom: Modtager-systemets accept eller afvisning af anmodningen. Aktører Frekvens Afsender-system Modtager-system Fordelings-komponent Støttesystemer SFTP på Serviceplatformen (eller andet fordelingskomponent-specifikt repository) Hver gang et afsender-system har behov for at afhænde et dokument til et modtager-system. Indgangsbetingelser En bruger har i afsender-systemets brugergrænseflade identificeret et behov for oprettelse af et dokument. Udgangstilstand Modtager-systemet har accepteret eller afvist anmodningen om oprettelse af dokumentet. Hovedforløb Aktivitet Aktøren Brugeren opretter i afsender-systemets brugergrænseflade en anmodning om oprettelse af et dokument og identificerer det metadata, der skal tillade fordelings-komponenten at identificere det relevante modtager-system. 1 Brugeren kan vælge at markere om sagsparten skal fritages for tvungen digital selvbetjening eller en tidligere fritagelse skal tilmeldes igen. 1.1 Da brugeren ikke i afsender-systemets brugergrænseflade kan finde en eller flere repræsentative sager, at oprette dokumentet i relation til, indtaster brugeren i stedet et generelt KLE emneområde, som dokumentet skal oprettes for. KOMBIT A/S Halfdansgade København S CVR Side 28 af 60

29 2 1.2 For at støtte brugeren i identifikationen af relevant KLE-nummer, foretager afsender-systemet proaktivt et kald til fordelingskomponentens opslags-service (use case UC-05). Som input medtager afsender-systemet det respektive KLE-nummer, handlingsfacet (hvis relevant) samt kommuneidentifikation og modtager en liste over relevante IT-systemer og deres systemidentifikation fra støttesystemet Organisation, der modsvarer de pågældende kriterier. 1.3 Såfremt der er mere end ét relevant modtager-system, vælger brugeren det relevante IT-system i en liste populeret på basis af svaret fra fordelingskomponentens opslags-service. Er der kun én mulighed skal brugeren ikke foretage sig yderligere. Er listen tom, må det valgte KLE nummer revideres. 1.4 Afsender-systemet forbereder anmodningen ved at berige denne med følgende metadata: Parts-identifikation KLE-identifikation System-identifikation (som returneret fra opslags-servicen i 1.2) 1.5 Brugeren uploader lokalt (i afsender-systemet) det pågældende dokument og initierer anmodningen i afsender-systemet. Afsender-systemet placerer det relevante dokument på Serviceplatformens SFTP, eller en anden fælles repository/lagringsmekanisme anvendt af fordelingskomponenten. 3 Serviceplatformens SFTP modtager filen og genererer en fil-reference. 4 Serviceplatformens SFTP kvitterer for modtagelse hos afsender-systemet og medsender en fil-reference, der angiver hvor filen kan hentes. 5 Afsender-systemet modtager kvittering fra SFTP, samt fil-reference. 6 Efter succesfuld upload kalder Afsender-systemet fordelings-komponenten med de identificerede metadata. Payload udgøres af XML-strukturen fra OIO sag standarden, samt fil-referencen. 6.1 Afsender-systemet kombinerer metadata fra trin 1.3, med yderligere data til brug for anmodningen: Bruger-identifikation (id på den bruger, der opretter dokumentet) Kommune-identifikation Afsender-systemets system-identifikation (eks. SAPAs specifikke identifikation) UUID (der kommer til at udgøre anmodningens transaktions-id) Fil-reference til placering, hvor modtager-systemet kan afhente filen 6.2 Afsender-systemet samler denne information i OIO Sag XML strukturen og kalder fordelingskomponentens service. Use casen fortsætter som UC-03 frem til aktivitet 25. KOMBIT A/S Halfdansgade København S CVR Side 29 af 60

30 1.9.8 UC-05: Opslag af tilgængelige IT-systemer i støttesystemer på basis af KLE nummer Navn Formål UC-05: Opslag af tilgængelige IT-systemer i støttesystemer på basis af KLE nummer Fordelings-komponenten behandler forespørgslen via opslag i støttesystemet Organisation og returnerer et svar, der indeholder IT-systemernes identifikation i Organisation. Anvender-systemerne kan benytte denne funktionalitet, når de vil støtte deres brugere ved oprettelse af journalnotater på eksisterende sager og hvor der ikke eksisterer en sag i forvejen. Aktører Frekvens Afsender-system Fordelingskomponent Støttesystemet Organisation Hver gang et afsender-system ønsker at støtte en bruger i oprettelse af et journalnotat eller dokument Indgangsbetingelser En bruger har i afsender-systemets brugergrænseflade identificeret et KLEnummer (helt eller delvist), som denne ønsker at oprette et journalnotat/dokument på. Udgangstilstand Fordelingskomponentens opslags-service returnerer en liste af tilgængelige IT-systemer, samt deres system-identifikation, som de fremgår i Organisation. Listen kan være tom. Hovedforløb Aktivitet 1 2 Aktøren Afsender-systemet foretager et kald til fordelingskomponentens opslagsservice. Som input sender afsender-systemet: Det respektive KLE-nummer Den respektive handlingsfacet, hvis kendt Kommune-identifikation Afsender-systemets system-identifikation Servicen skal understøtte input på forskellige niveauer af KLE hierarkiet. Den returnerede liste vil således være større eller mindre afhængig af hvor specifikt KLE nummeret er angivet. Fordelingskomponenten modtager kaldet fra afsender-systemet, foretager det relevante opslag i støttesystemet Klassifikation og returnerer en liste over fagsystemer, der ifølge kommunens konfiguration, er sat op til at varetage den specifikke kombination af emneområde og handlingsfacet. Output inkluderer det pågældende IT-systems identifikation fra Organisation, såvel som en generel beskrivelse. KOMBIT A/S Halfdansgade København S CVR Side 30 af 60

31 3 Afsender-systemet modtager servicens svar og kan bruge det til at støtte brugerens valg. KOMBIT A/S Halfdansgade København S CVR Side 31 af 60

32 1.9.9 UC-06: Opslag af tilgængeligt IT-system i støttesystemer på basis af KLE nummer Navn Formål UC-06: Opslag af tilgængeligt IT-system i støttesystemer på basis af KLE nummer Denne use case beskriver, hvordan et afsender-system forespørger på tilstedeværelsen af et specifikt kommunalt IT-system og dets evne til at modtage journalnotater. Fordelings-komponenten behandler forespørgslen via opslag i støttesystemet Organisation og returnerer et svar (true/false). Afsender-systemerne kan benytte denne funktionalitet, når de ønsker at give deres brugere en visuel indikation af, om der kan oprettes et journalnotat for en given sag (og dermed it-system) i brugergrænsefladen. Denne use case er en afart af det opslag, der foretages i UC-05. I modsætning til UC-05 er formålet her imidlertid udelukkende at afgøre om et specifikt modtager-system er konfigureret til at modtage journalnotater. Aktører Frekvens Afsender-system Fordelingskomponent Støttesystemet Organisation Hver gang et afsender-system har behov for berige brugergrænsefladen med information om hvilke sager, der kan oprettes journalnotater på. Indgangsbetingelser Afsender-systemet har identificeret de nødvendige input-parametre, der skal bruges af fordelingskomponentens opslags-service. Udgangstilstand Afsender-systemet modtager servicens svar og kan bruge det til at indikere up-front i brugergrænsefladen, om der kan oprettes et journalnotat på en given sag, eller ej. Hovedforløb Aktivitet 1 Aktøren Afsender-systemet foretager et kald til fordelingskomponentens opslags-service. Som input sender afsender-systemet: Det specifikke system-id (som det fremgår af Sags- og Dokumentindekset) Kommune-identifikation Afsender-systemets system-identifikation KOMBIT A/S Halfdansgade København S CVR Side 32 af 60

33 2 3 Note Fordelingskomponenten modtager kaldet fra afsender-systemet, foretager det relevante opslag i støttesystemet Organisation og returnerer true såfremt: Det specifikke fagsystem (system-id) er konfigureret til brug med fordelingskomponenten Fordelingskomponenten forventer UUID er fra Organisation. Såfremt det fremsendte system-id ikke kan findes her og ikke er konfigureret til brug med fordelingskomponenten, sendes en fejlmeddelelse til afsendersystemet. Afsender-systemet modtager servicens svar og kan bruge det til at indikere upfront i brugergrænsefladen om der kan oprettes et journalnotat på en given sag, eller ej. Det kan overvejes om denne service skal implementeres som en liste-service. KOMBIT A/S Halfdansgade København S CVR Side 33 af 60

34 2 Kontekst for integrationsparter 2.1 Kontekst for KY Lovhjemmel og forvaltningsmæssigt formål [Udfyldes med oplysninger om hvilke(n) lovhjemmel der findes for systemets anvendelse af servicen] Det anførte hjemmelsgrundlag er bestemt af det enkelte og relevante fagprojekt i KOMBIT på bestillingstidspunktet. Det er fastsat på baggrund af en rimelig og dækkende analyse. Henvisningen til hjemmelsgrundlaget bliver ikke vedligeholdt, hvorfor KOMBIT naturligvis ikke kan indestå for, at denne henvisnings indehold og retsvirkning til alle tider vil være korrekt. KOMBIT skal derfor understrege, at læseren af dette dokument udelukkende skal læse hjemmelsgrundlaget som en orientering. Det forvaltningsmæssige formål er at overføre journalnotater og dokumenter til fagsystemer. [Udfyldes med en kortfattet beskrivelse af de forvaltningsmæssige formål med anvendelse af servicen.] KY som modtager ikke har specifikke krav til lovhjemmel i forbindelse med brug af snitfladen. KY forventer at afsenderen håndterer eventuelle lovmæssige afklaringer Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart [Udfyldes med oplysninger om krav til kapacitet og service fx forventninger til antal transaktioner og volumen, oplysninger om spidsbelastninger, særlige krav til oppetid] KY forventer at kunne modtage omkring 2,3-3 mio. journalnotater og dokumenter via denne snitflade Specifikke forsætninger for tilslutning af denne integrationspart Ingen identificeret. 2.2 Kontekst for KSD Lovhjemmel og forvaltningsmæssigt formål [Udfyldes med oplysninger om hvilke(n) lovhjemmel der findes for systemets anvendelse af servicen] Det anførte hjemmelsgrundlag er bestemt af det enkelte og relevante fagprojekt i KOMBIT på bestillingstidspunktet. Det er fastsat på baggrund af en rimelig og dækkende analyse. Henvisningen til hjemmelsgrundlaget bliver ikke vedligeholdt, hvorfor KOMBIT naturligvis ikke kan indestå for, at denne henvisnings indehold og retsvirkning til alle tider vil være korrekt. KOMBIT skal derfor understrege, at læseren af dette dokument udelukkende skal læse hjemmelsgrundlaget som en orientering. Det forvaltningsmæssige formål er at overføre journalnotater og dokumenter til fagsystemer. KOMBIT A/S Halfdansgade København S CVR Side 34 af 60

35 [Udfyldes med en kortfattet beskrivelse af de forvaltningsmæssige formål med anvendelse af servicen.] KSD som modtager ikke har specifikke krav til lovhjemmel i forbindelse med brug af snitfladen. KSD forventer at afsenderen håndterer eventuelle lovmæssige afklaringer Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart [Udfyldes med oplysninger om krav til kapacitet og service fx forventninger til antal transaktioner og volumen, oplysninger om spidsbelastninger, særlige krav til oppetid] KSD har ikke specifikke krav til mængder Dette bestemmes af afsenderen Specifikke forsætninger for tilslutning af denne integrationspart Ingen identificeret. KOMBIT A/S Halfdansgade København S CVR Side 35 af 60

36 3 Specifikation for integrationsparter 3.1 Specifikation af endpoints for Modtagersystemer Integrationen benyttes til at overføre objekter til et modtagersystem og formidle asynkrone kvitteringer retur til afsender Overordnet forretningslogik Modtagersystemet udstiller en service (EP_FS1) til at modtage objekterne, og Serviceplatformen udstiller en service (EP_FS2) til at modtage kvitteringer Oversigt over endpoints ID Navn EP_FS1 EP_FS2 FordelingsobjektModtag FordelingskvitteringAfsend EP_FS2 har en generel header InvocationContext De tekniske detaljer er beskrevet på Serviceplatformen, ( hvor der også ligger vejledning til udviklere, samt demoprojekter.] Beskrivelse af endpoint EP_FS1 - FordelingsobjektModtag Transportspecifikation Serviceudstiller Modtagersystemerne (fagsystemerne) er serviceudstiller Serviceanvender Serviceplatformen er serviceanvender Teknologisk understøttelse Snitfladen er implementeret som en synkron SOAP webservice Teknisk endpoint [Udfyldes med teknisk endpoint] Følgende specificerer endpoint-oplysninger for produktionsmiljø og testmiljø. Miljø: Produktion URI til WSDL Endpoint navn [WSDL] Se DistributionServiceModtager.wsdl [Afklaring/KDF information skal hentes fra modtagersystemerne] KOMBIT A/S Halfdansgade København S CVR Side 36 af 60

37 Endpoint IP [Afklaring/KDF information skal hentes fra afsendersystemerne] Miljø: Test URI til WSDL Endpoint navn Endpoint IP [WSDL] Se DistributionServiceModtager.wsdl [Afklaring/KDF information skal hentes fra modtagersystemerne] [Afklaring/KDF information skal hentes fra afsendersystemerne] Teknisk retning for udveksling Serviceplatformen kalder service FordelingsobjektModtag på et fagsystem Dataretning for udveksling Serviceplatformen videresender journalpost eller dokument modtaget fra afsender til modtagerfagsystemet Service invokation / Triggers Kommunikation initieres af, at Serviceplatformen har modtaget et dokument eller en journalpost til videresendelse med service FordelingsobjoktAfsend (se SF 2720) Dataspecifikation Forklaring til elementbeskrivelser De enkelte elementer listes i den orden de optræder i beskeden. Der angives for hvert element følgende information: Niv Niveau i beskeden (1 er højeste). Et lavere niveau angiver at der er tale om underelementer til det element ovenfor der har et højere niveau Feltnavn Kard Værdisæt Navnet på feltet i XML Kardinalitet Hvor mange gange kan elementet optræde (0:1,1,0:n,1:n) Krav til formatet af feltets indhold. - angiver at det er en gruppe Betegnelse Beskrivelse af indholdet Generelle egenskaber for overførselsbesked Overførselsidentifikation Den besked der overføres via servicekaldet ( anmodning ) kan opdeles i to dele: A. Generelle attributter fælles for alle typer objekter ( DistributionContext ) B. Det overførte objekt ( DistributionObjekt ) Dette afsnit beskriver beskedens generelle attributter (Distribution context) Definition af DistributionContext udgør: KOMBIT A/S Halfdansgade København S CVR Side 37 af 60

38 Niv Feltnavn Kard Værdisæt Betegnelse 1 DistributionContext 1 - Udgør kuvert til styring af routing af objektet og den efterfølgende asynkrone kvittering 2 AnvenderTransaktionsID 1 UUID Unik identifikation på denne specifikke overførsel. Benyttes til at koordinere asynkrone svar i anvendersystemet. Ved levering af asynkron kvittering skal denne værdi returneres uændret 2 DistributionTransaktionsID 0..1 UUID Unik identifikation tildelt af distributionskomponenten. Den anvendes internt i fordelingskomponenten til routing. Værdien tildeles af fordelingskomponenten, og skal derfor ikke udfyldes i kaldet ved afsendelse. Ved asynkron kvittering skal denne værdi returneres uændret 2 AfsendendeMyndighed 1 8 cifret tal CVR-nummer for afsender myndigheden. Myndigheden skal ved afsendelse være den samme som den der angives i InvocationContext 2 RoutingMyndighed 1 8 cifret tal CVR-nummer for modtager myndighed Bemærk at denne kan afvige fra Afsendende- Myndighed ovenfor. I version 1 af fordelingskomponenten vil afsendelsen blive afvist med en fejl, såfremt disse er forskellige 2 RoutingEmneFacet 1 Tekst KLE Emnefacet (nn.nn.nn) Benyttes til at udpege modtagersystemet 2 RoutingHandlingFacet 0:1 Tekst KLE Handlingsfacet (xn) Yderligere specifikation til brug for routing 2 RoutingModtagerAktoer 0:1 UUID IT-System-aktør (Relation til organisation) Hvis denne angives, har det præcedens over KLE 2 DokumentFilnavn 0:1 Tekst Udgør navnet på den fil på FTP-serveren der indeholder den binære information til at kunne producere dokument image (f.eks. pdf eller doc) Pt. understøttes kun en fil, men det skal være muligt at udvide med flere filer senere (Kard. 0:n) Strukturen i et modtaget objekt ser således ud: KOMBIT A/S Halfdansgade København S CVR Side 38 af 60

39 Transportkvittering Alle services returnerer et fast responsestruktur med status for den tekniske validering af beskedens indhold. Strukturen har følgende indhold: Niv Feltnavn Kard Værdisæt Betegnelse 1 TransportKvittering 2 TransportValideringKode 1 Ok Advarsel Fejl Angiver resultatet af valideringen. Ved Fejl er beskeden ikke behandlet, og må derfor genfremsendes når problemet er løst. 2 Begrundelse 0:1 Tekst Dette er en tekst fra modtageren, der forklarer hvorfor et objekt er afvist. 2 FejlListe 0:n - Lister alle de valideringsfejl der er identificeret. Benyttes kun ved Advarsel eller Fejl. 3 FejlKode 1 Tekst Entydig identifikation af fejlen 3 FejlTekst 1 Tekst Beskrivelse af fejlen OverførselsobjektIndhold Dette afsnit beskriver indholdet af de enkelte objekttyper. Indholdet inkluderes i beskeden under gruppen ObjektIndhold i DistributionObjekt. KOMBIT A/S Halfdansgade København S CVR Side 39 af 60