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 [email protected]. 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

40 Niv Feltnavn Kard Værdisæt Betegnelse 1 DistributionObjekt 1 - Indeholder det objekt der overføres 2 Objekttype 1 Journalpost Dokument Angiver den type objekt der medsendes i kuvertens indhold. Pt. er kun to defineret, men det skal være muligt senere at udvide med nye objekttyper 2 ObjektIndhold 1 - Indholdet af objektet. Strukturen er defineret i de næste afsnit Journalpost Denne objekttype definition benyttes hvis ObjektType i DistributionObjekt indeholder Journalpost. Informationen nedenfor relateres til OIO-Sag version 1.2. Detaljer omkring brug, definitioner mv. kan udledes af standarden. Felter markeret med kursiv er udvidelser til standarden KOMBIT A/S Halfdansgade København S CVR Side 40 af 60

41 Fordelingskomponenten Journalposter DistributionJournalpost +ID : string +ObjektType : string SagForslag PartAngivelse Eksterne objekter Sag +ID : string (Part) +Objekttype : string +ReferenceID : string Registrering +FraTidspunkt : string +LivscyklusKode : string -ImportTidspunkt : string 1 1 RelationListe BrugerRef RegistreringItSystem BrugerAktør +ID : string ItSystemAktør +ID : string Virkning -FraTidspunkt : string -TilTidspunkt : string -NoteTekst : string Virkning 1..n Journalpost +Indeks : string +Rolle : string Dokument 0..1 (Dokument) +Objekttype : string +ReferenceID : string (Anvendes ikke) (Anvendes ikke) 0..1 JournalpostAttributter -Dokumenttitel : string 0..1 OffentlighedUndtaget +TitelAlternativTekst : string +HjemmelTekst : string JournalnotatAttributter -Titel : string +Notat : string -Format : string 1 KOMBIT A/S Halfdansgade København S CVR Side 41 af 60

42 Niv Feltnavn Kard Værdisæt Betegnelse 1 DistributionJournalPost - Struktur til at kommunikere Journalposter 2 ID 1 UUID Unik nøgle for journalpost objektet 2 EmneFacetForslag 1 Tekst KLE Emnefacet (nn.nn.nn) Benyttes af modtager til at identificere den sag der skal modtage Journalposten. Hvis SagForslag er udfyldt, udfyldes dette felt med den primære klassifikation fra sagen 2 HandlingFacetForslag 0:1 Tekst KLE Handlingsfacet (xn) Benyttes af modtager til at identificere den sag der skal modtage Journalposten. Hvis SagForslag er udfyldt, udfyldes dette felt med den primære handlingsklasse fra sagen 2 ObjektType 1 Journalpost Skal svare til indholdet af Kuvertens objekttype felt. Værdien er fast Journalpost for dette indhold 2 SagForslag 0:1 UUID Reference til den sag der er foreslået som destination for journalposten 2 PartAngivelse 0:1 - Parter dette notat omhandler. Hvis Sag- Forslag er angivet er parten ikke påkrævet. Er der intet SagForslag skal angives den part notatet vedrører 3 Objekttype 1 Person (CPR) Typen af part der relateres til Virksomhed (CVR) Organisation OrgEnhed OrgFunktion Interesse-faellesskab Bruger 3 ReferenceID 1 UUID/URN/Tekst Ekstern relation til parten (f.eks. CPR-nr) 2 Registrering 1 - Angiver den seneste registrering på det objekt der kommunikeres. Det objekt der afsendes fra skal være låst, så der ikke tilføjes flere registreringer efter dette kald. Pt. understøttes kun en registrering, men løsningen skal senere kunne udvides til at indeholde flere registreringer KOMBIT A/S Halfdansgade København S CVR Side 42 af 60

