SKI Version 1.0

Størrelse: px
Starte visningen fra side:

Download "SKI 02.19. Version 1.0"

Transkript

1 SKI Version maj

2 Indhold Indledning... 3 Snitfladernes etablering og tilgængelighed... 3 Integrations- og anvendervilkår... 3 Beskrivelse af KOMBITs snitfladeoversigt... 4 Faneblad: Snitfladeoversigt... 4 Faneblad: FORM - Snitflade - Dato... 4 Målarkitektur... 6 Det grundlæggende... 6 Integrationsformer... 7 I-01 - Integration via beskeder... 8 To former for beskeder... 9 Beskeders struktur... 9 I-02 - Integration via den fælleskommunale Serviceplatform I Asynkrone services I Synkrone services I Filintegration I-03 - Direkte integration Integrationer Generelle krav til integrationer M-01 - Jobcenterløsningernes integrationer M-02 - ØiR integrationer M-03 - Integration til Støttesystemet Sags- og Dokumentindeks M-04 - Integration til Støttesystemet Ydelsesindeks M-05 - Integrationer til Støttesystemerne Klassifikation og Organisation M-06 - Integration til Støttesystemerne for Sikkerhed M-07 - Integration til Støttesystemet Beskedfordeler M-08 - Dialogintegration M-09 - Integration til Dokumentfordeler

3 Indledning Bilaget angiver de obligatoriske integrationer, som den tilbudte løsning skal indgå i. De obligatoriske integrationer er, ift. integrationen med de fælles kommunale løsninger, omfattende både de fælleskommunale fagløsninger og støttesystemer. Integrationsbehovet vil variere ift. de forretningsområder, som den enkelte løsning understøtter. Derfor er kravene om obligatoriske integrationer opgjort i en matrice, som sammenstiller FORM med integrationen ved en snitflade. Snitfladen er her den snitflade, som KOMBIT via de fælles kommunale løsninger stiller til rådighed for løsningens brug. Den konkrete snitfladeoversigt fremgår af Bilag F5.1 D2 KOMBIT snitfladeoversigt. Snitfladernes etablering og tilgængelighed Snitfladerne, som løsningerne skal integrere med, vil løbende blive konkretiseret, etableret og gjort tilgængelig ifm. de udbud, som KOMBIT er i færd med at gennemføre. Leverandøren opfordres til at holde sig ajour med planerne for den enkelte snitflade, herunder hvornår snitfladebeskrivelsen foreligger, snitfladen er klar til integrationstest mv. Informationen vil blive gjort tilgængelig på KOMBITs hjemmeside Integrations- og anvendervilkår De specifikke integrations- og anvendervilkår, som vil gælde for snitfladerne, herunder integration til KOMBITs Serviceplatform, de fælleskommunale støttesystemer mv. vil ligeledes være at finde på KOMBITs hjemmeside 3

4 Beskrivelse af KOMBITs snitfladeoversigt Snitfladeoversigten er udarbejdet i Microsoft Excel. Den indeholder to faneblade. Det først faneblad Snitfladeoversigt indeholder en samlet oplistning af de obligatoriske snitflader. Det andet faneblad FORM - Snitflade - Dato angiver, fra hvornår en snitflade er obligatorisk opgjort pr. FORMområde. Det betyder, at dækker den tilbudte løsning et givent FORM-område, da er det obligatoriske for leverandøren at sikre, at den tilbudte løsning kan indgå i integration med de snitflader, som er markeret for FORM-området. Det forudsætter naturligvis, at løsningen indeholder det informationsobjekt, som integrationen håndterer. Der skal ikke foretages ændringer, angivelser, i arket. Faneblad: Snitfladeoversigt Her beskrives de enkelte kolonner i arket. ID : Unik identifikation af den enkelte snitflade Vil kunne genfindes på KOMBITs hjemmeside Forretning : Beskrivelse af det forretningsmæssige formål med og anvendelse integrationen, som snitfladen understøtter. Herunder hvilken løsning, som udstiller snitfladen Anvendelsesmønster : Her angives forventning til brugen af snitfladen, dvs. hvorledes integrationen skal foregå ift. den forretningsunderstøttelse, som løsningen indeholder. Information : Det eller de primære informationsobjekter data- som indgår i integrationen. Arkitekturreference : Reference til arkitekturmønsteret for integrationen. Faneblad: FORM - Snitflade - Dato Fanebladet indeholder en matrice. Venstre kolonner er indeholder referencen til FORM. Top-rækken indeholder den unikke reference til snitfladen, ID, som det er angivet på fanebladet Snitfladeoversigt. 4

5 Hvor en snitflade er obligatorisk for en FORM-området, er det angivet med en dato/tidsangivelse i matricen. Dette angiver fra hvornår snitfladen senest skal kunne ibrugtages af kunderne på løsningen. Formkolonner Ydelsesområde : Jf. Bilag F D2 Kravspecifikation Hovedgruppe : Jf. FORM Opgaveområde : Jf. FORM OpgaveNavn : Jf. FORM OpgaveTekst : Jf. FORM FORM Nummer : Jf. FORM Snitflade række ID : Navn på snitfladen Navn : Unik identifikation af den enkelte snitflade. 5

6 Målarkitektur I dette afsnit beskrives målarkitekturen for de identificerede snitflader. Målarkitekturen for snitfladerne er baseret på en række grundlæggende integrationsformer, som understøttes af de fælleskommunale støttesystemer og Serviceplatform. De grundlæggende integrationsformer er angivet på formen I-0x altså I-01, I-02 etc. Målarkitektur for de enkelte integrationer er angivet på formen M-0x altså M-01, M-02 etc. Det grundlæggende De mål for arkitektur og integrationer som er beskrevet i nærværende bilag sikrer understøttelse af til den fællesoffentlige digitaliseringsstrategi og de fælleskommunale arkitekturprincipper. Det er således væsentligt at integrationsformer vælges således tætte koblinger mellem systemer undgås. Ligeledes er det væsentligt at de informationer der udveksles i høj grad er baseret på fælles standarder og dermed, hvis de findes, på fællesoffentlige standarder. Valget af integrationsform skal som sagt understøtte kommunernes arkitekturprincipper og støtte op omkring den fælleskommunale digitaliseringsstrategi. Følgende er relevante udsnit af de fællesoffentlige arktiekturprincipper, som i deres helhed kan læses her: I forhold til valg af integrationsform er disse arkitekturmål vigtige (arkitekturprincipperne p.4): 1. Sammenhængende it Kommunens borgere (og medarbejdere) mødes ikke med behovet for genindtastning af data, som allerede er kendte af andre systemer. Systemerne har en datasammenhæng og en dataudvekslingsarkitektur, som skaber sammenhæng mellem it-løsningerne. 2. Byg til forandring Kommunens it-løsninger skal være lette at tilpasse, når der fx kommer ny lovgivning, der ændrer processen eller, når kommunerne vil forandre opgaveløsningen, så it-omkostningerne ikke bliver en bremse på forandring 3. Flere leverandører Når kommunen baserer sine løsninger på åbne standarder og udskiftelige komponenter, kan de skifte leverandører uden tekniske barrierer. Herudover er der et ønske om et reelt flerleverandørmarked, som sikrer konkurrence og innovation. 6

