Grunddatabeskedmodel version 1.0
|
|
- Tobias Jørgensen
- 8 år siden
- Visninger:
Transkript
1 Grunddatabesked Side: 1 Grunddatabeskedmodel version 1.0 Grunddata-besked version 1.0 Beskedformatet er det samme for både beskeder, som genereres af datafordeleren på basis af data-opdateringer fra registrene, og de beskeder som sendes direkte fra registrene til beskedfordeleren. Datafordeleren vil ikke kunne udfylde alle felter, men beskedens krævede felter udfyldes af alle. Besked - Datamodel Her beskrives beskeden uden den omsluttende arkitektur af abonnement og dataprocesser. Disse findes i Referencearkitekturen og i informationsmodellen, som følger med det fællesoffentlige beskedformat.
2 Grunddatabesked Side: 2
3 Grunddatabesked Side: 3 Hændelsesbesked Besked om en forretningshændelse. Dette er hovedobjektet, som samler de andre dele af beskeden Data leveres af kildesystemet (1) Beskedkuvert (1) Hændelsesbesked (0..*) Beskeddata (1) Hændelsesbesked Beskedkuverten indgår i Hændelsesbesked med det formål, at opbevare eksternt rettet filtreringsinformation, som beskedfordeleren kan anvende til abonnementsfiltrering Beskeddata kan indgå i Hændelsesbeskeden med det formål at transportere data sammen med beskeden Attribut Krav Type Datafordelerudfyldelse beskedid «krævet» HTTP-URI Beskedens unikke identifikation beskedversion «krævet» literal Versionsnummer for beskedmodellen/skemaet Et tal af formen major.minor Eksempel: 1.2 Genereres af Systemet Version indsættes af Systemet. Beskeddata "Payload", som forsendes indlejret i beskeden. Ikke synligt for beskedfordeleren. Kan altså ikke bruges til abonnementsfiltrering. I Grunddata er den primære måde at knytte data til hændelsesbeskeden en objektreference i klassen Objektregistrering - Grunddatas dataobjekter er jo tilgængelige og unikt refererbare gennm Datafordeleren. Payload anvendes kun undtagelsesvis 0 til mange "bilag" kan medsendes pr besked (beskedfordelere kan sætte begrænsninger for beskedstørrelse).
4 Grunddatabesked Side: 4 Hvert bilagsobjekt er enten en reference til et dataobjekt eller et indlejeret dataobjekt. Data leveres af kildesystemet. (0..*) Beskeddata (1) Hændelsesbesked (1) Objektreference kan være (1) Beskeddata (1) Objektdata kan være (1) Beskeddata Beskeddata kan indgå i Hændelsesbeskeden med det formål at transportere data sammen med beskeden Beskeddata kan repræsenteres ved en objektreference Beskeddata kan være indlejret i beskeden Objektdata Hvis dataobjekter medsendes, består de dels af et pakket data-objekt, dels af en reference til et dataskema, som forklarer deres struktur for modtageren. Objektdata kan kun være medsendt, hvis Objektreference er tom. Data leveres af kildesystemet. (1) Objektdata kan være (1) Beskeddata Beskeddata kan være indlejret i beskeden Attribut Krav Type Datafordelerudfyldelse dataskema «krævet» HTTP-URI (Klassifikation ) Reference til information om bilaget (et dataskema samt semantik), som skal gøre det muligt for modtageren at anvende dette - opbevares i en klassifikationsservice og følger ikke nødvendigvist en Link til skema for objektdata (som specificieret i DLS) indsættes af systemet. Udfyldes kun, hvis objektet indsættes.
5 Grunddatabesked Side: 5 bredt kendt specifikation objektdata «krævet» BLOB Bilaget som sådan - som indlejrede data Kan kun være udfyldt hvis objektreference er tom Genereres og indsættes på baggrund af XSD i DLSen Et Binary Large OBject (BLOB) eller med andre ord hvadsomhelst Fortolkning af objektet baserer sig på dataskema samt en eventuel bilateral aftale mellem afsender og modtager - not the Grunddata-way Objektreference Det medsendte objekt kan repræsenteres ved en objektreference. Data leveres af kildesystemet. (1) Objektreference kan være (1) Beskeddata Beskeddata kan repræsenteres ved en objektreference Attribut Krav Type Datafordelerudfyldelse objektreference «krævet» HTTP-URI (objektregistr ering) Reference til eksternt dataobjekt Kan kun være udfyldt hvis Objektdata er tom Link til objektet, hvis selve objektet ikke indsættes Beskedkuvert Beskedkuverten indeholder informationer til udvælgelse og levering af beskeder.
6 Grunddatabesked Side: 6 Bemærkning: Beskedfordelere kan udelukkende læse indholdet af beskedkuverten og anvender dette indhold til at udvælge de beskeder, som matcher de opsatte abonnementer. Indholdet kan dog samtidig anvendes til behandling af beskeden hos beskedmodtageren I Grunddata er kun et fåtal af attributterne obligatoriske, men generelt gælder det, at jo flere felter, der udfyldes, jo mere finkornede abonnementsudtryk er det muligt at udstille Data leveres! (1) Beskedkuvert (1) Hændelsesbesked Beskedkuverten indgår i Hændelsesbesked med det formål, at opbevare eksternt rettet filtreringsinformation, som beskedfordeleren kan anvende til abonnementsfiltrering (0..1) Modtagerhandling (1) Beskedkuvert (1) Filtreringsdata (1) Beskedkuvert (1) Leveranceinformation (1) Beskedkuvert Filtreringsdata indgår i Beskedkuvert for at kunne anvendes til abonnementsfiltrering og til beskedevaluering Beskedens Leveranceinformationer indgår i beskedkuverten - disse danner baggrund for håndtering og logning Modtagerhandling Modtagerhandling samler beskedafsenderens angivelser af, hvilke procestrin, der skal initieres hos beskedmodtageren I Grunddata etableres en web-service, som kan kontaktes med beskedid, som en kvittering for modtagelse af beskeden Data leveres af kildesystemet
7 Grunddatabesked Side: 7 (0..1) Modtagerhandling (1) Beskedkuvert Attribut Krav Type Datafordelerudfyldelse handling «valgfri» HTTP- URI(Klassifikat Afsenderens krav til modtagerens handling, når indholdet i bekeden er modtaget eller behandlet. Feltet er en reference til et sæt af handlingsbeskrivelser - udstillet på en klassifikationsservice - som sætter modtageren i stand til at udføre den ønskede handling Eksempler på handlinger: "Afgiv kvittering for modtagelse" "fortsæt med procestrin x" I første omgang er det kun anmodning om kvittering for modtagelsen, der er kendt som ønsket handlingsudfald. Der kan dog på sigt komme andre handlinger, så en løs kobling vil være at foretrække frem for hardcoding. responsmodtager «valgfri» HTTP- URI(Aktør) Angivelse af den aktør, som skal modtage out-put (fx en kvittering) af "handling" Reference til en aktør i en organisationskomponent Bør indeholde en komplet URL til kvitteringsservicen inkl. beskedid og/eller evt. andre relevante oplysninger, som den skal kaldes med for at kvittere for en besked. Filtreringsdata Filtreringsdata indeholder de data som er nødvendige for at kunne dels evaluere beskeden i forhold til et abonnementsudtryk (i Beskedfordeleren), dels evaluere beskedens relevans hos Beskedmodtageren, for derefter eventuelt at initiere en forretningsproces Data leveres af kildesystemet (1) Filtreringsdata Filtreringsdata indgår i Beskedkuvert for at kunne anvendes til abonnementsfiltrering og til beskedevaluering
8 Grunddatabesked Side: 8 (1) Beskedkuvert (0..*) RelateretObjekt indgår i (1) Filtreringsdata (0..*) Objektregistrering (1) Filtreringsdata Beskeden kan indeholde referencer til andre forretningsobjekter, som ikke er ændrede i forbindelse med beskedudsendelsen, men som kan have relevans for filtrering og fortolkning Nul til mange Objektregistreringer kan indgå i Filtreringsdata for at kunne bruges til abonnementsfiltrering Attribut Krav Type Datafordelerudfyldelse beskedtype «krævet» HTTP- URI(Klassifikat Deskriptiv klassificering af beskeden - beskedtyper publiceres i en klassifikationsservice og er tilgængelige for abonnementsopsætningen. Beskedtyperne dannes som en sammenstilling af objekttype og enten objekthandling (hvis beskeden dannes af kilderegisteret) eller Create, Update eller Delete (hvis beskeden dannes af Datafordeleren) Specificeres i DLS Eksempler DAF:Personobjekt-Create Kilderegister: Personobjektfødsel DAF:Personobjekt-Update Kilderegister: Personobjekt- Flytning beskedansvarliga ktør «krævet» HTTP- URI(Aktør) Specifikation af den aktør som har ansvaret for udsendelse af beskeden. Kilderegisteret som angivet i DLS Datafordeleren kan udsende beskeder på vegne af grunddataregistrene tilladtmodtager «valgfri» HTTP- URI(Aktør) Angivelse af de aktører,som må modtage beskeden, idet den omhandler begivenheder inden for deres Anvendes ikke
9 Grunddatabesked Side: 9 myndighedsområde. Skal være en organisationsaktør En positivliste - dog svarer en tom værdi til at alle kan modtage beskeden tværgåendeproce s «valgfri» HTTP- URI(Klassifikat Angivelse af den tværgåede proces - en arbejdsgang, som involverer en række aktører - der startede den objekthandling, som forårsagede hændelsesbeskeden. Anvendes ikke Der må være eksempler på sådanne processer inden for fx. ejendomsdomsdannelsen RelateretObjekt Dataobjekter, som ikke er opdaterede så de danner baggrund for beskeden, men som er relevante som filtreringsgrundlag i forhold til objektregistreringen Data leveres af kildesystemet ne er krævede, hvis klassen indgår i beskeden Eksempler: Måske et adresseobjekt relateret til en personobjekt-opdatering Et personobjekt, som ikke er opdateret, men som er part i sagen (0..*) RelateretObjekt indgår i (1) Filtreringsdata Beskeden kan indeholde referencer til andre forretningsobjekter, som ikke er ændrede i forbindelse med beskedudsendelsen, men som kan have relevans for filtrering og fortolkning Attribut Krav Type Datafordelerudfyldelse
10 Grunddatabesked Side: 10 objektid «krævet» HTTP- URI(Identifikat Specifikation af det konkrete dataobjekt Angiver et grunddatadataobjekt via Identifikation (se modelregel 6.1) Her altså ikke en reference til en objektregistrering, da beskeden ikke omhandler en specifik registreringsbegivenhed Det kan specificeres i DLS, at en datanær hændelse for et samleobjekt (fx en matrikelsag) angiver de objekter, det samler som relaterede (for en matrikelsag vil det være de ændrede matrikler objekttype «krævet» HTTP- URI(Klassifikat Objektets art, svarende et klassenavn i Grunddatamodellen Værdien må referere til en Klassifikationsservice, som udstiller modellens klasser Konstant for beskedtypen, læses fra datamodel ud fra angivelse i DLS. Objektregistrering Objekter, hvis opdatering har affødt beskeden Der er behov for, at en besked kan omhandle mere end et objekt Ved at sætte multiplicitet til 0..* muliggøres, at beskeden kan udsendes uden at der er reference til et specifikt objekt (hvis det er besked om en forretningshændelse, som ikke afføder objektregistrering), samt at beskeden kan omhandle ethvert antal af objekter større end nul. Data udfyldes af kildesystemet Krævede attributter er krævede, hvis klassen indgår i beskeden (0..*) Objektregistrering (1) Filtreringsdata Nul til mange Objektregistreringer kan indgå i Filtreringsdata for at kunne bruges til abonnementsfiltrering (0..1) Stedbestemmelse indgår i (1) Objektregistrering
11 Grunddatabesked Side: 11 Attribut Krav Type Datafordelerudfyldelse objektid «krævet» HTTP- URI(Identifikat Specifikation af det dataobjekt, som registreringen vedrører Læses fra opdateringen. I Grunddata er objektindentifikatoren Identifikation - se Modelregel 6.1 Eksempel: c3a-11d c9a66 Mapper til udtillingsmodellens id attribut registreringstid «krævet» datetime Tidspunkt for objektregistreringen I Grunddata er en objektregistrering specificeret ved en objektidentifikator samt et registreringstidspunkt Læses fra opdateringen. Svarer til Modelreglenes registreringfra (se modelregel 6.3) status «valgfri» HTTP- URI(Klassifikat Angivelse af den status - se Modelregel 6.2- som registreringen har påført dataobjektet Læses fra opdateringen. Modellens statusser udstilles i en klassifikationsservice Mapper til udstillingsmodellens statusattribut registreringsaktør «valgfri» HTTP- URI(Aktør) Den aktør, om har foretaget registreringen Reference til relevant aktør i en Læses fra opdateringen.
12 Grunddatabesked Side: 12 organisationskomponent Mapper til udstillingsmodellens registreringsaktør-attribut objektansvarligak tør «valgfri» HTTP- URI(Aktør) Den myndighed, som har overordnet dataansvar for dataobjektet - for eksempel et grunddataregister (person, adresse), en kommune (byggesag, institutionsplads) eller en bank (bankkonto) Kilderegisteret, der har afsendt opdateringen. NOTE: I Grunddata kan flere forskellige typer aktører være objektansvarlige - i de fælleskommunale beskedfordeler er det altid en myndighed, hvorfor den korresponderede attribut hedder objektansvarligmyndighed objekttype «krævet» HTTP- URI(Klassifikat Objektets art, svarende til et klassenavn i Grunddatamodellen Værdien må referere til en Klassifikationsservice, som udstiller modellens klasser Konstant for beskedtypen. Reference til klassens metadata i metadataregisteret. objekthandling «valgfri» HTTP- URI(Klassifikat En forretningsmæssig handling foretaget på objektet i forbindelse med den proces/registrering, som affødte hændelsesbeskeden. Handlingen er typisk en intern proces - en arbejdsgang, som er udført af beskedafsederen, og som kan være en del af en eller flere forskellige tværgående processer (procestyper) Oprettelse, Ændring eller Sletning er det eneste, vi ved, om datanære hændelser. Objekthandlingen danner forretningsmæssig kontekst i forbindelse med abonnementsfiltrering af beskeder. Et personobjekts ændring i adresseobjekttilknytning er måske kun af intersse hvis
13 Grunddatabesked Side: 13 der er tale om en flytning Objekthandlingerne udgør et udfaldsrum, som er specifikt for hver objekttype Mapper til udstillingsmodellens forretningshændelseattribut Eksempel: Ejerskifte, fx som del af en overordnet udstykningsproces Flytning (for et personobjekt) opgaveemne «valgfri» HTTP- URI(Klassifikat Det forretningsemne/opgave i forbindelse med hvilken, objektet blev registreret. Konstant for beskedtypen. Angives evt. i DLS Reference til en FORMklasse - ikke nødvendigvis på laveste niveau Mapper til udstillingsmodellens forretningsområdeattribut Eksempler: Indtil videre: online.dk:8080/form- REST/resources/f3295ba e c ?dybde=1 (svarer til FORM:10:Uddannelse og undervisning) eller online.dk:8080/form- REST/resources/f1abda73-44bb-11e4-ac c (FORM: :Prøver og eksamener på kunstneriske uddannelser)
14 Grunddatabesked Side: 14 På sigt formodentlig abda73-44bb-11e4-ac c registreringsid «valgfri» Systemer, der ikke opererer med registreringstid må identificere deres objektregistreringer på anden vis Læses evt. fra opdateringen. Stedbestemmelse Angivelse af et geografisk område, som objektregistreringen vedrører Er enten en reference til et geoobjekt, fx et DAGI-objekt eller en geometri angivet i WKT-format (0..1) Stedbestemmelse indgår i (1) Objektregistrering (1) StedbestemmelseGeometri kan være (1) Stedbestemmelse (1) StedbestemmelseReference kan være (1) Stedbestemmelse Stedbestemmelse kan foregå vha en medsendt geometri Stedbestemmelsen kan voregå via reference til et objekt med geometri StedbestemmelseReference Reference til et Grunddataobjekt, som har den geometri, som stedbestemmer beskeden til filtreringsformål (1) StedbestemmelseReference Stedbestemmelsen kan voregå via reference til et objekt med geometri
15 Grunddatabesked Side: 15 kan være (1) Stedbestemmelse stedbestemmelse Reference «krævet» Attribut Krav Type Datafordelerudfyldelse HTTP- URI(Identifikat Angivelse af stedet som en reference til et grunddataobjekt, med geometri, som udstilles på datafordeleren XML versionen af beskeden indeholder både objekttypen og referencen til objektet StedbestemmelseGeometri Geometri, som stedbestemmer beskeden til filtreringsformål (1) StedbestemmelseGeometri kan være (1) Stedbestemmelse Stedbestemmelse kan foregå vha en medsendt geometri Attribut Krav Type Datafordelerudfyldelse stedbestemmelse Geometri «krævet» CharacterStrin g Angivelse af stedet medsendes som en geometri i WKT-format Leveranceinformation Information vedrørende beskedens rute fra afsender til seneste handler. Data leveres af kildesystemet
16 Grunddatabesked Side: 16 (1) Leveranceinformation (1) Beskedkuvert (0..*) Leverancerute (1) Leveranceinformation Beskedens Leveranceinformationer indgår i beskedkuverten - disse danner baggrund for håndtering og logning Ruteinformationen kan indgå i Leveranceinformation - med en instans for hver "handler" Attribut Krav Type Datafordelerudfyldelse dannelsestidspun kt «krævet» datetime Tidspunkt for beskedens dannelse (= afsendelsestidspunkt fra kildesystem). Timestamp indsættes af systemet transaktionsid «valgfri» HTTP- URI(procesid) kildesystem «krævet» HTTP- URI(Aktør) Identifikaton af den proces, som dannede beskeden Identifikation af kildesystemet, det system, som udsendte beskeden Reference til en aktør af typen it-system i en organisationskomponent Løbenummer for beskeder udsendt efter et givet abonnement. Anvendes af modtageren til at verificere, at de har modtaget alle relevante beskeder. ID for Datafordeleren kildesystemipadr esse kildesystemakkre ditiver «valgfri» ip-adresse IP-adressen på kildesystemet «valgfri» CharacterStrin g Akkreditiver - for eksempel certifikat - som sikrer kildesystemets identitet NOTE: Type afklares Skal den være med? Udelades, hvis det ikke kan udfyldes meningsfuldt for Datafordeleren Udelades, hvis det ikke kan udfyldes meningsfuldt for Datafordeleren sikkerhedsklassif cering «krævet» HTTP- URI(Klassifikat Feltet beskriver beskedens sikkerhedsklassificering. Beskedfordeler- og modtagerhandling kan afhænge af denne Reference til en klasse i en klassifikationsservice Et af de fire niveauer som er aftalt i sikkerhedsdiskussi onen. Konstant for beskedtypen og specificeret i
17 Grunddatabesked Side: 17 DLSen Leverancerute Metadata om hvert trin i beskedens rute. Multiplicitet er 0..* idet elementet er fraværende i den besked, som sendes fra kildesystemet til første beskedfordeler. Data leveres af den aktuelt håndterende komponent (0..*) Leverancerute (1) Leveranceinformation Ruteinformationen kan indgå i Leveranceinformation - med en instans for hver "handler" Attribut Krav Type Datafordelerudfyldelse fordelingssystem «krævet» HTTP- URI(Aktør) Identifikation af 'denne komponent' Reference til en aktør af typen it-system i en organisationskomponent ID for Datafordeleren modtagelsestidsp unkt leverancetidspunk t modtagetfrasyste m «krævet» datetime Tidspunkt for denne komponents modtagelse af beskeden «krævet» datetime Det tidspunkt hvor denne komponent har videreformidlet beskeden «krævet» HTTP- URI(Aktør) Det system, som beskeden er modtaget fra. Det kan være kildesystemet eller en anden beskedfordeler Reference til en aktør af typen it-system i en organisationskomponent Indsættes af Systemet Indsættes af Systemet Tom for beskeder genereret af Datafordeleren erleveretihenhol dtil «krævet» HTTP- URI(Abonnem entid) Specifikation af det abonnement, som har specificeret denne videresendelse. Dette kan være nyttigt i Indsættes af Systemet
18 Grunddatabesked Side: 18 beskedmodtagerens analyse af den modtagne besked Reference til abonnementssystemets unikke identifikation af abonnementet - se referencearkitekturen.
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 mereUnderbilag 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 mereTeknikken bag Datafordeleren Distribution af data. Fællesoffentlig datadistribution
Teknikken bag Datafordeleren Distribution af data Fællesoffentlig datadistribution Styrelsen for Dataforsyning og Effektivisering 21. november 2017 Side 1 Indhold Datas vej fra register til anvendere Hændelser
Læs mere<navn på proces eller use case>
-- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der
Læs mereHændelser på dåtåfordeleren
Hændelser på dåtåfordeleren En kort introduktion til begreber og anvendelsesmuligheder SDFE version 1.0 24. oktober 2016 Indhold Indledning... 2 Overordnet arkitektur... 2 Hændelsesbegrebet... 3 Forretningsmæssige
Læs mere1. Services, egne (udgående)
1. Services, egne (udgående) Navn: navn på egen service, eksempelvis: BrugsenhedAjourfoer Formålet med servicen beskrives kort, eksempelvis: Formålet med servicen er at oprette en den Brugsenhed som beskriver
Læs mereNotat om metadata om grunddata
Bilag 16 - Fælles arkitekturramme for GD1-GD2-GD7 Notat om metadata om grunddata 6. december 2013 SAR & PLACE Indledning Metadata data om data betegner ikke en entydig klasse af data. Anvendelsen af betegnelsen
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.2.2
SF1460_C Aflever besked - version 2.2.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.4.0
SF1460_C Aflever besked - version 2.4.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereKrav til beskedfordeler, dannelse og abonnement
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 4 - Fælles arkitekturramme for GD1-GD2-GD7 Krav til beskedfordeler, dannelse og abonnement Version: 0.4 Status: udkast Oprettet: 2. juni 2014
Læs mere0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.
Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012
Læs mereSNITFLADER 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 mereUnderbilag 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 mereFælles arkitekturramme for GD1-GD2-GD7
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Cover til Fælles arkitekturramme for GD1-GD2-GD7 Fælles arkitekturramme for GD1-GD2-GD7 - kravbilag til brug for GD1-GD2 s kravspecificering Version:
Læs mere1 Objekt informationsmodel - Byggeblok
1 Objekt informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Objekt Modellen beskriver og viser hvordan Forretningsobjekt "Objekt" kan forstås. Modellen er generisk, og kan derfor bruges
Læs mereFordeling 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 mereGrunddata på Datafordeleren
Grunddata på Datafordeleren Fællesoffentlig datadistribution Morten Lindegaard 7. september, 2017 Grunddata på Datafordeleren Distribution af kopi af data Data skabes og vedligeholdes i grunddataregistre
Læs mereIntegration 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 mereBilag 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 mereAnvendelse af dobbelthistorik i GD2
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:
Læs mereEjendomsdataprogrammet - Matriklen Løsningsarkitektur - Bilag A Servicebeskrivelser og integrationer
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur
Læs mereDAGI Løsningsarkitektur Bilag A - Servicebeskrivelser og integrationer
Bilag 9 Fælles arkitekturramme for GD1GD2GD7 Grunddataprogrammets delaftale 2 om effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne DAGI Løsningsarkitektur Bilag A Servicebeskrivelser
Læs mereModelafleveringsproces
Appendix - Informationsmodel og Datamodel Side: 1 Modelafleveringsproces Modelafleveringsproces Modelafleveringsproces Diagrammet beskriver de processer, der knytter sig til indlevering af en datamodel
Læs mereTil 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 mereSF1460_A Modtag besked Integrationsbeskrivelse - version 2.3.0
SF1460_A Modtag besked - version 2.3.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mere1 Indledning. 2 Den fællesoffentlige datafordeler. 1.1 Hvad er grunddata
1 Indledning Det er et mål i den fællesoffentlige digitaliseringsstrategi, at grunddata skal være et fælles forvaltningsgrundlag for den offentlige sektor, der vedligeholdes ét sted (i de respektive kilderegistre)
Læs mereVilkår vedrørende brug af Støttesystemet Beskedfordeler
Vilkår vedrørende brug af Støttesystemet Beskedfordeler 1 Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Beskedfordeler,
Læs mereReferencearkitektur for håndtering af hændelser - "Event-Driven Architecture"
Bilag 3 - Fælles arkitekturramme for GD1-GD2-GD7 Referencearkitektur for håndtering af hændelser - "Event-Driven Architecture" Denne version af referencearkitekturen er målrettet Grunddataprogrammet Version:
Læs mereKlik 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 mereIntroduktion 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 mereDigital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet
Digital Sundhed Brugerstyringsattributter - Introduktion - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Læsevejledning... 2 3. Aktører... 2 4. Autentifikation...
Læs mereVilkår for brug af Støttesystemet Sags- og Dokumentindeks
Version 1.0 Vilkår for 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 CVR 19 43 50 75 Side 1/10 1. Indledning og
Læs mereBESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER. Version 2.0
BESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER Version 2.0 Støttesystemer er selvstændige it-løsninger, der sikrer, at kommunens fagløsninger kan fungere sammen og få adgang til relevante data. Et støttesystem
Læs mereINTEGRATION TIL DEN FÆLLESKOMMUNALE ARKITEKTUR
INTEGRATION TIL DEN FÆLLESKOMMUNALE ARKITEKTUR Integrationsform (Serviceplatform [SP]) Gennemstilling Omstilling/redirect Orkestrering Replica/cache Transformation SFTP simpel SFTP med service kvittering
Læs mereGD1/GD2 - Model for supplerende forretningsbeskrivelser
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 11 - Fælles arkitekturramme for GD1-GD2-GD7 GD1/GD2 - Model for supplerende forretningsbeskrivelser Udbudsoption vedrørende supplerende forretningsbeskrivelser.
Læs mereBitemporalitet på Datafordeleren
Bitemporalitet på Datafordeleren Denne side indeholder en anvenderrettet beskrivelse og dokumentation af grunddataprogrammets historikmodel ved anvendelse og implementering af bitemporalitet. Dokumentet
Læs mereKvalitetssikring af DLS leverancer Afrapportering 15. oktober 2015
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) bilag 6 Kvalitetssikring af DLS leverancer Afrapportering 15. oktober 2015 Version: 0.3 Status: Udkast Oprettet 15-10-2015 Fil: Bilag 6 - Kvalitetssikring
Læs mereKlik 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 mereModelregler for grunddata Version 1.0.0
Grunddataprogrammet Modelregler for grunddata Version 1.0.0 1 Modelregler for Grunddata Version: 1.0.0 Status: Gældende Godkendt af Grunddatabestyrelsen d.3. februar 2014 2 Forord Modelreglerne er udarbejdet
Læs mereVilkå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 mereVilkå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 mereAdresseprogrammet - Målarkitektur Bilag D - Arkitekturrammer
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseprogrammet - Målarkitektur
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk
Læs mere1 Tilstand informationsmodel - Byggeblok
1 Tilstand informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Tilstand : Overordnet model til at beskrive "tilstande". Modellen er generisk og kan bruges som skabelon på tværs af forretningsområder
Læs mereBESKEDFORDELER 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(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
30. april 2013 NOTAT Bilag 12: Anvenderkrav til Støttesystemet Beskedfordeler (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334
Læs mereBrugerdokumentation, Beskedfordeler Støttesystemer
Brugerdokumentation, Beskedfordeler Støttesystemer Side 1 af 52 Indholdsfortegnelse Historik... 5 1 Indledning... 6 1.1 Målgruppe for brugermanualen... 6 1.2 Hvad er beskedfordeleren?... 6 1.3 Forudsætninger
Læs mereIntegration 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 mereIntroduktion 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 mereBBR - Kontekstdiagram
BBR arkitekturprodukter 1. marts 2019 BBR - Kontekstdiagram Indledning Dokumentationen omkring BBR er struktureret med inspiration fra FDA arkitekturreolen, således at arkitekturprodukterne afspejler denne
Læs mereScope 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 mereVilkå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 mereTypografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem
Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem 1 Indholdsfortegnelse A3.1 INTRODUKTION 3 A3.1.1 HENVISNINGER 3 A3.1.2 LÆSEVEJLEDNING 4 A3.1.2.1 SÅDAN
Læs mereTeknisk Dokumentation
Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...
Læs mereHøringsnotat - specifikation af serviceinterface for SAG version 1 2
N OTAT Høringsnotat - specifikation af serviceinterface for SAG version 1 2 Specifikation af serviceinterface for SAG Version 1.2 (Sag-standard) Den fællesoffentlige styregruppe for Sag og Dokument sendte
Læs mereAdresseregister - løsningsarkitektur Bilag A - Servicebeskrivelser
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseregister - løsningsarkitektur
Læs mereVejledning 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 mereCompliance-test, STS Sags- og Dokument indekset
11. april 2018 Compliance-test, STS Sags- og Dokument indekset Version 1.0 75 Side 1/13 1. Ændringshistorik Dato Version Foretaget af Ændringsbeskrivelse 28-01-2019 0.1 CWM Dokument oprettet. 06-03-2019
Læs mereDKAL Snitflader REST Register
DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4
Læs mereIntroduktion til MeMo
Introduktion til MeMo 1. februar 2019 CIU I forbindelse med Digitaliseringsstyrelsens udbud af Næste generation Digital Post løsningen (NgDP) er der udviklet en ny model for udveksling af digitale postmeddelelser,
Læs mereKlik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks
30. april 2013 NOTAT Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks Indhold: 1. Indledning og vejledning... 3 2. Krav vedr. Systemets anvendelse af Støttesystemet
Læs mereDigital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3
Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 1 Indholdsfortegnelse INDHOLDSFORTEGNELSE 2 A5.1 INTRODUKTION 4 A5.2 HTTP RETURKODER 4 A5.3 DIGITAL POST FEJLKODER 7 A5.3.1 DIGITAL POST
Læs mereIntroduktion 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 mereSTEDBEVIDST UDVIKLING. Jes Ryttersgaard Kort og Matrikeldtyrelsen
STEDBEVIDST UDVIKLING Jes Ryttersgaard Kort og Matrikeldtyrelsen - bevidst om at bruge stedet som indgang til digital forvaltning - bevidst om hvordan vi sikrer, at det giver mening at bruge stedet - bevidst
Læs mereEn ajourføringsservice er intern service mellem to registre udgangspunktet er beskrivelserne i løsningsarkitekturen bilag A - servicebeskrivelse.
1. Fælles skabeloner For at få en ensartet detaljeret beskrivelser af samtlige services, skal bruges et sæt af fælles skabeloner. Der er én skabelon for hver servicetype (ajourføring, udstilling, hændelser
Læs mereServiceplatformen informationsmateriale. Leverandørmøde 7. februar 2013
Serviceplatformen informationsmateriale Leverandørmøde 7. februar 2013 1 Om Serviceplatformen Dette informationsmateriale beskriver kort Den fælleskommunale Serviceplatform: formålet med Serviceplatformen,
Læs mereIKT-teknisk kommunikationsspecifikation
Bilag til IKT Ydelsesspecifikation Dato 2012-10-01, Revisionsdato: 2013-04-15 Samarbejdsdokument for byggesagens parter Projekt: Byggesag: Projektledelse: IKT Koordinator: Dato: Revision: Revision dato:
Læs mereVilkår for dialogintegration SAPA
Vilkår for dialogintegration SAPA Indhold 1. Indledning og vejledning... 3 1.1 Definitioner... 5 2. Krav til it-systemer for at kunne udføre dialogintegration... 6 2.1 Udstilling af endpoint... 6 2.2 HTTPS
Læs mereKlassifikation: KlassifikationSystem-Snitflade
Side 1 af 15 Indhldsfrtegnelse 1. Versinsnummer...3 2. Snitfladebeskrivelse...3 3. Servicebeskrivelse...3 4. Funktinalitet i peratinen FremsegObjekthierarki...4 4.1. Inputdkument...6 4.2. Outputdkument...6
Læs mere6. Status på arbejdet med fælles infrastruktur (fast punkt)
6. Status på arbejdet med fælles infrastruktur (fast punkt) Status på RA STS projektet (Michael Strand) Operationelle erfaringer (Peter Thrane / Michael Strand) Serviceplatformen og datafordeleren (Michael
Læs mereLøsningsarkitektur Bilag A Servicebeskrivelser og integrationer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltningg og genbrug af ejendomsdataa under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet Ejerfortegnelsen Løsningsarkitektur
Læs mereSAPAs 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 mereIndholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase
Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...
Læs mereRetningslinjer for specifikation af RESTtjenester
Retningslinjer for specifikation af RESTtjenester pa Datafordeleren Version 1.0.1 Juli 2017 RETNINGSLINJER FOR SPECIFIKATION AF REST-TJENESTER I GRUNDDATAPROGRAMMET Retningslinjerne er godkendt af Grunddataprogrammets
Læs mereModelleringskoncept for grunddata
Modelleringskoncept for grunddata Version: 0.9 Status: Udkast 1 Forord Modelleringskonceptet er udarbejdet som led i etableringen af grunddatamodellen: en fælles datamodel for alle grunddata. Etablering
Læs merePeter Thrane Enterprisearkitekt KL+KOMBIT. Den fælleskommunale Rammearkitektur - Inspiration
Peter Thrane Enterprisearkitekt KL+KOMBIT Den fælleskommunale Rammearkitektur - Inspiration REGIONERNE Selvstyre Egen økonomi Konkurrence = bedre priser Samarbejde Koordinering Udveksling SAMMENHÆNG
Læs mereVersion 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 mereSpecifikation af Model for Dokument (Version til kommentering)
Specifikation af Model for Dokument (Version til kommentering) 1 > Specifikation af Model for Dokument. Version 2.0 (version til kommentering) Denne standard kan frit anvendes af alle. Citeres der fra
Læs mereFESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø
FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har
Læs mereTestplan - Snitflade-, Integrations- og anvendertest Bilag B: Planens test cycles
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Testplan - Snitflade-, Integrations- og anvendertest Bilag B: Planens test cycles Version: 2.1 Status: Godkendt af styregruppen Oprettet: 19-12-2016
Læs mereIndeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76
MOX bilag Indeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76 Rapporten og bilaget udgør et foreløbigt udkast til rapportering
Læs mereSpor 2: Anvendelse af datafordeleren. Dialogdag Datafordeler Aalborg, 22. september / København, 6. oktober / Odense 10.
Spor 2: Anvendelse af datafordeleren Tjenestetyper og hændelser Jakob Schou, Projektleder SDFE Sik Cambon Jensen, Arkitekt KMD Dialogdag Datafordeler Aalborg, 22. september / København, 6. oktober / Odense
Læs mereUNI Login. Eksport webservice. WS17 v1
UNI Login Eksport webservice WS17 v1 UNI Login Eksport webservice 1.4 Indhold 1 Eksport webservice... 1 1.1 Indhold af data... 1 1.2 Dataaftale... 1 1.3 Klassifikation af data... 2 1.4 Informationsmodel...
Læs mereDen 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 10.6.2014 De 5 digitaliseringsmål
Læs mereSTS ORGANISATION. 26. februar 2019
STS ORGANISATION 26. februar 2019 Indhold Baggrund og ophæng til rammearkitekturen Hvordan fungerer Organisation? Anvisninger til anvendelse af Organisation Guide til udlæsning af Organisation Dokumentation
Læs mereLø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 mereKOMBITS 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 mereIntroduktion til Støttesystem Sags- og Dokumentindeks
Introduktion til Støttesystem Sags- og Dokumentindeks 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Sags- og Dokumentindeks i den fælleskommunale infrastruktur. Formålet er
Læs mereSKI 02.19. Version 1.0
SKI 02.19 Version 1.0 23. maj 2015 1 Indhold Indledning... 3 Snitfladernes etablering og tilgængelighed... 3 Integrations- og anvendervilkår... 3 Beskrivelse af KOMBITs snitfladeoversigt... 4 Faneblad:
Læs mereVejledning til anvendelse af MeMo og SMTP. Næste generation Digital Post Maj 2018, version 0.9
Vejledning til anvendelse af MeMo og SMTP Næste generation Digital Post Maj 2018, version 0.9 Indhold Indhold 2 1 Introduktion 3 1.1 Præciseringer 3 1.2 Terminologi 3 2 Anvendelse af SMTP-felter 5 3 Anvendelse
Læs mereTeknisk uddybning af generelle egenskaber for sags- og dokumentområdet
Teknisk uddybning af generelle egenskaber for sags- og dokumentområdet Teknisk uddybning af generelle egenskaber for sags- og dokumentområdet Denne vejledning kan frit anvendes af alle. Citeres der fra
Læs mereFAQ Integrationsbeskrivelser. Kommunernes Datafællesskab - KDF
Kommunernes Datafællesskab - KDF 1 FAQ af integrationsbeskrivelser Denne log indeholder spørgsmål/kommentarer fra fagprojekterne til Integrationsbeskrivelser, wsdl-filer, stubbe eller generelt i forhold
Læs mereArkitekturrapport: 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 mereEjerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltningg og genbrug af ejendomsdataa under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet Ejerfortegnelsen Løsningsarkitektur
Læs mereAuthorizationCodeService
AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...
Læs mereBaggrundsinformation
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(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR
Læs mereDKAL Snitflade Webservice
DKAL Snitflade Webservice Typografidefinition: Overskrift 1: Skrifttype: Indrykning: Venstre: 0 cm, Hængende: 0,76 cm, Sideskift før Typografidefinition: Overskrift 2;H2;h2;2;headi;hea ding2;h21;h22;21;heading
Læs mereSamlet Fast Ejendom (SFE) Bygning På Fremmed Grund (kommende fra Bygning På Lejet Grund ) Ejerlejlighed
11. januar 2017 1. Formål Dette notat er henvendt til IT leverandører og IT indkøbere af systemer, der anvender Building & Dwelling services på det nuværende Bygnings- og Boligregister (BBR). Som offentliggjort
Læs mereDen Gode VANSEnvelope, Scenariebeskrivelser. MedCom
Den Gode VANSEnvelope, Scenariebeskrivelser MedCom Den Gode VANSEnvelope, Scenariebeskrivelser Jacob Glasdam, MedCom Ulrik Schønnemann, MedWare udgivelsesdato 19. november 2010 Revisionshistorie Revision
Læs mere