43 Niv Feltnavn Kard Værdisæt Betegnelse 3 FraTidspunkt 1 Timestamp Unikt tidspunkt for denne registrering. Benyttes til at identificere hvilken registrering der er gældende til et specifikt tidspunkt, og til at håndtere beskeder ude af sekvens 3 LivscyklusKode 1 Oprettet Fast værdi Oprettet 3 ImportTidspunkt 0:1 Timestamp Benyttes kun ved import (Udeladt her) 3 BrugerRef 0:1 UUID/URN Reference til organisation for den brugeraktør der har foretaget registreringen 3 RegistreringITSystem 1 UUID/URN Reference til organisation for den ITsystemaktør der har afgivet objektet (Bemærk at dette ikke altid er det samme som afsendersystemet) 3 RelationListe 1 - Der understøttes kun en relation/virkning 4 Journalpost 1:n - Der understøttes kun en journalpost, men der kan være flere virkninger. Hvis der er flere instanser her, valideres at der ikke er overlap på virkningerne. 5 Virkning 1 - Virkning angiver hvornår journalnotatet er validt. 6 FraTidspunkt 0:1 DateTime Det tidspunkt hvor notatet er gyldigt fra. Vil typisk være tidspunkt for modtagelse af notatet. Hvis udeladt, vil datoen være uendelig tilbage i tiden 6 TilTidspunkt 0:1 DataTime Det tidspunkt hvor notatet er gyldigt til. Hvis udeladt, vil notatet være evig gyldigt (Normalt) 6 Aktoer 1 UUID/URN Reference til organisation for den aktør der har defineret virkningen 6 AktoerType 1 Organisation OrganisationEnhed OrganisationFunktion Bruger ItSystem Interessefaellesskab Den type aktør i organisation, der er relateret ovenfor 6 NoteTekst 0:1 Tekst Dette er en tekst der kan benyttes til at forklare hvorfor virkningen er defineret 4 Indeks 1 Tekst Udfyldes med 1, da der kun kan sendes en journalpost 4 Rolle 1 Journalpost Rolle kan kun antage denne værdi her KOMBIT A/S Halfdansgade København S CVR Side 43 af 60

44 Niv Feltnavn Kard Værdisæt Betegnelse 4 Dokument 0:1 - Relation til dokument (Udelades her) 5 Objekttype 1 Dokument Denne reference er altid til et dokument objekt 5 ReferenceID 1 UUID/URN ID på det relaterede dokument 4 JournalpostAttributter 0:1 - Attributter knyttet til dokument (Udelades her) 5 Dokumenttitel 0:1 Tekst Overskrift for dokumentet 5 OffentlighedUndtaget 0:1 - Angiver følsomt dokument 6 TitelAlternativTekst 1 Tekst Alternativ overskrift til offentliggørelse 6 HjemmelTekst 1 Tekst Hjemmel for undtagelse fra offentligheden 5 JournalnotatAttributter 1 - Der skal altid inkluderes information omkring journalnotatet for denne type objekt 6 Titel 0:1 Tekst Overskrift for notatet 6 Notat 1 Tekst Indeholder selve Journalnotatteksten Dokument Denne objekttype definition benyttes hvis ObjektType i DistributionObjekt indeholder Dokument. Informationen nedenfor relateres til OIO-Dokument version 1.1, justeret med de generelle egenskaber for OIO-Sag version 1.2. Detaljer omkring brug, definitioner mv. kan udledes af standarden. Felter markeret med kursiv er udvidelser til standarden KOMBIT A/S Halfdansgade København S CVR Side 44 af 60

45 Fordelingskomponenten Dokumenter Eksterne objekter Dokument +ID : string +ObjektType : string SagForslag 0..1 Sag +ID : string Virkning -FraTidspunkt : string -TilTidspunkt : string -NoteTekst : string Registrering +FraTidspunkt : string +LivscyklusKode : string -ImportTidspunkt : string 1 BrugerRef RegistreringItSystem BrugerAktør +ID : string ItSystemAktør +ID : string Virkning Attributter +BrugervendtNoegleTekst : string +TitelTekst : string +BeskrivelseTekst : string +Dokumenttype : string +Retning : string +Brevdato : string -Fristdato : string -VersionIdentifikator : int -UnderversionIdentifikator : int -KassationskodeTekst : string n OffentlighedUndtaget +TitelAlternativTekst : string +HjemmelTekst : string 1..n Tilstand +Fremdrift : string Virkning -FraTidspunkt : string -NoteTekst : string VariantAttributter +VariantType : string -Produktion : bool -Offentliggørelse : bool -Arkivering : bool -DelvistScannet : bool 1 Virkning 1 RelationListe Variant +Rolle : string +Indeks : string 1 1..n Virkning DelAttributter +DelTekst : string -Indeks : int -Indhold : string -Filstoerrelse : int -MimeType : string -ScannerID : string -Lokation : string 0..n DokumentPart +Rolle : string +Indeks : string (Part) +Objekttype : string +ReferenceID : string Virkning Part Virkning -FraTidspunkt : string -TilTidspunkt : string -NoteTekst : string Virkning -FraTidspunkt : string -TilTidspunkt : string -NoteTekst : string 1 KOMBIT A/S Halfdansgade København S CVR Side 45 af 60