7 4. Driftstabilitet Kommunens it-løsninger skal være driftsstabile, pålidelige, attraktive og sikre, så borgere og medarbejdere kan have tillid til og vil tilslutte sig den digitale opgaveløsning I forhold til valg af integrationsformer er disse arkitekturprincipper vigtige: 1. Der arbejdes mod en fælles Rammearkitektur (A1) Den fælles Rammearkitektur skal sikre en ensartet måde at opfatte forretningsobjekter og disses integrationer med hinanden. Rammearkitekturen sikrer endvidere samme opfattelse af Forretningsobjekter på tværs af leverandører, bla. i form af standarder. 2. Arkitekturen skal sikre mod leverandør-lock-in (A2) I en integrationssammenhæng er det vigtigt at have en løs koblet arkitektur, således at der let kan skiftes leverandør på de forskellige løsninger. Det skal også sikres, at der kan være flere leverandører til samme løsning. Undgå endvidere leverandørejede, proprietære protokoller. 3. Forretningshændelser meddeles omverdenen (B7) Når en proces har ændret på et forretningsobjekt, meddeles det omverden via beskeder. På den måde kan processer automatisk startes op på baggrund af det, der sker et andet sted. 4. Fælles autoritative reference- og grunddata anvendes (B8) For at sikre at entydig og entydig udveksling af information anvendes og opmærkes med fælles referencedata. Ved at anvende autoritative grunddata sikres pålidelige og opdaterede data. 5. Forandringsrobust arkitektur (B9). Eller byg til forandring. Vi skal bygge vores integrationer løskoblet og med stor smidighed, da verden helt sikkert forandres. Derfor bør stærke fysiske bindinger undgås. 6. Alle data er uafhængige af systemet, hvor de opbevares (C2) Det er IKKE systemerne, der ejer data. Dvs. at adgang til data ikke må gøres til et spørgsmål om datas lokation. Adgang til data er et spørgsmål om rettigheder. 7. IT-løsninger er robuste overfor egne og andre systemers nedbrud (C5) Dette princip skal sikre at der tænkes i robuste integrationsformer, som er mindst muligt følsomme for andre systemers nedbrud og som er selvreparerende, når systemer eller linjer kører igen Integrationsformer Den fælleskommunale infrastruktur består af en række systemer som udfører forskellige opgaver i den kommunale forvaltning. Systemerne har behov for at udveksle informationer med forskellige formål. 7

8 Det er væsentligt at de integrationer, som systemerne anvender fremadrettet understøtter de arkitekturmæssige mål og principper omtalt i foregående afsnit. Det er derfor med udgangspunkt i disse, at følgende integrationsformer er defineret. De integrationsformer der her nævnes er Integration via beskeder Integration via services Direkte integration Afsendersystemer Fagsystemer Fagsystemer Fagsystemer Fagsystemer Fagsystemer Støttesystemer Grunddata Beskedfordeler Serviceplatformen Asynkron service Synkron service Filintegration Kildesystemer Modtagersystemer Fagsystemer Fagsystemer Fagsystemer Fagsystemer Fagsystemer Støttesystemer I-01 - Integration via beskeder Integrationer via beskeder understøtter Event Driven Architecture, som er et bærende element i den fælleskommunale Rammearkitektur. Målet for de kommunale systemer er dermed at der i videst mulig omfang integreres via beskeder. Integration via beskeder understøtter dermed arkitekturprincipperne om robust, forandringsparat og løst koblet arkitektur ligesom ønsket om at imødegå leverandør lock-in effektivt understøttes. Denne integrationsform betyder, at når et system ønsker at meddele omverdenen at en hændelse er indtruffet, afleveres en besked til Beskedfordeler. Beskedfordeler distribuerer herefter beskeden til de systemer, der abonnerer på den pågældende beskedtype. De to parter, afsender og modtager kender, ikke hinanden. Det overordnede integrationsmønster er således det løst koblede Publish/Subscribe. Konkret er processen den, at afsendersystemer afleverer deres beskeder direkte til Beskedfordeler. Modtagersystemerne kan vælge imellem, at Beskedfordeler afleverer en besked til dem (push scenarie), eller at hente beskeder fra Beskedfordeler (pull scenarie). Både afsender og modtager er bundet op på de aftaler, de er indgået om deres brug af beskeder. 8

9 Se i øvrigt for nærmere beskrivelse af hvordan der integreres til Beskedfordeler To former for beskeder I Rammearkitekturen defineres to former for beskeder Hændelsesbeskeder som er beskeder der sendes når en proces er færdig med sit arbejde og dermed har ændret på sit forretningsobjekt. Beskeden informerer om, at opgaven er løst. I dette scenarie tilhører forretningsobjektet afsendersystemet. Meddelelsesbesked som er en særlig type beskeder, hvor der i en proces sendes en meddelelse til en anden proces. Eksempelvis kan et beregningssystem sende en udbetalingsanmodning til et udbetalingssystem. I dette scenarie tilhører forretningsobjektet modtagersystemet. Det er udfyldt og afsendt af afsendersystemet, i en struktur som er defineret af modtageren. Formidlingen af meddelelsesbeskeder er stadig del af publish/subscribe mønsteret, som Beskedfordeler implementerer hvilket betyder at afsender ikke kender det konkrete modtagersystem. Beskeders struktur En besked består af Beskedkuvert som indeholder alle de informationer, der er nødvendige dels for at definere hvilke beskeder man ønske at modtage i sit abonnement, dels for at kunne distribuere de rigtige beskeder til de rigtige modtagere. Se i øvrigt Beskedmetadata som indeholder de generelle/standardisere informationer om objektet. For en given sag vil dette være relevante informationer fra Sags- og Dokumentstandarden. Beskeddata som indeholder de evt. helt specifikke informationer om en given opdatering, og som ikke er indeholdt i beskedens metadata. Transportmekanisme Transportmekanismerne er endnu ikke fastlagt, da udbud pågår, men det vil være gængs og udbredt anvendt teknologi. 9

10 Beskedfordeler vil benytte den kommende fælleskommunale sikkerhedsmodel. Dette betyder, at de systemer, som ønsker afsende og modtage beskeder må understøtte denne model. Se i øvrigt Konkret vil Beskedfordeler og anvendersystemerne være afhængige af sikkerhedskomponenterne Administrationsmodulet, Adgangsstyring for Systemer og Adgangsstyring for brugere. I-02 - Integration via den fælleskommunale Serviceplatform Den fælleskommunale Serviceplatform understøtter forskellige former for integrationer. I nærværende udbud nævnes tre grundlæggende former, som kan kombineres i de enkelte integrationer. De tre integrationsformer er Asynkrone services dette er den foretrukne integrationsform, da den løsner bindingen mellem de involverede systemer. Synkrone services kan der være gode grunde til at anvende, men er ikke den foretrukne, da den giver en stærk binding mellem de involverede systemer. Filintegration anvendes til at overføre store datamængder som eksempelvis statistikdata. Denne integrationsform vil altid være asynkron. At anvende en kombination af integrationsformerne kunne eksempelvis være hvis en kombination af synkron og asynkrone services anvendt på forskellige niveauer i en integration komplementere hinanden. På det forretningsmæssige niveau kan en integration være asynkron ved at en forespørgsel sendes til en service, som evt. kan være udstillet på Serviceplatformen svaret på forespørgslen leveres ved at det sendes til en service udstillet af det afsendende system. På det rent tekniske niveau kan de to servicekald dog godt være synkrone idet svaret på det enkelte servicekald medfører en simple anerkendelse af at forespørgsel/svar er modtaget. Transportmekanisme Den fælleskommunale Serviceplatform understøtter følgende transportmekanismer SOAP(https) sftp gateway Desuden vil der blive etableret en sftp Server med adgangsstyrede filer og foldere. For integration til de kommende fælleskommunale systemer inkl. støttesystemerne skal den fælleskommunale sikkerhedsmodel understøttes. Ved servicekald i Rammearkitekturen opereres med tre forskellige typer af adgangsstyring, der tilgodeser forskellige behov. Adgangstyperne giver forskellige muligheder for detaljeringsgraden af de adgangsrettigheder, der kan håndhæves, når servicen kaldes, og understøttes på forskellig vis rent teknisk. 10

