Grunddatabeskedmodel version 1.0
|
|
|
- Tobias Jørgensen
- 10 å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
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...
Teknikken 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
Hæ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
Notat 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
Krav 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
0.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
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
Grunddata 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
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
Anvendelse 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:
Ejendomsdataprogrammet - 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
SF1460_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
1 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)
Vilkå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,
Referencearkitektur 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:
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
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
BESKEDFORDELER -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
GD1/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.
Bitemporalitet på Datafordeleren
Bitemporalitet på Datafordeleren Denne side indeholder en anvenderrettet beskrivelse og dokumentation af grunddataprogrammets historikmodel ved anvendelse og implementering af bitemporalitet. Dokumentet
Modelregler 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
Vilkår for Dialogintegration
Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer
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
Brugerdokumentation, 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
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
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
BBR - 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
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.
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
Typografidefinition: 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
Teknisk 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...
Compliance-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
DKAL 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
Introduktion 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,
Digital 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
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
STEDBEVIDST 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
IKT-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ø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
Indholdsfortegnelse. 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...
Modelleringskoncept 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
Peter 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
Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring
Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring [email protected] CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT
Specifikation 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
FESD-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
Testplan - 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
Spor 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
UNI 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...
STS 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ø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
Introduktion 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
SKI 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:
Vejledning 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
FAQ 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
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
Ejerfortegnelse 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
AuthorizationCodeService
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...
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
DKAL 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
Samlet 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