46 Niv Feltnavn Kard Værdisæt Betegnelse 1 DistributionDokument - Struktur til at kommunikere Dokumenter 2 ID 1 UUID Unik nøgle for dokument objektet 2 EmneFacetForslag 1 Tekst KLE Emnefacet (nn.nn.nn) Benyttes af modtager til at identificere den sag der skal modtage Dokumentet. Hvis SagForslag er udfyldt, udfyldes dette felt med den primære klassifikation fra sagen 2 HandlingFacetForslag 0:1 Tekst KLE Handlingsfacet (xn) Benyttes af modtager til at identificere den sag der skal modtage Dokumentet. Hvis SagForslag er udfyldt, udfyldes dette felt med den primære handlingsklasse fra sagen 2 ObjektType 1 Tekst Skal svare til indholdet af Kuvertens objekttype felt. Værdien er fast Dokument for dette indhold 2 SagForslag 0:1 UUID Reference til den sag der er foreslået tilknyttet dokumentet 2 Registrering 1 - Angiver den seneste registrering på det objekt der kommunikeres. Det objekt der afsendes fra skal være låst, så der ikke tilføjes flere registreringer efter dette kald. Pt. understøttes kun en registrering, men løsningen skal senere kunne udvides til at indeholde flere registreringer 3 FraTidspunkt 1 Timestamp Unikt tidspunkt for denne registrering. Benyttes til at identificere hvilken registrering der er gældende til et specifikt tidspunkt, og til at håndtere beskeder ude af sekvens 3 LivscyklusKode 1 Oprettet Fast værdi Oprettet 3 ImportTidspunkt 0:1 Timestamp Benyttes kun ved import (Udeladt her) 3 BrugerRef 0:1 UUID/URN Reference til organisation for den brugeraktør der har foretaget registreringen KOMBIT A/S Halfdansgade København S CVR Side 46 af 60

47 Niv Feltnavn Kard Værdisæt Betegnelse 3 RegistreringITSystem 1 UUID/URN Reference til organisation for den ITsystemaktør der har afgivet objektet (Bemærk at dette ikke altid er det samme som afsendersystemet) 3 Attributter 1:n - DokumentAttributter. Der kan eventuelt være flere virkninger for attributterne. Hvis der er flere instanser her, valideres at der ikke er overlap på virkningerne. 4 Virkning 1 - Virkning angiver hvornår attributterne er valide. 5 FraTidspunkt 0:1 DateTime Det tidspunkt hvor attributterne er gyldige fra. Vil typisk være tidspunkt for modtagelse af dokumentet. Hvis udeladt, vil datoen være uendelig tilbage i tiden 5 TilTidspunkt 0:1 DataTime Det tidspunkt hvor attributterne er gyldige til. Hvis udeladt, vil attributterne være evigt gyldige 5 Aktoer 1 UUID/URN Reference til organisation for den aktør der har defineret virkningen 5 AktoerType 1 Organisation OrganisationEnhed OrganisationFunktion Bruger ItSystem Interessefaellesskab Den type aktør i organisation, der er relateret ovenfor 5 NoteTekst 0:1 Tekst Dette er en tekst der kan benyttes til at forklare hvorfor virkningen er defineret 4 BrugervendtNoegleTekst 1 Tekst Entydig nøgle for dokumentet til præsentation 4 TitelTekst 1 Tekst Titel for dokumentet 4 BeskrivelseTekst 1 Tekst Beskrivelse af dokumentet 4 Dokumenttype 1 Faktura Brev Notat Rapport Dagsorden Referat Anden Typen af dokument KOMBIT A/S Halfdansgade København S CVR Side 47 af 60