11 Simpel service: Certifikatbaseret. Enten har anvendersystemet adgang til hele servicen eller også har det ikke adgang. Simpel fælleskommunal service: Certifikatbaseret. Et anvendersystem tilgår altid servicen på vegne af en given myndighed. Anvendersystemet har enten adgang til hele servicen (for den specifikke myndighed) eller også har det ikke adgang. Fælleskommunal service: Tokenbaseret. Et anvendersystem tilgår altid servicen på vegne af en given myndighed. Endvidere begrænses anvendersystemets brug af servicen ud fra systemroller, der tildeles anvendersystemet. Det bemærkes at KOMBIT generelt anbefaler den tokenbaserede model Fælleskommunal service, da dette giver den mest detaljerede sikkerhedsmodel. I Asynkrone services At anvende asynkrone services er karakteriseret ved en relativ løs kobling mellem det system som ønsker at forespørge på eller aflevere data og det system som svarer eller modtager data, men der vil være dog afhængighed af transportkanalens tilgængelighed. Transportkanalen er i dette regi den fælleskommunale Serviceplatform. Konkret fordrer dette integrationsmønster, at den modtagende part er i stand til at svare på kaldet indenfor en rimelig tid samt at den forespørgende part er i stand til at håndtere, at der ikke modtages svar inden for en given tidsramme. Yderligere fordrer det af både afsender og modtager at forespørgsel og svar kan kædes sammen, således det er klart for afsender hvad der modtages svar på. Mønsteret giver en løsere binding mellem de involverede systemer end anvendelse af synkrone services. Det giver også mulighed for bedre udnyttelse af transportkanalens ressourcer. Det er derfor som udgangspunkt den foretrukne form for serviceintegration Transportmekanisme For de asynkrone services er følgende transportmekanisme relevant SOAP(https) For integration til de kommende fælleskommunale systemer inkl. støttesystemerne kræves at den fælleskommunale sikkerhedsmodel understøttes I Serviceintegration med forretningskvittering Når et afsendersystem ønsker at overdrage ansvar for data og den videre håndtering af disse og det samtidigt er væsentligt for afsendersystemet at få bekræftet at modtagersystemet har accepteret overdragelsen, kan denne type af service anvendes. 11

12 Arbejdsgangen er illustreret i nedenstående tegning med eksempel på opdatering af Sags- og Dokumentindeks: 6 Fagsystem (Afsender system) 1 Service platform 2 3 Indeks 5 4 KMD Sag Tallene på tegningen illustrerer følgende: 1. Afsendersystem kalder opdateringsservice på Serviceplatformen (asynkront) 2. Serviceplatform kalder opdateringsservice på Indeks (synkront) 3. Indeks svarer Serviceplatform (synkront) 4. Serviceplatform kalder opdateringsservice på KMD Sag (synkront) 5. KMD Sag svarer Serviceplatform (synkront) 6. Afsendersystem får svar retur (asynkront) Følgende fejlsituationer medfører følgende handlinger: 2 fejler: Serviceplatform får fejl vha. 3, udfører ikke 4 og 5 og returnerer fejl til Afsendersystem vha 6. Afsendersystem opdaterer ikke KMD Sag. 4 fejler: Serviceplatform får fejl vha. 5 og returnerer fejl til Afsendersystem. Afsendersystem skal herefter udføre kompenserende handling i forhold til opdatering 2. Da denne type af service medfører en relativt stor afhængighed mellem afsendersystem og muligvis flere modtagersystemer skal anvendelsen af den nøje overvejes og begrænses til det absolut nødvendige. I Synkrone services At anvende synkrone services er karakteriseret ved en relativ hård binding mellem det system som ønsker at forespørge på eller aflevere data og det system som svarer eller modtager data, samt stor afhængighed af transportkanalens kvalitet. Transportkanalen er i dette regi den fælleskommunale Serviceplatform. Konkret fordrer dette integrationsmønster, at den modtagende part er i stand til umiddelbart at svare på kaldet samt at den forespørgende part er i stand til at håndtere, at der evt. ikke er forbindelse til modtageren og om nødvendigt genfremsætte sin forespørgsel. Mønsteret giver dermed en hård binding mellem de involverede systemer. Uagtet det uhensigtsmæssige i den hårde binding kan der være en forretningsmæssig nødvendighed for det umiddelbare svar i nogle tilfælde. Eksempelvis kan forretningen have regler om at en række informationer SKAL være indhentet, før en given transaktion kan afsluttes. 12

13 Transportmekanisme For de synkrone services er følgende transportmekanisme relevant SOAP(https) For integration til de kommende fælleskommunale systemer inkl. støttesystemerne skal den fælleskommunale sikkerhedsmodel understøttes. I Filintegration Store datamængder kræver særlig opmærksomhed da både størrelsen på en given fil og antallet af forespørgsler/opdateringer erfaringsmæssigt giver udfordringer i et distribueret miljø. Transportmekanisme For filintegrationer er følgende transportmekanismer relevante sftp gateway sftp Server I-03 - Direkte integration I særlige tilfælde kan direkte integrationer mellem afsendersystemer og modtagersystemer være relevante. Da der således vil være tale om endog meget tæt kobling mellem de involverede systemer og der derved ikke leves op til de fælleskommunale arkitekturprincipper om løs kobling er det ikke en foretrukken integrationsform. Denne måde at integrere på kan for fagsystemer dog være relevant, hvis der er tale om en midlertidig integration, der etableres for eksempelvis at lette ind-/udfasning af systemer, og det dermed alene er de to involverede systemer, der vil kunne have interesse i data. Men så snart det vurderes at data kunne være relevant for flere systemer enten på afsender eller på modtagersiden, bør integration via beskeder eller services på serviceplatformen foretrækkes. Direkte integrationer anvendes tillige af systemer, som er centrale infrastrukturkomponenter i det fælleskommunale systemlandskab mere konkret vil der være direkte integrationer til Den fælleskommunale Serviceplatform Støttesystemet Adgangsstyring for Systemer Støttesystemet Adgangsstyring for brugere Støttesystemet Beskedfordeler 13

14 Transportmekanisme Vedr. transportmekanismen for at tilgå services på Serviceplatformen se I-02 - Integration via den fælleskommunale Serviceplatform. Transportmekanismerne for de tre støttesystemer er endnu ikke fastlagt, da udbud for disse systemer pågår. Men de vil være gængse og udbredt anvendte teknologier. Hvilke teknologier, der er valgt vil fremgå af opdaterede integrationsvilkår for de enkelte støttesystemer. For at anvende støttesystemerne skal Støttesystemerne for Sikkerhed være tilgængelige. Integrationer I det følgende beskrives krav til de konkrete integrationer, som er defineret i Bilag 5.1 D2 KOMBIT Snitfladeoversigt. Integrationerne er her grupperet efter forretningsdomæne, hvor dette er relevant. Således er eksempelvis krav til jobcenterløsningernes integration til de fælleskommunale systemer beskrevet under ét. Indledningsvist er der beskrevet en række generelle behov og krav, der som udgangspunkt er gældende for alle integrationerne. Med undtagelse af de systemer som i forrige afsnit er nævnt specifikt som værende direkte integrationer. Generelle krav til integrationer Det er væsentligt for at få det kommunale systemlandskab til at understøtte kommunernes behov at de fælleskommunale støttesystemer bringes i anvendelse. Således er der behov for at de kommunale systemer bidrager til dette. Dette vil sige, at sagsbærende systemer skal opdatere Støttesystemet Sags- og Dokumentindeks og hvis det er relevant skal Støttesystemet Ydelsesindeks ligeledes holdes opdateret. På samme måde er der behov for at Støttesystemet Beskedfordeler anvendes til at informere om forretningshændelser, samt at der abonneres og reageres på modtagne beskeder. Der er derudover et generelt behov for, at der arbejdes hen mod en så løst koblet arkitektur som muligt under hensyntagen til de forretningsmæssige behov, der må være indenfor de enkelte forretningsdomæner. Så samme måde er det også væsentligt, at systemerne kan tilpasses kommende standardiseringer af begreber og de deraf afledte informationsmodeller indenfor de enkelte domæner. 14