48 Niv Feltnavn Kard Værdisæt Betegnelse 4 Retning 1 Indgaaende Udgaaende InterntInd InterntUd Internt Den retning dokumentet er kommunikeret i forhold til myndigheden/ enheden 4 Brevdato 1 Date Dato for udsendt brev/ dato modtaget 4 Fristdato 0:1 Date Den seneste dato svaret skal foreligge 4 OffentlighedUndtaget 0:1 - Angiver følsomt dokument 5 TitelAlternativTekst 1 Tekst Alternativ overskrift til offentliggørelse 5 HjemmelTekst 1 Tekst Hjemmel for undtagelse fra offentligheden 4 VersionIdentifikator 0:1 Integer 4 UnderversionIdentifikator 0:1 Integer 4 KassationskodeTekst 0:1 Tekst 3 Tilstand 1-4 Virkning 1 - Virkning angiver hvornår tilstanden er valid. 5 FraTidspunkt 0:1 DateTime Det tidspunkt hvor tilstanden er gyldig fra. Vil typisk være tidspunkt for modtagelse af notatet. Hvis udeladt, vil datoen være uendelig tilbage i tiden 5 Aktoer 1 UUID/URN Reference til organisation for den aktør der har defineret virkningen 5 AktoerType 1 Organisation OrganisationEnhed OrganisationFunktion Bruger ItSystem Interessefaellesskab Den type aktør i organisation, der er relateret ovenfor 5 NoteTekst 0:1 Tekst Dette er en tekst der kan benyttes til at forklare hvorfor virkningen er defineret 4 Fremdrift Modtaget Fordelt UnderUdarbejdelse UnderReview Endeligt Afleveret Vil normalt være Endeligt med mindre et udgående dokument overføres før det er færdigt/ afsendt 3 RelationListe 1 - Der understøttes kun en virkning pr. relation 4 DokumentPart 0:n - Indeholder relationer er parter (Relationstype) KOMBIT A/S Halfdansgade København S CVR Side 48 af 60

49 Niv Feltnavn Kard Værdisæt Betegnelse 5 Virkning 1 - Virkning angiver hvornår relationen er valid. 6 FraTidspunkt 0:1 DateTime Det tidspunkt hvor relationen er gyldigt fra. Vil typisk være tidspunkt for modtagelse af notatet. Hvis udeladt, vil datoen være uendelig tilbage i tiden 6 TilTidspunkt 0:1 DataTime Det tidspunkt hvor relationen er gyldigt til. Hvis udeladt, vil relationen være evig gyldig 6 Aktoer 1 UUID/URN Reference til organisation for den aktør der har defineret virkningen 6 AktoerType 1 Organisation OrganisationEnhed OrganisationFunktion Bruger ItSystem Interessefaellesskab Den type aktør i organisation, der er relateret ovenfor 6 NoteTekst 0:1 Tekst Dette er en tekst der kan benyttes til at forklare hvorfor virkningen er defineret 5 Rolle 1 PrimaerPart SekundaerPart KopiModtager Angiver rollen for parten i forhold til dokumentet 5 Indeks 1 Tekst Unik reference til en given relation, hvis der er flere på samme DokumentPart Rolle. Kan f.eks. være et fortløbende nummer 5 Objekttype 1 Person (CPR) Typen af part der relateres til Virksomhed (CVR) Organisation OrgEnhed OrgFunktion Interesse-faellesskab Bruger 5 ReferenceID 1 UUID/URN/Tekst Ekstern relation til parten (f.eks. CPR-nr) 4 Variant 1:n - Angiver forskellige varianter af det samme dokument, f.eks. en doc og en pdf variant Pt. understøttes kun en variant, men løsningen skal understøtte at der fremover kan håndteres flere varianter. Der kan eventuelt være flere virkninger for varianten. Hvis der er flere instanser her, valideres at der ikke er overlap på virkningerne. 5 Virkning 1 - Virkning angiver hvornår Varianten er valid. KOMBIT A/S Halfdansgade København S CVR Side 49 af 60

50 Niv Feltnavn Kard Værdisæt Betegnelse 6 FraTidspunkt 0:1 DateTime Det tidspunkt hvor Varianten er gyldig fra. Vil typisk være tidspunkt for modtagelse af Varianten. Hvis udeladt, vil datoen være uendelig tilbage i tiden 6 TilTidspunkt 0:1 DataTime Det tidspunkt hvor Varianten er gyldigt til. Hvis udeladt, vil Varianten være evig gyldig 6 Aktoer 1 UUID/URN Reference til organisation for den aktør der har defineret virkningen 6 AktoerType 1 Organisation OrganisationEnhed OrganisationFunktion Bruger ItSystem Interessefaellesskab Den type aktør i organisation, der er relateret ovenfor 6 NoteTekst 0:1 Tekst Dette er en tekst der kan benyttes til at forklare hvorfor virkningen er defineret 5 Rolle 1 Variant Fast værdi 5 Indeks 1 Tekst Udfyldes med 1, da der kun kan understøttes en variant 5 VariantAttributter 1-6 VariantType 1 Tekst Unik type af varianten. Ændres ikke over tid. Eks: Word, HTML, PDF samt TIFF. 6 Produktion 0:1 Nej, Ja Angiver om det er denne variant der udgør grundlaget for redigering af dokumentet 6 Offentliggørelse 0:1 Nej, Ja Angiver om det er denne variant der offentliggøres 6 Arkivering 0:1 Nej, Ja Angiver om det er denne variant der arkiveres 6 DelvistScannet 0:1 Nej, Ja Angiver om det er denne variant er helt eller delvist scannet 5 DelAttributter 1 - Angiver de dele det fysiske dokument er opdelt i. Pt. understøttes kun en del, men løsningen skal understøtte at der fremover kan håndteres flere dele. 6 DelTekst 1 Tekst Unik beskrivelse af dokumentdelen indenfor den givne dokumentvariant KOMBIT A/S Halfdansgade København S CVR Side 50 af 60

51 Niv Feltnavn Kard Værdisæt Betegnelse 6 Indeks 0:1 Heltal Beskrivelse af rækkefølge mellem de enkelte dele. Rækkefølge sættes af brugeren 6 Indhold 0:1 URI/ Tekst Reference til den fil der indeholder dokumentdelen. Filen skal være indeholdt i kuvertens DokumentFilnavn Pt. undersøttes kun en fil, og dermed kun en Del, men det skal være mulig senere at udvide så flere filer, og dermed flere varianter/ dele understøttes. 6 Filstoerrelse 0:1 Heltal Antal bytes estimeret i filen 6 MimeType 0:1 Tekst Dokumentdelens MimeType, en beskrivelse af indholdets type og sammensathed 6 ScannerID 0:1 Tekst Identifikation af dokumentet i scanneren 6 Lokation 0:1 Tekst Henvisning til location, hvor fysisk udgave af dokumentet findes [Udfyld specifikation for både input og output data. Dataelementer specificeres med elementnavn, datatype, feltlængde, valgfri/tvungen, evt. bemærkning til anvendelse, og krav til validering.] Miljø: Produktion Inputdata Outputdata DistributionServiceMsg.xsd DistributionServiceMsg.xsd Miljø: Test Inputdata Outputdata DistributionServiceMsg.xsd t_itype.xsd DistributionServiceMsg.xsd Sikkerhed Der benyttes Serviceplatformens standard sikkerhed for udstillede services. KOMBIT A/S Halfdansgade København S CVR Side 51 af 60

52 Leverancesikkerhed og fejlhåndtering At least once. Hvis afsendelsen fejler, skal afsender genfremsende samme AnvenderTransaktionsID. Såfremt et givet ID allerede er modtaget, returnerer Fordelingskomponenten besked om dublet, og beskeden ignoreres af fordelingskomponenten Servicemål Følgende underafsnit indeholder oplysninger vedrørende servicemål for aftalt driftstid Aftalt driftstid Parameter Tidsrum Svartid Tilgængelighed Spidsbelastningsperiode Servicevinduer Værdi [Afklaring/KDF: Åbningstid for fagsystem kendes ikke] [Afklaring/KDF: Svartid for fagsystem kendes ikke herunder SFTP] [Afklaring/KDF: Tilgængelighed for fagsystem kendes ikke] [Afklaring/KDF: Spidsbelastningsperioder for fagsystem kendes ikke] [Afklaring/KDF: Servicevinduer for fagsystem kendes ikke] Beskrivelse af endpoint EP_FS2- FordelingskvitteringAfsend Transportspecifikation Serviceudstiller Serviceplatform er serviceudstiller Serviceanvender Modtagersysterne (fagsystemerne) er serviceanvenderne 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 DistributionService.wsdl KOMBIT A/S Halfdansgade København S CVR Side 52 af 60