15 M-01 - Jobcenterløsningernes integrationer Integrationen mellem jobcenterløsningerne og de fælleskommunale systemer Kommunernes Ydelsessystem og Kommunernes Sygedagpenge System består af to typer af snitflader. Services udstillet på Serviceplatformen Afsendelse og modtagelse af beskeder via Støttesystemet Beskedfordeler Der er i regi af KOMBITs klippekortprojekt defineret en række services, som vil være de services som fagsystemerne eller jobcenterløsningerne skal udstille og anvende. Se Disse services vil være synkrone services, som det er beskrevet i I Synkrone services Det er dog et mål for denne integration, at der benyttes beskeder til udveksling af informationer i videst mulig omfang. Derfor er der behov for at både fagsystemerne og jobcenterløsningerne understøtte at afsende og modtage beskeder via Støttesystemet Beskedfordeler, se I-01 - Integration via beskeder. Endeligt skal Støttesystemerne Sags- og Dokumentindeks og Ydelsesindeks holdes opdateret når det er relevant. Anvendelse af støttesystemerne fremgår af de gældende integrationsvilkår for det enkelte støttesystem, som findes her: I en transitionsperiode skal systemerne understøtte begge integrationsformer, services og beskeder. For oprettelse/ændring af aftaler skal støttesystemet Administrationsmodulet være tilgængeligt dette er således ikke en run-time afhængighed, men en forudsætning for at kunne tilgå de fælleskommunale systemer For system adgang til andre systemer/støttesystemer skal støttesystemet Adgangsstyring for systemer være tilgængeligt For bruger adgang til brugervendte systemer skal støttesystemet Adgangsstyring for brugere være tilgængeligt I en transitionsperiode kan der være tale om at anvende eksisterende sikkerhedsmodel for Serviceplatformen - men dette vil alene kunne håndtere adgangen til de udstillede jobcentersnitflader og altså ikke adgangen til støttesystemerne og deres udstillede snitflader eller services For at nå målet, integration via beskeder skal Støttesystemet Beskedfordeler være tilgængeligt og jobcenterløsningen skal understøtte den fælleskommunale Sikkerhedsmodel. Sags- og Dokumentindeks skal være tilgængeligt Ydelsesindeks skal være tilgængeligt 15

16 M-02 - ØiR integrationer ØiR står for Økonomi i den fælleskommunale Rammearkitektur. ØiR er en integrationsløsning. ØiR understøtter kommunikationen af posteringer, debitorregistreringer og udbetalingsanmodninger fra en fagsystem (anvendersystem) til kommunens ERP-løsning ØiR har tre hovedfunktioner: Dirigering anvendersystemets kommunikation hen til den pågældende kommunes ERP-løsning (Routing) Transformering af transportmekanismen, dvs. understøttelse af at der skiftes mellem transportprotokoller, fx ftp og webservice. Transformering af data mellem de nuværende legacy dataformater, som anvendes i kommunalt regi og en mere moderne og fleksibel xml-struktur. Transformeringsfunktioner sigter alene på at lette overgangen til nye datastruktur og transportmekanisme. Denne interim funktionalitet vil forventelig blive udfaset 2-3 år efter ØiR s produktionssætning. ØiR er en fælleskommunal komponent på den fælleskommunale Serviceplatform. Anvendersystemerne: Der er mulighed for både synkrone og asynkrone services. Der er mulighed for både synkrone og asynkrone services. Synkrone forespørgsler: De synkrone services vil blive udstillet som SOAP baserede webservices, jf. I Synkrone services. Et servicekald kan alene håndtere en forespørgende myndighed (kommune). Asynkron kommunikation: ØiR udstiller asynkrone services til at modtagelse af en datasamling transaktioner (posteringer, debitorregistreringer, udbetalingsanmodninger). Servicen udstilles både som en SOAP baseret webservices eller via ftp jf. Serviceplatformens filintegration (se I Filintegration). Ved anvendelse af webservicen vil svaret indeholde en transportkvittering for modtagelse af datasamlingen Anvendersystemet skal udstille en service til modtagelse af forretningskvittering på overførelsen af datasamlingen til ERP-løsningen (se I Serviceintegration med forretningskvittering). ØiR kalder denne service, når datasamlingen er færdigvalideret af ERP systemet. Forretningskvitteringen omfatter både hele datasamlingen og de enkelte elementer i datasamlingen. Servicen bør udstilles som en SOAP baseret webservice alternativt en FTP-service. Kommunikationen skal opdeles pr. myndighed, kommune, for at understøtte den content baserede routing samt begrænsning af datavolumen. Datavolumen kan yderligere skulle begrænses ved anvendelse af webservices, fx i antal posteringer. 16

17 ERP-løsningen: ERP-løsning (løsningen) eller tilsvarende løsninger, integreres med ØiR på flg. vis Synkrone forespørgsler: Løsningen skal udstille synkrone services til rådighed til brug for servicekald gennemstillet via ØiR. Der er tale om SOAP-baserede webservices (se I Synkrone services). Asynkron kommunikation: Løsningen skal hente datasamlingen af transaktioner (posteringer, debitorregistreringer, udbetalingsanmodninger) med brug af en service, som ØiR udstiller. Servicen er understøttet i to varianter, en SOAP baseret webservice og en ftp-service jf. Serviceplatformens filintegration(se I Filintegration). Løsning kalder denne service for at få overført datasamlingen. Er der tale om anvendelse af webservicen kvitterer løsningen med angivelse af transportkvittering i svaret. Når løsningen har valideret den modtagne fil, afsender løsningen en forretningskvittering ved kald af en service udstillet af ØiR (se I Serviceintegration med forretningskvittering). Forretningskvitteringen omfatter både hele datasamlingen og de enkelte elementer i datasamlingen. Servicen er udstillet son en SOAP baseret webservice samt alternativt en FTP-service. Dirigering af kommunikation ØiR håndterer dirigering af kommunikation via en content baseret routingmekanisme. Denne mekanisme anvender forespørgende myndighed (fx kommunen). Sikkerhed Den fremadrettede sikkerhedsmodel baserer sig på sikkerhedsmodel fra de fælleskommunale støttesystemer. I interim perioden understøttes Serviceplatformens nuværende sikkerhedsmodel baseret på OIORESTsikkerhedskoncept. Generelt anvendes alene system-certifikater. Der vil være mulighed for at supplere med virksomheds- eller funktionscertifikater. Transformering - transportmekanisme For de asynkrone services vil ØiR kunne transformere mellem webservice og ftp. Kommunikation med ØiR følger mønsteret, hvor ØiR tager ansvar for data i det tidsrum, hvor data er lagret på platformen. 17

18 Tranformering data Data er i dag typisk organiseret i filformater baseret på KMD s løsninger til det kommunale område. Der er i regi af KOMBIT og i samarbejde men ERP-leverandørerne etableret en ny standard baseret på xml. ØiR vil indeholde transformeringslogik og data, som vil gøre det muligt at transformere data mellem de to formater. Både fra eksisterende legacy format til nyt xml-format og vice versa. Der vil i interimsperioden være begrænsninger i anvendelsen af nyt xml-format, hvor det indgår i en transformering. Den begrænsning vil også gælde ift. anvendelse af dataformatet i fagsystemer. For oprettelse/ændring af aftaler skal støttesystemet Administrationsmodulet være tilgængeligt dette er således ikke en run-time afhængighed, men en forudsætning for at kunne tilgå de fælleskommunale systemer. For system adgang til andre systemer/støttesystemer skal støttesystemet Adgangsstyring for systemer være tilgængeligt For bruger adgang til brugervendte systemer skal støttesystemet Adgangsstyring for brugere være tilgængeligt. Desuden forventes det at informationer om klassifikationer og deres relationer vil tage udgangspunk i de informationer, der findes i Støttesystemet Klassifikation, samt at informationer til brug for sagsplacering tager udgangspunkt i informationer fra Støttesystemet Organisation. M-03 - Integration til Støttesystemet Sags- og Dokumentindeks Integrationen til Sags- og Dokumentindeks består af to typer af servicesnitflader begge udstillet på Serviceplatformen Forespørgselsservice, som er synkron service, se I Synkrone services Opdateringsservice, som er en asynkron service af typen I Serviceintegration med forretningskvittering Der er desuden mulighed for at forespørge og opdatere indeks via en batch integration, som bør anvendes ved ud- og indlæsning af store datamængder. Integration til og anvendelse af Støttesystemet Sags- og Dokumentindeks er i øvrigt beskrevet i de gældende integrationsvilkår for systemet, hvorfor der henvises hertil Se: Det er et mål at der på længere sigt kan anvendes beskeder til løbende opdatering af indekset. Derfor er der behov for at både anvendersystemerne kan understøtte at afsende og modtage beskeder via Støttesystemet Beskedfordeler, se I-01 - Integration via beskeder. 18

SNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser

SNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser SNITFLADER TIL INDEKSER Præsentation af de fælleskommunale støttesystemernes snitflader til indekser Introduktion Fokus At give et overblik over: Integration til indekserne Forudsætninger for integration

Læs mere

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

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA 26. marts 2014 NOTAT SAPAs forretningsmæssige behov i relation til Dialogintegration Dette notat beskriver SAPAs specifikke forretningsmæssige behov i forhold til integration med relevante ESDH-/fagsystemer,

Læs mere

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014 Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,

Læs mere

Introduktion til Klassifikation

Introduktion til Klassifikation Introduktion til Klassifikation 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Klassifikation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af

Læs mere

Støttesystemerne. Det er tid til

Støttesystemerne. Det er tid til 1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare

Læs mere

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder kommunerne i det

Læs mere

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,

Læs mere

Introduktion til Støttesystem Organisation

Introduktion til Støttesystem Organisation Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse

Læs mere

Klik her for at angive tekst.

Klik her for at angive tekst. 30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav

Læs mere

Vilkår for Dialogintegration

Vilkår for Dialogintegration Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer

Læs mere

MØDE OM JOBCENTER- RELATEREDE SNITFLADER

MØDE OM JOBCENTER- RELATEREDE SNITFLADER MØDE OM JOBCENTER- RELATEREDE SNITFLADER 20. og 21. maj 2014 Dagsorden 1. Præsentation af deltagerne Jesper Bo Seidler 2. Formaliteter omkring indgåelse af aftaler Iver Winther 3. Præsentation af Jobcenter

Læs mere

MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015

MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015 MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015 Introduktion ERP-leverandører har været med i afklarings- og specificeringsforløb siden 2013. Der vil være gentagelser og opsummeringer

Læs mere

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks 23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

Læs mere

Vilkår for integration til SAPA Dialogintegration

Vilkår for integration til SAPA Dialogintegration Vilkår for integration til SAPA Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/5 Dokumenthistorik Dato Version Ansvarlig

Læs mere

Introduktion til Støttesystem Ydelsesindeks

Introduktion til Støttesystem Ydelsesindeks Introduktion til Støttesystem 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af hvilke komponenter,

Læs mere

SAPA S BETYDNING FOR ESDH. IMPULS 2015, 17. september 2015 Kenneth Møller Johansen

SAPA S BETYDNING FOR ESDH. IMPULS 2015, 17. september 2015 Kenneth Møller Johansen SAPA S BETYDNING FOR ESDH IMPULS 2015, 17. september 2015 Kenneth Møller Johansen I dag 1. Kort om KOMBIT 2. KMD Sag: Monopolbrud hvordan? 3. Samspil med ESDH-systemer 4. Hvad gør kommunerne nu? 5. Etablering

Læs mere

Integration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0

Integration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0 Integration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer

Læs mere

Introduktion til Støttesystemet Beskedfordeler

Introduktion til Støttesystemet Beskedfordeler Introduktion til Støttesystemet 1. Om dokumentet Dette dokument formidler et overblik over brugen af den fælleskommunale. Formålet er at give læseren en forståelse af, de væsentligste begreber, forudsætninger

Læs mere

Vilkår for dialogintegration SAPA

Vilkår for dialogintegration SAPA Vilkår for dialogintegration SAPA Klaus Rasmussen 26. oktober 2016 Indhold 1. Indledning og vejledning... 3 1.1 Definitioner... 4 2. Krav til it-systemer for at kunne udføre dialogintegration... 5 2.1

Læs mere

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem Arkitekturrapport: Kommunernes Ydelsessystem 1 Indholdsfortegnelse Baggrund for projekt... 3 Resultat af gennemført arkitekturanalyse... 5 Anvendelse af forretningsservices... 9 Baggrund for projekt Baggrund

Læs mere

KOMBITS TILGANG TIL ARKITEKTUR ER ENKEL

KOMBITS TILGANG TIL ARKITEKTUR ER ENKEL KOMBITS TILGANG TIL ARKITEKTUR ER ENKEL KOMBIT s EA rammeværk KL Fundament Digitaliseringsstrategi Arkitekturmål Arkitekturprincipper Brug Måling, evaluering og opfølgning Undervisning og gå-hjem møder

Læs mere

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan Anvendersystemer afsender og/eller modtager objekter til/fra

Læs mere

Vilkår vedrørende anvendelsen af Støttesystemet Organisation

Vilkår vedrørende anvendelsen af Støttesystemet Organisation Vilkår vedrørende anvendelsen af Støttesystemet Organisation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Organisation,

Læs mere

Fælleskommunal infrastruktur - SAPA-seminar, marts Michel Sassene, KOMBIT

Fælleskommunal infrastruktur - SAPA-seminar, marts Michel Sassene, KOMBIT Fælleskommunal infrastruktur - SAPA-seminar, marts 2014 Michel Sassene, KOMBIT Agenda 1. Hvorfor fælleskommunal infrastruktur? 2. Hvad kan man med infrastrukturen? 3. Brug af infrastrukturen i kommunen

Læs mere

Generelt om støttesystemerne

Generelt om støttesystemerne Generelt om støttesystemerne Dette afsnit giver et overblik over de enkelte støttesystemer der indgår i Rammearkitekturen. For yderligere information henvises til de udarbejdede kravspecifikationer. Støttesystemerne

Læs mere

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 13.10.2014 Fælles it-arkitekturstyring

Læs mere

Læsevejledning til review af støttesystemer, marts 2013

Læsevejledning til review af støttesystemer, marts 2013 Læsevejledning til review af støttesystemer, marts 2013 Kommunerne ønsker en fælleskommunal rammearkitektur, der kan understøtte digitaliseringen og åbne for konkurrence på det kommunale it-marked. Rammearkitekturen

Læs mere

SAPA OG STØTTESYSTEMERNE. V/ projektleder Kenneth Møller Johansen

SAPA OG STØTTESYSTEMERNE. V/ projektleder Kenneth Møller Johansen SAPA OG STØTTESYSTEMERNE V/ projektleder Kenneth Møller Johansen I dag 1. KMD Sag: Konkurrence hvordan? 2. Kort om SAPA og om Støttesystemerne 3. Samspil med kommunernes sagsbærende løsninger 4. Hvad gør

Læs mere

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4

Læs mere

KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer og

KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer og KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer 11-03-15 og 12-03-15 Hvem er jeg? Denny Christensen Chefkonsulent og IT Arkitekt i KOMBIT Har været teamlead og skribent på bla. kravspecifikationerne

Læs mere

Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere

Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere 1 Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere Tre af de otte Støttesystemer 2 Kombit Støttesystemerne Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring

Læs mere

Sags- og Dokumentindeks og Ydelsesindeks

Sags- og Dokumentindeks og Ydelsesindeks Støttesystemet Sags- og Dokumentindeks og Ydelsesindeks 1 Sags- og Dokumentindeks og Ydelsesindeks To af de otte Støttesystemer 2 Kombit Støttesystemerne Sags- og Dokumentindeks og Ydelsesindeks Hvad er

Læs mere

WORKSHOP DIALOGINTEGRATION OG JOURNALNOTAT. HK-huset, onsdag d. 3. april

WORKSHOP DIALOGINTEGRATION OG JOURNALNOTAT. HK-huset, onsdag d. 3. april WORKSHOP DIALOGINTEGRATION OG JOURNALNOTAT HK-huset, onsdag d. 3. april Agenda Velkomst og agenda (5 min.) Kort om SAPAs behov (7 min.) Workshop 1: Dialogintegration - KOMBIT præsentation (10 min.) - Tech-Swat-Teams:

Læs mere

Støttesystemet Beskedfordeler. Beskedfordeler Et af de otte Støttesystemer

Støttesystemet Beskedfordeler. Beskedfordeler Et af de otte Støttesystemer Støttesystemet 1 Et af de otte Støttesystemer 2 Kombit Støttesystemet Hvad er Støttesystemet Beskedefordeler? Abonnér på beskeder om forretningsmæssige hændelser Støttesystemet er det centrale beskedsystem,

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

SAPA Kommunenetværk Øst & Vest. KMJ 28. august 2013, Værløse 29. August 2013, Middelfart

SAPA Kommunenetværk Øst & Vest. KMJ 28. august 2013, Værløse 29. August 2013, Middelfart SAPA Kommunenetværk Øst & Vest KMJ 28. august 2013, Værløse 29. August 2013, Middelfart P R O J E K T S T A T U S 1. Kravspecifikation A. Kommuner B. Leverandører 2. Faglige afklaringer i workshops 3.

Læs mere

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt.

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. 8. april 2013 19-Partskontakt => Kontaktdata Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. I de oprindelige oplæg med visionen

Læs mere

Arkitekturrapport: Digitalisering på Handicap- og Udsatte Voksne-området

Arkitekturrapport: Digitalisering på Handicap- og Udsatte Voksne-området Arkitekturrapport: Digitalisering på Handicap- og Udsatte Voksne-området Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af

Læs mere

Integration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1

Integration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1 Integration Integrationsbeskrivelse - version 0.1 rnes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 201n-nn-nn xxx 0.1 Første version Referencer Ref Titel Kommentarer

Læs mere

SAPA KRAVSPECIFIKATION v. 0.8. Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL

SAPA KRAVSPECIFIKATION v. 0.8. Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL SAPA KRAVSPECIFIKATION v. 0.8 Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL Sags- og partsoverblikket Vise adresser der har adressebeskyttelse Adressen

Læs mere

Støttesystemet Klassifikation. Klassifikation. Et af de otte Støttesystemer

Støttesystemet Klassifikation. Klassifikation. Et af de otte Støttesystemer 1 Et af de otte Støttesystemer 2 Kombit Støttesystemet Hvad er Støttesystemet? Håndtering af alle typer klassifikationer i samme system Støttesystemet er et centralt register for de klassifikationer, som

Læs mere

Acadre-integration til SAPA

Acadre-integration til SAPA Løsningsbeskrivelse Leverandør: Formpipe Software A/S Borupvang 5D DK-2750 Ballerup CVR nr. 29177015 Indholdsfortegnelse 1.0 Acadre-integration til SAPA... 1 1.1 Overordnet beskrivelse... 1 1.2 Detaljeret

Læs mere

STS NETVÆRKSDAGE. Spor 3: Beskedfordeler. 11. og 12. marts 2015. Christian Callsen

STS NETVÆRKSDAGE. Spor 3: Beskedfordeler. 11. og 12. marts 2015. Christian Callsen STS NETVÆRKSDAGE Spor 3: Beskedfordeler 11. og 12. marts 2015 Christian Callsen SPOR: BESKEDFORDELER PRÆSENTERES AF: Christian Callsen, KOMBIT (ekstern) BAGGRUND: It-arkitekt, bl.a. speciale i hændelsesorientering

Læs mere

BESKEDFORDELER OG BESKEDER. Den fælleskommunale Beskedfordeler

BESKEDFORDELER OG BESKEDER. Den fælleskommunale Beskedfordeler BESKEDFORDELER OG BESKEDER Den fælleskommunale Beskedfordeler KOMBITS MISSION ER AT SAMLE KOMMUNERNE OM FÆLLES IT- LØSNINGER, DER FREMMER EFFEKTIVITET OG KVALITET Dagens tekst Monopolbrud og Rammarkitektur

Læs mere

Underbilag 2O Beskedkuvert Version 2.0

Underbilag 2O Beskedkuvert Version 2.0 Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...

Læs mere

Vilkår vedrørende brug af Støttesystemet Adgangsstyring

Vilkår vedrørende brug af Støttesystemet Adgangsstyring Vilkår vedrørende brug af Støttesystemet Adgangsstyring 1. Indledning Nærværende vejledning beskriver, hvordan it-systemer skal anvender Adgangsstyring i rammearkitekturen såvel dynamisk som i den daglige

Læs mere

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013 Opsamling på kommunal høring Vejle & Roskilde Den 18. Juni 2013 Dagsorden Velkommen Høringsprocessen frem til udbuddet på KY Resultater fra høringen Udbudsmaterialet kapitel 1 4, 5 og 6 Temaer: EDSH, opgavelisten,

Læs mere

Arkitekturrapport: KITOS - Kommunens It-Overbliks System

Arkitekturrapport: KITOS - Kommunens It-Overbliks System Arkitekturrapport: KITOS - Kommunens It-Overbliks System Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt.

Læs mere

SAPA - spørgsmål & svar for beslutningstagere

SAPA - spørgsmål & svar for beslutningstagere SAPA - spørgsmål & svar for beslutningstagere Erstatter vi ikke bare et monopol med et andet? Nej. Vi vil kombinere en række forskellige nye og eksisterende it-løsninger, som hver især kræver flere forskellige

Læs mere

Bilag 2. Vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale Rammearkitektur Version 2.0

Bilag 2. Vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale Rammearkitektur Version 2.0 Bilag 2 Vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale Rammearkitektur Version 2.0 1 Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer integrerer til og anvender

Læs mere

SF 2800 Fordelingskomponent - Modtag objekter Integrationsbeskrivelse - version 2.0.0

SF 2800 Fordelingskomponent - Modtag objekter Integrationsbeskrivelse - version 2.0.0 SF 2800 Fordelingskomponent - Modtag objekter Integrationsbeskrivelse - version 2.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-03-03 MVC 0.1 Første

Læs mere

KOMBITS UDMØNTNING AF RAMMEARKITEKTUREN. V/ Chefkonsulent Morten Hass

KOMBITS UDMØNTNING AF RAMMEARKITEKTUREN. V/ Chefkonsulent Morten Hass KOMBITS UDMØNTNING AF RAMMEARKITEKTUREN V/ Chefkonsulent Morten Hass Tre budskaber Rammearkitekturen er kommunernes fælles krav og infrastruktur Hvert fælles projekt udbygger rammearkitekturen Når ny fælles

Læs mere

/marius hartmann Integrationskrav 2. Logningskrav 3. Konsekvenser for kommunen

/marius hartmann Integrationskrav 2. Logningskrav 3. Konsekvenser for kommunen /marius hartmann maha31@frederiksberg.dk 20141002 Ang./ Vilkår for integration til støttesystemet Sags- og Dokumentindeks version 1.3 Denne fælleshenvendelse, som dækker it-arkitekterne fra Ballerup, Odense,

Læs mere

KOMBITs arbejde med it-arkitektur

KOMBITs arbejde med it-arkitektur KOMBITs arbejde med it-arkitektur Fælleskommunal rammearkitektur Mette Kurland, KOMBIT 29.09.2011 KOMBIT/Fælleskommunal rammerarkitektur 1 Rammearkitektur ift. KOMBITs mission Forhandlingskraft Effektivisering

Læs mere

Arkitekturrapport: Kommunernes Sygedagpengesystem