53 Endpoint IP [Udfyldes af KDF senere] Miljø: Test URI til WSDL Endpoint navn Endpoint IP [WSDL] Se DistributionService.wsdl [Udfyldes af KDF senere] Teknisk retning for udveksling Modtagersystemet kalder en synkron service udstillet af Serviceplatformen Dataretning for udveksling Modtagersystemet leverer en forretningskvittering til Serviceplatformen, som videresender den til afsendersystemet Service invokation / Triggers Når en journalpost eller et dokument er valideret i henhold til de tekniske krav sendes Modtaget. Når den er forretningsmæssigt accepteret sendes Accepteret. Herefter overgår det fulde ansvar for objektet til modtageren, og afsenderen kan i princippet slette sin egen kopi. Hvis valideringen fejler, eller modtageren ikke ønsker at overtage objektet, sendes en negativ kvittering retur Dataspecifikation Forretningskvittering Denne struktur benyttes til at kommunikere forretningskvitteringer (resultatet af behandlingen af det fremsendte objekt) retur til afsenderen og indeholder følgende: Niv Feltnavn Kard Værdisæt Betegnelse 1 Forretningkvittering 1 - Indeholder den fremsendte kvittering 2 ForretningValideringKode 1 "Modtaget" "Afleveret" "Accepteret" "Afvist" "Fejlet" Indikerer om modtagersystemet har modtaget objektet og senere om det har accepteret objektet. Hvis der returneres Afvist skal afsenderen håndtere problemet, og eventuelt fremsende til en anden modtager 2 Begrundelse 0:1 Tekst Dette er en tekst fra modtageren, der forklarer hvorfor et objekt er afvist. Vil typisk stamme fra den sagsbehandler der har behandlet objektet. 2 FejlListe 0:n - Lister alle de valideringsfejl der er identificeret. Benyttes kun ved Fejlet. KOMBIT A/S Halfdansgade København S CVR Side 53 af 60

54 Niv Feltnavn Kard Værdisæt Betegnelse 3 FejlKode 1 Tekst Entydig identifikation af fejlen 3 FejlTekst 1 Tekst Beskrivelse af fejlen Miljø: Produktion Inputdata Outputdata DistributionServiceMsg.xsd DistributionServiceMsg.xsd Miljø: Test Inputdata Outputdata DistributionServiceMsg.xsd t_itype.xsd DistributionServiceMsg.xsd Sikkerhed Der benyttes Serviceplatformens standard sikkerhed for udstillede services Leverancesikkerhed og fejlhåndtering At least once. Såfremt kaldet fejler, er det det kaldende system der skal foretage et nyt kald Servicemål Følgende underafsnit indeholder oplysninger vedrørende servicemål for aftalt driftstid Aftalt driftstid Parameter Tidsrum Svartid Værdi Systemet driftsafvikles hele døgnet alle dage bortset fra når der udføres ændringer/hvor der er servicevinduer [SPref]. Der er forskellig SLA på svartid alt efter hvilken integrationskompleksitet, der er tale om: Simpel = 1 sekund KOMBIT A/S Halfdansgade København S CVR Side 54 af 60

55 Mellem = 1,5 sekund Kompleks = 4 sekunder [SPref] Tilgængelighed Spidsbelastningsperiode Servicevinduer Servicemålene for systemets driftseffektivitet er 99,8% for perioden 06:00-18:00 på arbejdsdage samt 98,5 % i den øvrige tid [SPref]. Må antages at være i perioden 06:00-18:00 på arbejdsdage [SPref]. Ved mindre opdateringer: 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: 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] Service Management Incident Management [Indhold afventer generel afklaring af governancestrukturer.] Problem Management [Indhold afventer generel afklaring af governancestrukturer.] Change Management [Indhold afventer generel afklaring af governancestrukturer.] Testplan Integrationstest Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Produktionssætningstest Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. KOMBIT A/S Halfdansgade København S CVR Side 55 af 60

56 KOMBIT A/S Halfdansgade København S CVR Side 56 af 60

57 4 Beskrivelse for integrationsplatforme 4.1 Beskrivelse for Serviceplatformen Nærværende afsnit angiver den integrationsfunktionalitet, som Serviceplatformen håndterer i interaktionen mellem integrationsparter. En integration kan understøttes af flere integrationsflow, som vil være beskrevet hver for sig i nærværende afsnit. I hvert integrationsflow vil der indgå en række endpoints. Hvert endpoint vil være specificeret i integrationsbeskrivelserne for integrationsparterne, jf. ovenstående afsnit 3. Figuren nedenfor viser hvilke komponenter og endpoints, der indgår i integrationen. Afsend Serviceplatformen Modtag Afsendersystem FTP Kvittering Forespørg Forespørg IF01 Overfør objekt IF02 List modtagere IF03 Valider modtager(-e) FTP Kvittering Modtagersystem Oversigt over integrationsflows ID Navn IF01 Overfør objekt til modtager og returner asynkron kvittering Integrationsflow IF01: Overfør objekt til modtager og returner asynkron kvittering Anvendte service endpoints Endpoint ID Navn på endpoint Dokument-reference EP_FS1 FordelingsobjektModtag Afsnit EP_FS2 FordelingskvitteringAfsend Afsnit Integrationstype Orkestreringssintegration (Del af fordelingskomponenten)] KOMBIT A/S Halfdansgade København S CVR Side 57 af 60

58 Diagram over integrationsflowet Jf. figuren nedenfor indgår følgende integrationsflows 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 Dette dokument specificerer kommunikationen mellem serviceplatfomen og modtagersidensiden, altså den højre side af tegningen. 4.2 Services udstillet af Serviceplatformen Alle services udstillet af Serviceplatformen har en ekstra header (InvocationContext), der anvendes af serviceplatformen til validering af afsenderen og til afregningsformål. Der henvises til den generelle dokumentation for Serviceplatformen (serviceplatformen.dk) for yderligere information FordelingskvitteringAfsend Denne service benyttes af modtagersystemerne til at returnere forretningskvitteringer til afsendersystemer. Request input består af følgende elementer: - DistributionContext (se afsnit ) - ForretningsKvittering (se afsnit ). Modtagersystemet skal sende indholdet af DistributionContext retur uændret i forhold til det der blev modtaget via FordelingsobjektModtag. Synkron response returdata består af følgende elementer: KOMBIT A/S Halfdansgade København S CVR Side 58 af 60

59 - Transportkvittering (Se afsnit ) 4.3 Services udstillet af Modtager Modtager skal udstille følgende service: FordelingsobjektModtag Denne service benyttes til at modtagersystemet kan modtage de objekter der fremsendes til modtagersystemet Request input består af følgende elementer: - DistributionContext (se afsnit ) - DistributionObjekt (se afsnit ). Der kan kun modtages en type ad gangen (Journalpost eller Dokument). Hvis DistributionContext.DokumentFilnavn er angivet, skal modtagere hente filen med dokumentet fra Serviceplatformens FTP-server inden der afgives teknisk kvittering. Synkron response returdata består af følgende elementer: - Transportkvittering (Se afsnit afsnit ) - Forretningskvittering (Se afsnit afsnit ) Retur udgør en teknisk kvittering for validering, herunder at en eventuel tilknyttet fil var tilgængelig på FTP serveren. Hvis der returneres Modtaget, indikerer det ligeledes en forretningskvittering for at modtagersystemet har overtaget ansvaret for videre behandling af objektet. Efterfølgende vil denne behandling asynkront resultere i at objektet enten accepteres eller afvises Datatransformering N/A Datapersistering N/A Databerigelse N/A KOMBIT A/S Halfdansgade København S CVR Side 59 af 60

60 Routing Routing foregår ud fra felterne i overførselsbeskeden, AfsendendeMyndighed, RoutingMyndighed, RoutingEmneFacet, RoutingHandlingFacet og RoutingModtagerAktoer Orkestrering Sikkerhed Logning Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Testdata og testfaciliteter Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Konfiguration Supplerende information KOMBIT A/S Halfdansgade København S CVR Side 60 af 60