Arkitekturrapport: Kommunernes Sygedagpengesystem Bilag 3: Arkitekturraport KSD. (Bilag til dagsordenspunkt 7: Arkitekturrapport for Kommunernes Syge-Dagpenge system (KSD)). Arkitekturrapport: Kommunernes Sygedagpengesystem Denne orienteringsrapport udarbejdes

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013Klik her for at angive tekst. NOTAT Bilag 11: Anvenderkrav til adgangsstyring - Støttesystemerne Context handler, Security Token Service og Administrationsmodul (Bilag til dagsordenspunkt

Læs mere

ADGANG TIL EGEN SAG ADGANG TIL EGEN SAG. Integration til Borger.dk baseret på fælleskommunal infrastruktur

ADGANG TIL EGEN SAG ADGANG TIL EGEN SAG. Integration til Borger.dk baseret på fælleskommunal infrastruktur ADGANG TIL EGEN SAG ADGANG TIL EGEN SAG Integration til Borger.dk baseret på fælleskommunal infrastruktur Tema Side 2 af 7 Indholdsfortegnelse Formål...3 Muligheder for at udstille data...3 SAPA og den

Læs mere

1 Begrebsmodel for Ydelsesindeks

1 Begrebsmodel for Ydelsesindeks 1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående

Læs mere

NETVÆRKSDAGE MARTS 2015. Michel Sassene

NETVÆRKSDAGE MARTS 2015. Michel Sassene NETVÆRKSDAGE MARTS 2015 Michel Sassene Emner Baggrund Ibrugtagning af Støttesystemerne Hvorfor dette initiativ? Dialog og opfølgning Status på udviklingsprojektet BAGGRUND Lidt historie I forbindelse med

Læs mere

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere

Aftale med KMD om udfasning af KMD Sag

Aftale med KMD om udfasning af KMD Sag 30. april 2014 KMJ NOTAT Aftale med KMD om udfasning af KMD Sag 1. Om dette notat Dette notat er udarbejdet som orientering til kommunerne og distribueres til alle kommuners lokalt udpegede kontaktperson

Læs mere

SPOR 2 ADGANGSSTYRING. Netværksdage Støttesystemer 11. og 12. marts 2015

SPOR 2 ADGANGSSTYRING. Netværksdage Støttesystemer 11. og 12. marts 2015 SPOR 2 ADGANGSSTYRING Netværksdage Støttesystemer 11. og 12. marts 2015 Hvem er jeg? Rasmus H. Iversen Teknisk Projektleder Teamlead på sikkerhed Har været på STS projektet helt fra starten Mål for dagens

Læs mere

Baggrundsinformation

Baggrundsinformation 1. Begreber Baggrundsinformation Sags- og Dokumentindekset skal indeholde sags- og dokumentmetadata, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres

Læs mere

Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0

Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0 Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-10-

Læs mere

DECEMBER Vejledning til kommunens snitfladestrategi

DECEMBER Vejledning til kommunens snitfladestrategi DECEMBER 2016 Vejledning til kommunens snitfladestrategi Dette notat introducerer arbejdet med kommunens snitfladestrategi. Snitfladestrategien beskriver kommunens strategiske beslutninger vedr. snitflader

Læs mere

Fællesoffentlig beskedmodel version 1.0

Fællesoffentlig beskedmodel version 1.0 Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles

Læs mere

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Klik her for at angive tekst. Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Krav og vejledning til

Læs mere

Integration SF1570 - SKAT R75 Integrationsbeskrivelse - version 2.0.0

Integration SF1570 - SKAT R75 Integrationsbeskrivelse - version 2.0.0 Integration Integrationsbeskrivelse - version 2.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-10-06 DGJ 0.1 Første version 2015-06-29 JJN 0.2 Referencerettelser

Læs mere

Introduktion til Den fælleskommunale Rammearkitektur

Introduktion til Den fælleskommunale Rammearkitektur Introduktion til Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Version 1.3 1. Introduktion Den fælleskommunale Rammearkitektur er et løbende udviklingsarbejde, hvor

Læs mere

Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform

Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform Version 1.0, september 2013 Den fælleskommunale Serviceplatform Ved årsskiftet 2013/14 åbner Den fælleskommunale Serviceplatform

Læs mere

STØTTESYSTEMERNE NØGLEN TIL NYE MULIGHEDER OG FREMTIDENS SAGSBEHANDLING

STØTTESYSTEMERNE NØGLEN TIL NYE MULIGHEDER OG FREMTIDENS SAGSBEHANDLING Bilag 8 seneste version af grundfortællingen Pkt. 11 Grundfortælling om støttesystemer STØTTESYSTEMERNE NØGLEN TIL NYE MULIGHEDER OG FREMTIDENS SAGSBEHANDLING 1 HISTORIEN BAG STØTTESYSTEMERNE KMD har monopol

Læs mere

Arkitekturrapport: SAPA

Arkitekturrapport: SAPA Arkitekturrapport: SAPA Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt. Det er projektlederens ansvar

Læs mere

Den fælleskommunale Rammearkitektur

Den fælleskommunale Rammearkitektur Høringsversion, Publiceret 4. november 2013 Bilag 2: Introduktion til den fælleskommunale rammearkitektur. Bilag til dagsordenspunkt 7: Arkitekturfaglig introduktion til rammearkitekturen. Introduktion

Læs mere

Bilag 3A.6 Integrationer

Bilag 3A.6 Integrationer Bilag 3A.6 Integrationer Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 2.1 BILAGETS FORMÅL OG OPBYGNING... 4 2.2 RELATION TIL ØVRIGT MATERIALE... 4 3 INTEGRATIONSBESKRIVELSER...

Læs mere

SAPAs kravspecifikation Læsevejledning. KMJ, 19. marts 2013

SAPAs kravspecifikation Læsevejledning. KMJ, 19. marts 2013 SAPAs kravspecifikation Læsevejledning KMJ, 19. marts 2013 Udbudsmaterialets kontrakter og bilag Øvrige bilag A.Ordliste B.Begrebs- og Informationsmodel C.Snitflader (STS og SP) D.Udrulningsbistand E.Overgangsløninger

Læs mere

SAPA. Kommunenetværk. KMJ, d. 24. november 2013

SAPA. Kommunenetværk. KMJ, d. 24. november 2013 SAPA Kommunenetværk KMJ, d. 24. november 2013 P R O J E K T S T A T U S 1. Integrationer til sagsbærende it-systemer 2. Kravspecifikation for SAPA 3. Interessenterne 4. Tidsplan 2 1. Se data fra sagssystemer

Læs mere

Krav og vejledning til kommunernes fremtidige it-udbud

Krav og vejledning til kommunernes fremtidige it-udbud Klik her for at angive tekst. Krav og vejledning til kommunernes fremtidige it-udbud I forbindelse med det forestående monopolbrud udarbejder KOMBIT i samarbejde med kommunerne en trin-for-trin drejebog,

Læs mere

Automatisering og datakvalitet i it-systemer

Automatisering og datakvalitet i it-systemer RIGSARKIVETS KONFERENCE 2017 - KVALITET I OFFENTLIGE FORVALTNINGSDATA Automatisering og datakvalitet i it-systemer Hvad betyder kvaliteten, når borgeren skal have adgang til egne sager? Henrik Brix, Favrskov

Læs mere

SPOR 2. Opgaveoverblik på Støttesystemerne

SPOR 2. Opgaveoverblik på Støttesystemerne SPOR 2 Opgaveoverblik på Støttesystemerne Det kommunale systemlandskab Det kommunale systemlandskab Adgangsstyring for brugere i forhold til, og SAPA SAPA Bruger Log på Kommune Bruger + Job funktions roller

Læs mere

Fælles kommunal rammearkitektur og konkrete støttesystemer

Fælles kommunal rammearkitektur og konkrete støttesystemer Fælles kommunal rammearkitektur og konkrete støttesystemer KL/Kombit og Kommunerne hvad er Kombit? KOMBIT er kommunernes it-fællesskab, hvis forretningsområde er kommunal it og digitalisering. KOMBIT bestiller

Læs mere

Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler

Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7 Etablering af datadistribution på den Fællesoffentlige Datafordeler Version: 0.8 Status: udkast Oprettet: 10.3.2014 Dato: 16. juni 2014 Dokument historie

Læs mere

DAGORDEN FOR MØDE MED ERP LEVERANDØRER 27. AUGUST. Iver Winther

DAGORDEN FOR MØDE MED ERP LEVERANDØRER 27. AUGUST. Iver Winther DAGORDEN FOR MØDE MED ERP LEVERANDØRER 27. AUGUST Iver Winther Dagorden Velkommen Status på ØiR Tilpasning og udvikling af indhold af snitflader Justeret integrationsarkitektur Den videre proces Formålet

Læs mere

BILAG 2 Kravspecifikation

BILAG 2 Kravspecifikation BILAG 2 Kravspecifikation Instruktion til Tilbudsgiver Nærværende bilag, samt underbilag 2A-2R, udgør Kravspecifikationen. Tilbudsgiver skal ikke udfylde nærværende bilag, men besvare bilaget ved at udfylde

Læs mere

Axapoint Reviewkommentar til MOX-specifikation Version 0.76 - udarbejdet af It-arkitekturrådets arbejdsgruppe

Axapoint Reviewkommentar til MOX-specifikation Version 0.76 - udarbejdet af It-arkitekturrådets arbejdsgruppe Axapoint ApS Brunhøjvej 8, st. tv DK-8680 Ry Tel. +45 23 10 83 44 CVR nr. 32 15 37 98 info@axapoint.com www.axapoint.com Bank: Danske Bank. www.axapoint.com MOX-review Axapoint Reviewkommentar til MOX-specifikation

Læs mere

LoRA lokal rammearkitektur. Marius Hartmann, Frederiksberg Kommune Leif Lodahl, Magenta

LoRA lokal rammearkitektur. Marius Hartmann, Frederiksberg Kommune Leif Lodahl, Magenta LoRA lokal rammearkitektur Marius Hartmann, Frederiksberg Kommune Leif Lodahl, Magenta Hvad er lokal rammearkitektur Frederiksberg Kommune, KL og Magenta om udvikling af en referenceimplementering af rammearkitekturen.

Læs mere

Integration SF1320_A - CPR - Hændelser Integrationsbeskrivelse - version 2.0.2

Integration SF1320_A - CPR - Hændelser Integrationsbeskrivelse - version 2.0.2 Integration Integrationsbeskrivelse - version 2.0.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-01-10 PBO 0.1 Første version kopieret fra gammel skabelon

Læs mere

Informationsmateriale til leverandørerne om. Den fælleskommunale Serviceplatform Version 1.1, december 2013

Informationsmateriale til leverandørerne om. Den fælleskommunale Serviceplatform Version 1.1, december 2013 Informationsmateriale til leverandørerne om Den fælleskommunale Serviceplatform Version 1.1, december 2013 Den fælleskommunale Serviceplatform Fra 1.januar 2014 åbner den fælleskommunale Serviceplatform

Læs mere

Ofte stillede spørgsmål til SAPA-løsningen

Ofte stillede spørgsmål til SAPA-løsningen Ofte stillede spørgsmål til SAPA-løsningen Emner Funktionalitet... 2 Advis... 5 LIS... 5 Lovgivning/Arkivering... 5 SAPA App Shop... 6 Snitflader... 6 Brugervenlighed... 9 Aktører og Roller... 9 Sikkerhed...

Læs mere

SAPA PÅ KOMMUNEDAGE. November Kenneth Møller Johansen

SAPA PÅ KOMMUNEDAGE. November Kenneth Møller Johansen SAPA PÅ KOMMUNEDAGE November 2014 Kenneth Møller Johansen Person- og sagsoverblik SAPA Overblik SAPA Advis Sagsbehandling og sagsstyring Sagsbærende løsninger (Fagsyst. & ESDH) Infrastruktur Legacy (KMD

Læs mere

Udarbejdelse af strategier for hændelsesorientering

Udarbejdelse af strategier for hændelsesorientering Udarbejdelse af strategier for hændelsesorientering En vejledning til kommunernes og ATP s opgaver Version 1.0 februar 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

Læs mere

ESDH-strategi. Sag og Dokument/ESDH anbefalinger til udarbejdelse af lokal strategi i kommunen

ESDH-strategi. Sag og Dokument/ESDH anbefalinger til udarbejdelse af lokal strategi i kommunen ESDH-strategi Sag og Dokument/ESDH anbefalinger til udarbejdelse af lokal strategi i kommunen Indhold Indledning og baggrund for værktøjet 3 Strategiens scope, formål og målsætninger 4 Understøttelse af

Læs mere

N O TAT. Udkast til: KL s politik på sags- og dokumentområdet. Anbefalinger i KL s politik på sags- og dokumentområdet

N O TAT. Udkast til: KL s politik på sags- og dokumentområdet. Anbefalinger i KL s politik på sags- og dokumentområdet N O TAT Udkast til: KL s politik på sags- og dokumentområdet Kommunernes politik på sags og dokumentområdet støtter kommunerne i at træffe de rigtige beslutninger om valg af it-løsninger til sags- og dokumenthåndtering,

Læs mere

Kolonnen indikerer, hvornår KOMBITs monopolbrudsprojekter KY, KSD, SAPA og STS forventes at kunne gå i produktion med den pågældende snitflade.

Kolonnen indikerer, hvornår KOMBITs monopolbrudsprojekter KY, KSD, SAPA og STS forventes at kunne gå i produktion med den pågældende snitflade. Læsevejledning Kolonnen Klar til produktion for monopolbrudsprojekterne Kolonnen indikerer, hvornår KOMBITs monopolbrudsprojekter KY, KSD, SAPA og STS forventes at kunne gå i produktion med den pågældende

Læs mere

Arkitekturrapport: Ejendomsskatte- og Ejendomsbidragsløsningen. Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af

Arkitekturrapport: Ejendomsskatte- og Ejendomsbidragsløsningen. Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af Arkitekturrapport: Ejendomsskatte- og Ejendomsbidragsløsningen Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapporten ejes af projektets

Læs mere

Fælleskommunale it-arkitekturprincipper

Fælleskommunale it-arkitekturprincipper Fælleskommunale it-arkitekturprincipper Pr. 5. september 2012 Af arbejdsgruppen for fælleskommunale itarkitekturprincipper under Kommunernes It-Arkitekturråd Side 1 af 24 IndholdIndhold... 2 Baggrund...

Læs mere

Arkitekturrapport: YDELSESREFUSION

Arkitekturrapport: YDELSESREFUSION Arkitekturrapport: YDELSESREFUSION Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets arkitekt (Erling Hansen).

Læs mere

Løsningsbeskrivelse til P13-7 Hent ydelsesinformationer fra Ydelsesindeks

Løsningsbeskrivelse til P13-7 Hent ydelsesinformationer fra Ydelsesindeks Løsningsbeskrivelse til P13-7 Hent ydelsesinformationer fra Ydelsesindeks Dokument-nr.: Version: V2.3 Forfatter: CE/PSZ/CVS Versionsdato: 15.022.2016 Side 1 af 11 Versionsoversigt Version Dato Oprettet

Læs mere

Overblik over roller og kompetencer i forhold til Støttesystemerne

Overblik over roller og kompetencer i forhold til Støttesystemerne Overblik over roller og kompetencer i forhold til ne En vejledning til kommunernes og ATP s opgaver Version 1.0.1 maj 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

Læs mere

KMD Sag II udfasningsassistance. Bilag G: Grænsefladedokumentation til KMD Sag. Dokumentet er udarbejdet af KMD. Version 2.1.

KMD Sag II udfasningsassistance. Bilag G: Grænsefladedokumentation til KMD Sag. Dokumentet er udarbejdet af KMD. Version 2.1. KMD Sag II udfasningsassistance Bilag G: Grænsefladedokumentation til KMD Sag Dokumentet er udarbejdet af KMD Version 2.1 Side 1 af 14 Indhold KMD Sag II udfasningsassistance... 1 Bilag G: Grænsefladedokumentation

Læs mere

Data og rammearkitektur på beskæftigelsesområdet

Data og rammearkitektur på beskæftigelsesområdet R E SULTATKONTRAKT Data og rammearkitektur på beskæftigelsesområdet (2.1) Kommunerne ønsker at levere en langt mere effektiv beskæftigelsesindsats, både mere effektiv i betydningen af bedre målopfyldelse

Læs mere