FESD Grænseflade til CMSløsninger

Størrelse: px
Starte visningen fra side:

Download "FESD Grænseflade til CMSløsninger"

Transkript

1 FESD Grænseflade til CMSløsninger Standard IT- og Telestyrelsen København den 18. december FESD-standardisering Grænseflade til CMS-løsninger. Snitflade. Version 1.1

2 Kolofon: FESD-standardisering. Grænseflade til CMS-løsninger. Snitflade. Version 1.1 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Kontoret for standardiserings- og arkitekturpolitik, FESD-standardiseringsgruppen i samarbejde med de tre FESD-leverandører Software Innovation A/S, Traen Informationssystemer A/S og CSC mark A/S. Kontaktperson i FESD-standardisering: Projektleder Rita Lützhøft, Mail-adresse rla@itst.dk Telefon (direkte) Traen Informationssystemer A/S Vesterbrogade 95 A 1620 København K Telefon: Web-adresse: CSC mark A/S Retortvej København V Telefon: Web-adresse: Software Innovation A/S Nærum Hovedgade Nærum Telefon: Web-adresse: Ministeriet for Videnskab, Teknologi og Udvikling IT- og Telestyrelsen Kontoret for standardiserings- og arkitekturpolitik Holsteinsgade 63 DK-2100 København Ø Telefon: Fax itst@itst.dk 2 / 33

3 Indholdsfortegnelse 1 FORORD Teknisk forord DEL A BUSINESS CASE Indledning og afgrænsning Formål Reference til andre standarder Målgruppe Anvendelse DEL B BESKRIVELSE AF FORRETNINGSARKITEKTUR Indledning Data Dataobjekter Fortrolighed Rettighed Udpeget til publicering Forretningskrav Aktører i brugsscenarier Funktionelle krav Publicering Opdatering af data Afpublicering DEL C BESKRIVELSE AF DATAMODEL OG -SKEMAER Publiceringsstatus publishingstatus publishingstatuscode Webservice grænseflader getcontenttree createcontentposition updatecontentposition removecontentposition createcmdata updatecmdata removecmdata getcmcontentlist getcmcontentlist getcmdata / 33

4 Samlet oversigt over webservices Publiceringsstatus publishingstatus (-navn: PubliceringStatusStruktur) publishingstatuscode (-navn: PubliceringStatusKodeStruktur) Webservice grænseflader getcontenttree createcontentposition updatecontentposition removecontentposition createcmdata updatecmdata removecmdata getcmcontentlist getcmcontentlist getcmdata ANVENDTE TYPER I FESD-MODELLERNE / 33

5 1 Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sags- og dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Arbejdet med forslag/udkast til standarder tager udgangspunkt i Noark 4 s datamodel og databeskrivelser samt leverandørernes løsninger. Standarderne kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor parterne i FESD-standardiseringen kan opnå enighed om en afvigelse. Udkast/forslag sendes herefter i offentlig høring i ca. 1 måned. FESD-standardiseringsgruppen tilretter og færdiggør på baggrund af høringen de endelige Forslag til standarder. Standardforslagene forelægges herefter OIO-komiteen til godkendelse. Efter den samlede godkendelse bliver standarderne således offentliggjort og indgår i IT- og Telestyrelsens OIO-Katalog (digitaliser.dk), som indeholder en oversigt over godkendte og anbefalede standarder til digital forvaltning i det offentlige. I standarden kan forekomme brug af særligt ordvalg. Følgende termer anvendes konsekvent i den følgende betydning: skal / obligatorisk : betyder, at den nævnte metode/element/mulighed/etc. skal benyttes eller skal forefindes dvs. må ikke udelades. må ikke : betyder, at den nævnte metode/element/mulighed/etc. ikke må forefindes eller må ikke benyttes. bør / anbefalet : betyder, at det i høj grad anbefales, at den nævnte metode/element/mulighed/etc. benyttes eller forefindes. Der skal være tungtvejende grunde til at udelade. kan / optionel : betyder, at den nævnte metode/element/mulighed/etc. er en valgmulighed og derfor valgfri at medtage. Denne udgave af standarden er såkaldt konsolideret i forhold til version 1.0. På grund af den måde FESDstandardiseringsarbejdet er tilrettelagt på forskellige afleveringer på forskellige tidspunkter siden 2004 udkommer FESD-datamodellen som deldatamodeller. Det har betydet, at enkelte detaljer i det forventede slutresultat altså den samlede FESD-datamodel kan være overset. Det har endvidere været nødvendigt at konsekvenstilføje noget, der tidligere er sprunget over fx på grund af manglende standardisering på det tidspunkt, den aktuelle standard blev udarbejdet. Endvidere har NDR (Name 5 / 33

6 and Design Rules) reglerne givet anledning til en del ændringer i sprogbrug (semantik) vedrørende attributter af hensyn til efterfølgende generering af Den samlede FESD-datamodel (i form af deldatamodellerne) til og med 2008 er derfor gennemgået og genvurderet i forbindelse med denne standard. Denne genvurdering har ikke medført forretningsmæssige radikale ændringer i deldatamodellen, men har dog givet anledning til en del justeringer, typisk af præsentationsmæssig (semantik) karakter, især pga. NDR-reglerne. 1.1 Teknisk forord Grundlaget for FESD-datamodellen er blevet udarbejdet på en periode på mere end fire år, hvor der er udarbejdet standarder for de forskellige delområder. Arbejdsmetoder, terminologi og anvendelse af datatyper har ændret sig i denne periode FESD-standardiseringsgruppen har f.eks. indført en konsekvent brug af UMLnotation i de senere standarder. Konsolideringen af datamodellen har derfor forudsat, at der blev defineret en fælles modelleringsmetode og et sæt af primitive datatyper, der var kompatibelt med alle del-datamodellerne. De primitive datatyper, som modellen er opbygget af, fremgår af kapitel 6. 6 / 33

7 2 DEL A Business Case 2.1 Indledning og afgrænsning Styregruppen for FESD-projektet har besluttet at der skal gennemføres et standardiseringsarbejde inden for området ESDH CMS integration. Dette arbejde skal omfatte udarbejdelse af en business case, forretningsarkitektur og datamodel. ESDH-systemer bruges til sagsbehandling, dvs. skabe, opsamle, journalisere, distribuere, og arkivere sagsdata inden for den sagsbehandlende organisation. Med andre ord, håndtering af en sags livscyklus. Da sager ofte vil omfatte følsomme informationer, er det et væsentligt kendetegn ved ESDH-systemer at brugerne tildeles et og samme veldefinerede rettigheds-domæne. I modsætning til dette fokuserer CMS på at organisere og præsentere tekster og billeder mm. Dette er typisk fra en organisations interne domæne til det offentlige domæne (dvs. world wide web). Det er oplagt, at der er væsentlige dele af de data, der opsamles i ESDH, der vil være relevant at formidle via CMS. Således forventes integration mellem ESDH og CMS at være et hyppigt forekommende ønske. Hvilken funktionalitet der ønskes i en sådan integration er derimod mindre klart. Der er et utal af mulige udformninger; men af retslige, organisatoriske, sikkerhedsmæssige og økonomiske grunde er det relevant at skelne mellem tre forskellige behovsområder: 1. publicering af data, der er af offentlig interesse i henhold til Lov om offentlighed i forvaltningen 2. publicering af data, der ikke automatisk giver aktindsigt eller data der er konfidentielt, 3. overførelse af data fra det offentlige net (www) til ESDH (udefra ind). Nærværende standard retter sig kun mod punkt 1. Da der i regi af det fælles offentlige er konkrete overvejelser om at iværksætte en analyse med henblik på at lave et fælles, koordineret systemsetup til at give borgere overblik over deres ESDH-sager (svarende til punkt 2) holdes dette ude af nærværende specifikation. Det vurderes ligeledes, at punkt 3 skal holdes ude for nærværende specifikation, dels fordi der er kraftige afhængigheder til punkt 2, og dels fordi det vurderes, at markedets modenhed endnu ikke kan underbygge en business case, der tilskriver et sådant arbejde. Nærværende standard retter sig altså alene mod publicering af data, der ikke kræver særlig aktindsigt eller er konfidentielt, til CMS. Med henblik på yderligere afgrænsning af dens virkeområde skal opmærksomheden henledes på standarden FESD Generisk integrationsmodel Fase 1, der omfatter et api med de mest almindelige services, der kan forekomme i et ESDH-system. Det har endvidere været foreslået at lave en standard for søgning i ESDH. Det har dog endnu ikke været muligt at nå til enighed om et grundlag for et sådant standardiseringsarbejde. Nærværende standard retter sig ikke mod disse behov. 2.2 Formål Med udarbejdelsen af en standard for området sigtes mod at: afdække de sikkerhedsmæssige hensyn, der skal tages for en sådan integration eksemplicifere mulige systemarkitekturer til en sådan integration tilvejebringe standard snitflader fra ESDH, der er særligt rettede mod CMS Arbejdet skal samlet set gøre det lettere, hurtigere og billigere at lave integrationsprojekter efterfølgende. 7 / 33

8 2.3 Reference til andre standarder [1] FESD Datamodel for sager og dokumenter [2] FESD Generisk integrationsmodel Fase Målgruppe Målgruppen for denne standardisering er software- og konsulentvirksomheder, der gennemfører integration fra CMS til ESDH, samt ESDH-udviklingsvirksomheder, der skal eller ønsker at møde standarderne for FESDprojektet. 2.5 Anvendelse Standarden fastsætter minimumskrav til snitflader mellem ESDH og CMS. Dette sikrer, at ESDHleverandørene har forberedt et vist omfang af funktionalitet, som implementeringspartnere kan gøre brug af i forbindelse med konkrete integrationsprojekter. Det er derimod ikke hensigten med standarden at sætte grænser for integrationen mellem ESDH og CMS på andre områder end dem der direkte omtales i standarden. Fx kan det tænkes at lave en anden og mere omfattende integration til et CMS der driver et intranet, der er placeret i et betroet domæne. 8 / 33

9 3 Del B af forretningsarkitektur 3.1 Indledning Integrationen mellem de to systemer ESDH og CMS består af nogle snitflader, i form af webservices, som systemerne hver især kan eller skal tilbyde eller benytte. For ikke at stille krav, der kan medføre at systemerne påvirker hinandens performance negativt, stilles der ingen krav om synkronisitet mellem systemerne. Men det er heller ikke et krav at kommunikationen skal være asynkron. I udformningen af standarden er der blevet lagt vægt på at standarden ikke skal indskrænke mulighederne for forskellige systemarkitekturer unødigt. Således er der taget hensyn til alle tre af følgende systemarkitekturer: 1. Løsninger, hvor CMS-systemet tager initiativ til at hente data fra ESDH 2. Løsninger, hvor ESDH tager initiativ til at sende data til CMS 3. Løsninger, hvor de to systemer ikke kan tale direkte sammen, men kommunikerer via en mellemmand. Eftersom data (indenfor rammerne af denne standard) fødes i ESDH men præsenteres i CMS, så kan første løsningsmodel kaldes en Pull-model, anden løsningsmodel kaldes en Push-model, mens den tredje model bruger både Push og Pull. Nedenfor er de tre modeller illustreret i tre simple tegninger. Model 2: Push ved publicering ESDH server CMS server med visningsklart ESDH data 9 / 33

10 Uanset hvilken model der vælges i en given integration, er det et krav, at det er ESDH-systemet, der bestemmer hvilket udvalg af data, der skal kunne vises i CMS. Efter ESDH-systemet har frigjort data som publiceret, er det op til CMS at bestemme over præsentationen af data. 3.2 Data En afgørende egenskab ved ESDH-CMS integrationer er at sikre, at det kun er data, der opfylder visse kriterier, der må publiceres. Nedenfor gennemgås de fire kriterier, der afgør om et givent dataelement må publiceres Dataobjekter De dataobjekter, det kan komme på tale at publicere, fremgår af standarden FESD Datamodel for sager og dokumenter. Det vil sige, at det som minimum skal være muligt at publicere sager og dokumenter fra ESDH til CMS, men at integrationen ikke behøver at være begrænset til disse dataobjekter. Således kan fx postlister og dagsordener publiceres som enten selvstændige datatyper, aftalt mellem parterne, eller indlejret i et dokument i henhold til ovennævnte standard for dokumenter. I tilfældet sag vil der indgå en række underobjekter (dokumenter, journalposter mv.). Det er vigtigt, at disse ikke automatisk sættes til publicering når sagen er publiceret. ESDH-systemet skal i dette tilfælde sikre, at brugeren præsenteres for en oversigt over underelementer på sagen, som kunne tænkes at være relevante til publicering, og brugeren kan fra denne oversigt til- eller fravælge publicering af de enkelte underobjekter. I nærværende standard bruges den generelle betegnelse element om et objekt (fx et dokument) med tilhørende metadata Fortrolighed For at data kan komme på tale til publicering, skal det være åbent for offentligheden. Det vil sige, at det, der automatisk gives aktindsigt i, ikke er konfidentielt Rettighed Et element kan naturligvis kun publiceres af en bruger, der har rettigheder til at publicere Udpeget til publicering Brugeren skal have valgt at publicere dataet. Det kan ikke komme på tale at publicere data, der ikke eksplicit er blevet sat til publicering. 3.3 Forretningskrav Aktører i brugsscenarier Med henblik på begrebsafklaring følger her en kort beskrivelse af de roller, der refereres til i det følgende. Sagsbehandler Leder (ressortansvarlig) Webmaster Slutbruger Bruger af ESDH-systemet med almindelige brugerrettigheder (typisk ikke administrator). Det kan være stor forskel fra organisation til organisation hvor mange rettigheder sagsbehandlere har, herunder om de har ret til publicering direkte til CMS. En rolle som kan til- eller fravælges i integrationen er en leder, der skal godkende publiceringen. I et setup med inddragelse af leder-rollen kan sagsbehandleren kun markere et element til publicering, mens publicering kun kan finde sted hvis lederen accepterer det. Den ansvarlige for indholdsstrukturen på webben. Ved organisering af konkrete implementeringer bør det afklares, hvem der har ret til hhv. ansvar for dataudvalg og struktur på webstedet. Den bruger der i sidste ende læser data fra CMS et 10 / 33

11 3.3.2 Funktionelle krav Standarden stiller seks funktionelle krav: - Sagsbehandler (evt. ressortansvarlig) skal kunne publicere ESDH-data - Sagsbehandler (evt. ressortansvarlig) skal kunne opdatere publiceret ESDH-data - Sagsbehandler (evt. ressortansvarlig) skal kunne afpublicere publiceret ESDH-data - ESDH-systemet skal automatisk kunne afpublicere dokumenter, hvis kassationsdatoer er nået - Sagsbehandler (og ressortansvarlig) skal kunne se ESDH-systemets publiceringsstatus (men ikke nødvendigvis CMS-systemets) - ESDH-systemet skal logge ændringer i ESDH-systemets publiceringsstatus - Slutbruger skal kunne læse publiceret ESDH-data i CMS I afsnit 3.1 er opstillet tre forskellige modeller for integration mellem ESDH og CMS. Det fremgår implicit at selve ESDH-dataet ikke nødvendigvis flyttes mellem systemerne på publiceringstidspunktet; det kan også ske på læsningstidspunktet. Standarden understøtter således både at data kan gemmes lokalt (i ESDH-systemet) eller i et fremmed system (mellemlager eller CMS). I de næste afsnit uddybes kravene til publicering, opdatering og afpublicering. Grænsefladerne til understøttelse af dette fremgår af afsnit / 33

12 3.3.3 Publicering Flow for publicering CMS ESDH Sagsbehandler Ressortansvarligt Hent indholdshierarki Sæt element til publicering Udsnit af indholdshierarki Knyt element til position i indholdshierarki Element klar til publicering Kræves godkendelse? Ja Publiceringsmaskine Ja Accepter publicering? Nej Gem lokalt? Notificering om afvisning Nej Ja Publiceret ESDH element Publiceret ESDH element Status opdateres 12 / 33

13 Use case navn Formål Forventet resultat Aktører : Sæt element til publicering Hent indholdshierarki Udsnit af indholdshierarki Knyt element til position i indholdshierarki Element klar til publicering Kræves godkendelse? Publiceringsmaskine Publiceret ESDH element Publicering fra ESDH til CMS ESDH-bruger kan publicere et element eller et sæt elementer fra ESDH til CMS Elementet er klar til brug for CMS Elementet er indplaceret i CMS indholdshierarki Publiceringsstatus er sat i ESDH Sagsbehandler, Ressortansvarlig, ESDH system, evt. Mellemlager, CMS Sagsbehandleren har markeret et element (herunder den ønskede version af elementet) i ESDH-systemet og vælger Publicér. Ved implementering af brugergrænsefladen til dette, skal ESDH-leverandøren være opmærksom på, at der ikke må herske tvivl om hvilket element, der vælges til publicering. Det kan fx ske hvis brugeren har åbnet en sag og derefter højremusseklikker på en anden sag og vælger Publicér på lokalmenuen. Se også 3.2. ESDH-systemet kalder en webservice der returnerer en nodeliste, med CMS indholdshierarki. Format for kald er defineret i afsnit Webservicen returnerer en nodeliste, der repræsenterer et udsnit af CMS indholdshierarki under hensyntagen til den aktuelle brugers (ESDH-bruger eller ESDH-systembruger) rettigheder. Implementeringspartneren kan vælge at inkludere et element i indholdshierarkiet, der fungerer som et medie-bibliotek, således at det ikke indgår direkte i CMS navigérbare indholdshierarki, men kun bruges til at linke fra andre tekster eller i forbindelse med søgning. ESDH-brugeren udpeger et eller flere steder i indholdshierarkiet hvor ESDH-elementet skal indsættes. Afhængig af implementeringen kan dette være som sideordnet (sibling) eller under-(child-) element. Publiceringsstatus sættes til Afventer publicering. ESDH-leverandøren kan vælge at indsætte et led i publiceringsprocessen hvor en ressortansvarlig skal acceptere at det givne element publiceres. Tilsvarende kan ESDHleverandøren vælge at notificere sagsbehandleren om hvilken beslutning, der er truffet. Såfremt ESDH-elementet skal publiceres, skal ESDH-systemet enten gemme dataet lokalt (kan implementeres som et flag, der angiver at elementet er publiceret) eller kalde en webservice med ESDH-elementet samt metadata om dette. Format for dette kald er defineret i afsnit ESDH-leverandøren kan vælge at formatere, transformere eller konvertere data inden det sendes til mellemlageret. Når ESDH-elementet er publiceret, indgår det i CMS forretningslogik. ESDH-systemet kan alene bestemme om et element er publiceret eller ikke publiceret. Status opdateres Publiceringsstatus sættes til Publiceret Opdatering af data Opdatering af data skal ske som følge af en aktiv handling fra ESDH-brugeren. ESDH-systemet bør prompte ESDH-brugeren, hvis der gemmes ændringer i et element, der er publiceret og bør i denne forbindelse give mulighed for at opdatere elementet i mellemlageret. Er der tale om en ny version af et element i ESDH, bør ESDH-systemet kunne prompte brugeren om 1. den nye version skal erstatte den eksisterende, publicerede version 2. den nye version skal publiceres, mens den eksisterende version bibeholdes. 3. den nye version ikke giver anledning til ændringer (herunder publicering). 13 / 33

14 Det bør være muligt at konfigurere ESDH-systemet til automatisk at foretage et af ovenstående valg uden involvering af brugere Afpublicering Eksplicit Brugeren vælger eksplicit at afpublicere elementet Implicit Elementet afpubliceres som underelement i en afpubliceret mængde. 14 / 33

15 Flow for afpublicering Flow for afpublicering CMS ESDH Sagsbehandler Ressortansvarligt Sæt element til afpublicering Sæt status til afpublicering Kræves godkendelse? Ja Nej Send besked om afpublicering Ja Accepter afpublicering Nej Gem lokalt? Notificering om afvisning Nej Ja Element slettes Element slettes Bekræftelse på sletning OK Fejl Advicer hvis fejl Status opdateres 15 / 33

16 Use case navn Formål Forventet resultat Aktører : Sæt element til afpublicering Accepter afpublicering Send besked om afpublicering Element slettes Bekræftelse på sletning Afpublicering af ESDH element fra CMS ESDH-bruger kan afpublicere et element eller et sæt elementer således at det ikke længere er tilgængeligt for slutbrugeren. Elementet fjernes fra CMS, mellemlager eller lokalt lager og kan derefter ikke vises i CMS Publiceringsstatus er sat i ESDH til Ikke publiceret. Sagsbehandler, Ressortansvarlig, ESDH system, evt. Mellemlager, evt. CMS Sagsbehandleren vælger at iværksætte afpubliceringsproceduren. ESDH-systemet bør gøre det klart for brugeren, at dette ikke i sig selv betyder, at elementet faktisk er blevet afpubliceret. Publiceringsstatus sættes til Afventer afpublicering. ESDH-leverandøren kan vælge at inkludere et led i afpubliceringsproceduren, hvor den ressortansvarlige skal acceptere afpubliceringen. Såfremt ressortansvarlige ikke vælger at acceptere afpubliceringen, rettes publiceringsstatus, og systemet kan returnere en notifikation til sagsbehandleren. Hvis data er gemt lokalt, slettes det (eller flag sættes, der angiver at elementet ikke er publiceret). Såfremt data ikke er gemt lokalt, skal ESDH-systemet så længe status er sat til afpublicering forsøge at kalde en webservice fra mellemlageret/cms, der skal få dette system til at fjerne ESDH-elementet. Format for dette kald er defineret i afsnit Det anbefales at ESDH-leverandøren inkluderer en facilitet, hvorefter ESDH-systemet forsøger afpublicering et antal gange, og ved gentagne forsøg med negativt udfald - advarer sagsbehandler (og/eller ressortansvarlig) om det negative udfald. Mellemlageret/CMS skal slette elementet ikke bare markere det som slettet eller lignende. Dog må det gerne (bør) gemme en log-information om at elementet er slettet. Det skal sikres, at ESDH-brugere kan få information om den reelle publiceringsstatus, både når det lykkes og når det ikke lykkes at gennemføre afpubliceringen. 16 / 33

17 4 Del C af datamodel og -skemaer 4.1 Publiceringsstatus For at kunne opbevare publiceringsstatus for de publicerede elementer samt elementer, der har været publiceret, skal FESD-datamodellen udvides med to tabeller. En tabel til opbevaring af status, og en støttetabel med udfaldsrummet af status publishingstatus elementid itemid UUID [1] Id på det indholdselement som posten er status for. brugerid useridentifier String [1] Tekststreng der identificerer den bruger, der har bevirket elementets nuværende status. acceptid acceptidentifier String [0..1] Tekststreng der identificerer den bruger, der i egenskab af ressortansvarlig eller lignende har godkendt elementets nuværende status. publiceringsstatusforkortelse StatusCode Code [1] Fremmednøgle til tabellen publishingstatuscode senesteaendringdato- Tid lastchangedatetime DateTime [1] Dato og tid for hvornår publiceringsstatus senest er sat publishingstatuscode publiceringsstatusforkortelse Name [1] Publiceringsstatus betegnelse i klar tekst. StatusCode Code [1] Fremmednøgle til tabellen CaseFileStatusCode publiceringsstatusbetegnelse PublishingStatusName publiceringanmodningstidspunkt afpubliceringanmodningstidspunkt publiceringfaktisk- Tidspunkt afpubliceringfaktisk- Tidspunkt publishrequeststart DateTime [0..1] Dato og tid for hvornår indholdselementet ønskes publiceret. publishrequestend DateTime [0..1] Dato og tid for hvornår indholdselementet ønskes afpubliceret. publishactualstart DateTime [0..1] Dato og tid for hvornår indholdselementet faktisk er blevet publiceret. publishactualend DateTime [0..1] Dato og tid for hvornår indholdselementet faktisk er blevet afpubliceret. Udfaldsrummet for publiceringsstatus skal, jf. forretningskravene ovenfor, som minimum omfatte - Ikke publiceret - Afventer publicering - Publiceret - Afventer afpublicering 17 / 33

18 - Afpubliceret 4.2 Webservice grænseflader Dette afsnit præsenterer de webservices, som hhv. ESDH- og CMS-leverandør kan eller skal stille til rådighed. I det efterfølgende afsnit er anført hvilke webservices der er obligatoriske for den ene eller den anden leverandør getcontenttree Implementeres i CMS. ESDH anmoder CMS om at få en kopi af det indholdshierarki, som eksporteret data kan indplaceres i Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. Dette kan være en generisk bruger, således at alle ESDH-brugere optræder som samme bruger i mellemlagret; eller det kan være ESDH-brugeren også er oprettet i mellemlagret, således at deres brugerid kan bruges i dette Output dannettidspunkt ListGeneratedDate- Time DateTime [1] Tidspunkt for hvornår nodelisten er dannet. dannetsystem ListGeneratorName String [0..1] på systemet, der har produceret nodelisten [1] Liste af menupunkter MenuList-parameter menupunktid MenuItemStructure element menuliste MenuItemCollection element [0*] Et menupunkt container for attributter og elementer der udgør egenskaberne for menupunktet. accepterunderpunkter Id MenuItemIdentifier UUID [1] CMS id på menupunktet. Det er dette id, der er den unikke og utvetydige identifikation af det punkt i CMS indholdshierarki, hvorunder ESDH-elementet indsættes som sideordnet (sibling) eller under-(child-) element. Det vil typisk være et UUid, men det læses som string, da der ikke kan være sikkerhed for at det er et UUid. MenuItemAcceptAttachmentIndicator Boolean [1] For at kunne præsentere ESDH-brugeren for et sammenhængende indholdshierarki, som det er muligt at navigere rundt i, kan 18 / 33

19 det være nødvendigt at inkludere elementer i nodelisten, som CMS ikke accepterer at der hæftes ESDH-elementer på. Såfremt denne attribut er af værdien Sand (1), kan der vedhæftes ESDH-elementer på dette MenuItem; ellers ikke. menutekst MenuItemText String [1] Dette er den tekst, som ESDH-brugeren præsenteres for til navigering i indholdstræet. Det er ikke noget krav at den er præcis som den tilsvarende tekst i CMS, men det skal naturligvis være muligt for ESDHbrugeren entydigt at kunne identificere positionen ud fra teksten og dens relative placeringen i indholdshierarkiet (nodelisten). [0..1] Eventuelle undermenupunkter createcontentposition Kan implementeres i CMS. ESDH skal kunne konfigureres til at benytte dette. ESDH sender oplysning til CMS om hvilket data der sættes ind i indholdshierarkiet med oplysning om hvor det indsættes (men uden data) Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. indholdsplacering contentposition String [0*] Sæt af hhv. indholdselementer og deres indplaceringer contentposition-parameter menuliste MenuItemCollection element elementid ContentitemIdentifier UUID [1] Id på et indholdselement menupunktid menuitemidentifier UUID [1*] Et antal id er på de placeringer som indholdselementet skal tilknyttes Output updatecontentposition Kan implementeres i CMS. ESDH skal kunne konfigureres til at benytte dette. ESDH sender oplysning til CMS om ændrede indsætningspunkter for allerede publicerede indholdselementer Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. 19 / 33

20 indholdsplacering contentposition String [0*] Sæt af hhv. indholdselementer og deres indplaceringer. Se contentpositionparameter ovenfor Output removecontentposition Kan implementeres i CMS. ESDH skal kunne konfigureres til at benytte dette. ESDH sender oplysning til CMS om at et indholdselement er blevet afpubliceret, at og oplysninger om dets indsætningspunkter derfor skal slettes Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. indholdsplacering contentposition String [0*] Sæt af hhv. indholdselementer og deres indplaceringer. Se contentpositionparameter ovenfor Output createcmdata Kan implementeres i CMS. ESDH skal kunne konfigureres til at benytte dette. Modtager pakke med data, der skal hæftes på indholdshierarkiet med oplysning om hvor på træet det skal hæftes på mm Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. dokumentomslag documentwrapper String [0..1] Container-element til et dokument (se documentwrapper-parameter nedenfor) sagsomslag casewrapper String [0..1] Container-element til en sag (se casewrapper-parameter nedenfor) Output updatecmdata Kan implementeres i CMS. ESDH skal kunne konfigureres til at benytte dette. Modtager opdaterede oplysninger om et allerede publiceret indholdselement. 20 / 33

21 Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. dokumentomslag documentwrapper String [0..1] Container-element til et dokument (se documentwrapper-parameter nedenfor) sagsomslag casewrapper String [0..1] Container-element til en sag (se casewrapper-parameter nedenfor) Output removecmdata Kan implementeres i CMS. ESDH skal kunne konfigureres til at benytte dette. Anmoder om at få fjernet et indholdselement fra CMS eller mellemlager Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. elementid ContentitemIdentifier UUID [1] Id på et indholdselement Output getcmcontentlist Bemærk forskellig fra nedenstående, idet denne implementeres i CMS. Kaldes fra ESDH. Returnerer en liste over alle de ESDH-objekter, der optræder i CMS. Dette med henblik på sikkerhedstjek på synkroniteten mellem CMS og ESDH-systemets oplysninger om publiceringsstatus Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system Output indholdsplacering contentposition String [0*] Sæt af hhv. indholdselementer og deres indplaceringer contentposition-parameter 21 / 33

22 elementid ContentitemIdentifier UUID [1] Id på et indholdselement menupunktid menuitemidentifier UUID [1*] Et antal id er på de placeringer som indholdsementet er tilknyttet getcmcontentlist Bemærk forskellig fra ovenstående, idet denne implementeres i ESDH. CMS kan kalde denne webservice for at få oplyst hvilke indholdselementer, der er publiceret. Såfremt der er uoverensstemmelser, kan CMS enten slette overskydende poster lokalt eller hente manglende eller ikkeopdaterede indholdselementer ved brug af servicen getcmdata Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system Output indholdsplacering contentposition String [0*] Sæt af hhv. indholdselementer og deres indplaceringer contentposition-parameter elementid ContentitemIdentifier UUID [1] Id på et indholdselement menupunktid menuitemidemtifier UUID [1*] Et antal id er på de placeringer som indholdselementet er tilknyttet getcmdata Implementeres i ESDH. Kaldes fra CMS. Udleverer dokument eller sag fra ESDH til CMS Input brugerid useridentifier String [1] Tekststreng der identificerer brugeren i det fremmede system. elementid itemidentifier UUID [1] UniqueIdentifier til indholdselementet Output dokumentomslag documentwrapper String [0..1] Container-element til et dokument (se documentwrapper-parameter nedenfor) 22 / 33

23 sagsomslag casewrapper String [0..1] Container-element til en sag (se casewrapper-parameter nedenfor) documentwrapper-parameter elementid contentitemidentifier UUID [1] Id på et indholdselement titeltekst titletext Text [0..1] Dokumentets titel dokumentindhold documentcontentdata String [0..1] Dokumentindholdet i binært format. dokumentdato documentdate Date [0..1] Dokumentdato nummer number Integer(5) [0..1] Dokumentets versionnummer indenfor dokumentet. dokumentversionnummer fra klassen DokumentVersion betegnelsetekst name Name [0..1] Dokumentstatus i klar tekst. fil versionfilename String [0..1] Angiver det præcise filnavn på filen. filekode filecode Char(10) [0..1] Angiver standardformat filtyper eksempelvis DOC for Word. StorageFormat.defaultFile casewrapper-parameter elementid ContentitemIdentifier UUID [1] Id på et indholdselement oprettelsedato creationdate Date [1] Oprettelsesdato for sagen kassationskode diposalcode Name [0..1] Angiver hvad der skal ske når kassationsdatoen er nået Feltet Name fra tabellen CaseFileDisposal kassationdato disposaldate Date [0..1] Kassationdato opdateringregistrator- senestejournalpost- Dato opdateringdato informationupdatedate ansvarligsagsbehandlerreference sagnummerhistorisk- Tekst latestupdateby Name [1] på person, der senest har registreret sagen. Udfyldes om muligt. latestrecorddate Date [0..1] Dato for seneste registrerede journalpost. Date [1] Dato for seneste opdatering. managerreference Name [0..1] Feltet udfyldes med navn på ansvarlig sagsbehandler. Hentes fra standarden Brugeradministration, klassen Bruger, attributten. formercasefilenumbertext Char(40) [0..1] Frit tidligere sagsnr. Eventuelt sammenstillinger af andre felter. Udfyldes med sagnr, hvis sagen har været omjournaliseret. Tidligere sagsnummer. Fri tekst. sagsnummertekst casefilenumbertext Char(40) [1] Frit sagsnummer. papirarkiveringindikator paperstorageindicator Indicator [0..1] Angiver om sagen arkiveres på papirform eller elektronisk. sletningsfrist retentiontimeyear Integer(2) [0..1] Antal år sagen skal bevares. 23 / 33

24 serialnumberidentifier loebenummeridentifikator Sequence- Number [1] Indeholder sagens sekvensnummer eventuelt indenfor året. Anvendes sammen med sagens oprettelsesår til at danne journalnummeret. Entydigt maskingenereret løbenummer. Nulstilles evt. hvert år. tekst text Name [0..1] Sagens status i fritekst titelalternativtekst titlealternativetext Text [0..1] Hvis sagstitlen er uofficiel, kan dette felt indeholde en alternativ officiel sagstitel til postlister etc. Feltet indeholder en alternativ titel i klar tekst. titeltekst titletext Text [1] Sagens titel betegnelsetekst name Name [0..1] Feltet Name fra tabellen CaseFile sagaaridentifikator creationyeartext Year [1] Sagens oprettelsesår dokumentomslag documentwrapper String [0*] Container-element til et dokument (se documentwrapper-parameter ovenfor) Samlet oversigt over webservices For at lette overblikket over de webservices der er beskrevet ovenfor, følger her en samlet oversigt over disse. Envidere er tilføjet kolonnen Egnet til, hvor der med reference til de tre modeller, der er beskrevet i afsnit 3.1, er anført hvilken af disse modeller, webservicen er rettet mod. Som anført i afsnittet Formål (2.2) er det et mål med standarden at tilvejebringe standard snitflader fra ESDH, der er særligt rettede mod CMS. Dette med henblik på at CMS-/integrations-leverandører kan vide hvilke snitflader, der er til rådighed, og ud fra dette vælge hvilken integrationsmodel (og dermed hvilke snitflader), der ønskes i et givent projekt. Således er alle snitflader obligatoriske for ESDH, mens snitfladerne fortrinvis ikke er obligatoriske for CMS. Når der alligevel er to snitflader, der er obligatoriske for CMS, skyldes det, at disse indgår i alle tre integrationsmodeller Implementeres i CMS Obligatorisk for CMS Obligatorisk for ESDH Egnet til getcontenttree Ja Ja model 1 model 2 model 3 createcontentposition Nej Ja model 1 model 3 updatecontentposition Nej Ja model 1 model 3 removecontentposition Nej Ja model 1 model 3 createcmdata Nej Ja model 1 model 2 24 / 33

25 updatecmdata Nej Ja model 1 model 2 removecmdata Nej Ja model 1 model 2 getcmcontentlist Ja Ja model 1 model 2 model Implementeres i ESDH Obligatorisk for CMS Obligatorisk for ESDH Egnet til getcmcontentlist Nej Ja model 1 model 2 model 3 getcmdata Nej Ja model 1 model 3 25 / 33

26 5. I dette afsnit anføres mapning mellem den danske attribut fra standarden og elementnavnet, som er ækvivalent i det tilhørende -skema. Selve -skemaerne findes via Publiceringsstatus publishingstatus (-navn: PubliceringStatusStruktur) elementid brugerid acceptid publiceringsstatusforkortelse ElementIdentifikator BrugerIdentifikator AcceptIdentifikator StatusKode senesteaendringdatotid UpdateDateTime publishingstatuscode (-navn: PubliceringStatusKodeStruktur) publiceringsstatusforkortelse publiceringsstatusbetegnelse publiceringanmodningstidspunkt afpubliceringanmodningstidspunkt publiceringfaktisktidspunkt afpubliceringfaktisktidspunkt StatusKode PubliceringStatus PubliceringAnmodetDatoTid AfpubliceringAnmodetDatoTid PubliceringFaktiskDatoTid AfpubliceringFaktiskDatoTid 5.2 Webservice grænseflader getcontenttree Input (getcontenttreeinput) brugerid BrugerIdentifikator 26 / 33

27 Output (-navn: GetContentTreeOutput) dannettidspunkt ListenetDatoTid dannetsystem ListenetSystem menuliste MenuPunktSamling MenuList-parameter (-navn: MenuPunktStruktur) menupunktid ElementIdentifikator Id MenuPunktIdentifikator accepterunderpunkter AccepterUnderpunkterIndikator menutekst MenuPunktTekst menuliste MenuPunktSamling createcontentposition Input (-navn: ContentPositionInput) brugerid BrugerIdentifikator Indholdsplacering IndholdPlaceringStruktur contentposition-parameter (-navn: IndholdPlaceringStruktur) elementid ElementIdentifikator menupunktid MenuPunktIdentifikator updatecontentposition Input (-navn: ContentPositionInput) brugerid BrugerIdentifikator Indholdsplacering IndholdPlaceringStruktur 27 / 33

28 5.2.4 removecontentposition Input (-navn: ContentPositionInput) brugerid BrugerIdentifikator Indholdsplacering IndholdPlaceringStruktur createcmdata Input (-navn: CMDataInput) brugerid BrugerIdentifikator dokumentomslag DokumentomslagStruktur sagsomslag SagsomslagStruktur updatecmdata Input (-navn: CMDataInput) brugerid BrugerIdentifikator dokumentomslag DokumentomslagStruktur sagsomslag SagsomslagStruktur removecmdata Input (-navn: RemoveCMDataInput) brugerid BrugerIdentifikator elementid ElementIdentifikator getcmcontentlist Input (-navn: getcmcontentlistinput) brugerid BrugerIdentifikator 28 / 33

29 Output(-navn: getcmcontentlistoutput) Indholdsplacering IndholdPlaceringStruktur contentposition-parameter (-navn: IndholdPlaceringStruktur) elementid ElementIdentifikator menupunktid MenuPunktIdentifikator getcmcontentlist Input brugerid BrugerIdentifikator Output Indholdsplacering IndholdPlaceringStruktur contentposition-parameter (-navn: IndholdPlaceringStruktur) elementid ElementIdentifikator menupunktid MenuPunktIdentifikator getcmdata Input (-navn: GetCMDataInput) brugerid BrugerIdentifikator elementid ElementIdentifikator Output (-navn: GetCMDataOutput) dokumentomslag DokumentOmslagStruktur sagsomslag SagsomslagStruktur 29 / 33

30 documentwrapper-parameter (-navn: DokumentOmslagStruktur) elementid titeltekst dokumentindhold dokumentdato nummer betegnelsetekst fil filekode ElementIdentifikator TitelTekst DokumentObjektData DokumentDato BetegnelseTekst Fil FilKode casewrapper-parameter (-navn: SagsomslagStruktur) elementid oprettelsesdato kassationskode kassationdato opdateringregistrator senestejournalpostdato opdateringdato sagnummerhistorisktekst sagsnummertekst papirarkiveringindikator sletningsfrist loebenummeridentifikator tekst titelalternativtekst titeltekst betegnelsetekst sagaaridentifikator dokumentomslag ElementIdentifikator CreatedDate KassationsKode KassationDato OpdateringRegistrator SenesteJournalPostDato UpdateDateTime DokumentVersionNummerKvantitet ansvarligsagsbehandlerreference AnsvarligSagsbehandlerReference SagsnummerHistoriskTekst SagsnummerTekst PapirArkiveringIndikator SletningsfristMaal SerialNumberIdentifier SagStatusTekst TitelAlternativTekst TitelTekst BetegnelseTekst SagAarIdentifikator DokumentOmslagStruktur 30 / 33

31 6. Anvendte typer i FESD-modellerne FESD-modellerne er udarbejdet i UML med det formål at beskrive den logiske informationsarkitektur i en FESD-løsning. UML-modellen er opbygget af et antal klasser, der igen er opbygget af relationer til andre klasser og primitive typer, så man kan opfatte UML-modellen som opbygget af byggesten, hvoraf den mindste er de primitive datatyper. I UML-modellen beskriver de primitive datatyper det logiske domæne, som datatypen kan antage, men ikke hvordan den fysiske repræsentation af data skal være. I skemaerne ses for hver primitiv datatype, der anvendes i FESD-UML-modellen, den tilsvarende datatype for hhv. SQL og XSD. integer Benyttes til angivelse af heltal. Der kan benyttes en angivelse af max længde hvis intet er angivet,vil domænet være i intervallet mellem og Anvendte længder i den nuværende model: 2, 3, 4, 6, 8, 10. Benyttes alene til naturlige tal (positive heltal). Benyttes også til at danne identifikator med udfaldsrum UML SQL datatype XSD datatype Integer Heltal i rummet mellem og , begge tal inclusive. Den maksimale længde angives i modellen NonNegativeInteger Naturlige tal Heltal i rummet mellem 0 og , begge tal inclusive SequenceNumber NonNegativeInteger mellem 0 og begge tal inklusive NUMBER(Maksimal længde) NUMBER(Maksimal længde) NUMBER(Maksimal længde) xsd:int xsd:int xsd:int boolean Er en grundtype i UML. UML SQL datatype XSD datatype Boolean Udfaldsrummet er binært true / false (eller rigtigt / forkert). BOOLEAN xsd:boolean Identifikationstyper UML SQL datatype XSD datatype URI Enhver mulig lovlig URI. Der kan evt. anvendes en maxlængde. STRING xsd:anyuri HttpURI Lovlig http(s)-adresse STRING xsd:anyuri 31 / 33 Evt. restrictions der afgrænser til http.

32 MailToURI Smtp-adresse på en mailmodtager. STRING xsd:anyuri UUID Identifikator på objekt UUID xsd:anyuri UserIdentifier SystemIdentifier BinaryObject Det er en identifikation af bruger Det er en identifikation af systemer Et binary large object - også kaldet blob - er en samling af binære data, der opbevares som en separat entitet i et database management system. Blobs er typisk billeder, lyd og andre medieobjekter, selvom binær eksekverbar kode til tider også opbevares som en blob. Database support for blob er ikke universal. Binary Large Object (BLOB) Evt. restrictions der afgrænser til mailadresser. Evt. restrictions der afgrænser til UUID. char Benyttes til karakterstrenge af varierende længde, men med en defineret maksimal længde. Anvendte længder: 1, 2, 3, 4, 15, 16, 20, 34, 40, 50, 60, 70, 110, 120, 255. Benyttes også nogle steder til at angive en boolsk værdi. UML SQL datatype XSD datatype Char ShortText Text Code Name ReferenceText Den minimale og maksimale længde er angivet i modellen. Anvendes til felter der indeholder en kort beskrivende tekst Anvendes til en beskrivende tekst med en fast længde. Anvendes til at beskrive en kode, der er nøgle/fremmednøgle i en opslagstabel. Anvendes til felter der indeholder navne, der kan opfattes som brugervendte nøgler. Anvendes til felter der indeholder tekster, der af brugerne opfattes som fremmednøgler. VARCHAR(maksimal længde) VARCHAR(70) VARCHAR(255) VARCHAR(2) VARCHAR(70) VARCHAR(40) xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Indicator Til kodeværdier på én karakter VARCHAR(1) xsd:string Med restriction på den maximale længde Med restriction på den maximale længde 32 / 33

33 date, datetime og time. n Date bruges til at angive dato. n DateTime bruges til Dato og tidspunkt, også i betydningen tidsstempel. n Time bruges til klokkeslæt. UML SQL datatype XSD datatype Year Årstal VARCHAR (4) xsd:gyear Date Dato DATE xsd:date DateTime Dato og tidspunkt DATETIME xsd:datetime Time Tidspunkt uden datoangivelse TIME xsd:time string Er en grundlæggende type i UML. UML SQL datatype XSD datatype String Tekststreng af vilkårlig længde STRING xsd:string float Defineres som sådan: UML SQL datatype XSD datatype Float Decimaltal hvor længde og præcision begrænses til en samlet størrelse på 16-bit. DECIMAL(X,Y) xsd:float 33 / 33

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 IT- og Telestyrelsen København den 12. juli 2007 FESD-standardisering Grænseflade

Læs mere

FESD Brugeradministration

FESD Brugeradministration FESD Brugeradministration Standard IT- og Telestyrelsen København den 10. december 2008 FESD standardisering Brugeradministration. Datamodel Version 1.1 Kolofon: FESD standardisering. Brugeradministration.

Læs mere

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008.

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008. FESD Arkivstruktur Standard IT- og Telestyrelsen København den 10. december 2008. FESD-standardisering Arkivstruktur. Datamodel Version 1.1 Kolofon: FESD-standardisering. Arkivstruktur. Datamodel. Version

Læs mere

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 Ø 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 mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

Brugerskabte data en national service (BSD) - produktbeskrivelse

Brugerskabte data en national service (BSD) - produktbeskrivelse - 1 Brugerskabte data en national service (BSD) - produktbeskrivelse Brugerskabte data en national service (BSD) - produktbeskrivelse...1 Indledning...1 Formål...1 Beskrivelse...1 Basale krav til det bibliotek/website

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 FESD standardisering FESD-modul. Skanningsmodul Version 1.0 Kolofon: FESD moduler. Skanningsmodul. FESD standardisering. Skanningsmodul

Læs mere

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 11. december 2008. FESD-standardisering Sikker epostløsning. Grænsesnit. Version 1.1 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

TeamShare 2.1 Versionsnoter Oktober 2009

TeamShare 2.1 Versionsnoter Oktober 2009 TeamShare 2.1 Versionsnoter Oktober 2009 TeamShare version 2.1.292 Denne version af TeamShare har fået mange nye funktioner, samt forbedringer på eksisterende. Hver ny feature er gennemgået i hvert sit

Læs mere

Leverancebeskrivelse - Bilag 1

Leverancebeskrivelse - Bilag 1 Leverancebeskrivelse - Bilag 1 Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service Juli 2008 Dato: 17-07-2008 Kontor: Udviklingsenhed J.nr.: I4148 Sagsbeh.: CHS Fil-navn: Leverancebeskrivelse bilag

Læs mere

FESD standardisering Udveksling Version 1.0

FESD standardisering Udveksling Version 1.0 FESD standardisering Udveksling Version 1.0 Kolofon: FESD standardisering. Udveksling Version 1.0 FESD udvekslingspakke Udarbejdet af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

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

Læs mere

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22 august 2007. IT- og Telestyrelsen København 12. juli 2007 FESD-standardisering FESD Datafølgeseddel.

Læs mere

DKAL Snitflader REST Register

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

Læs mere

Åben indsigt på www.syddjurs.dk

Åben indsigt på www.syddjurs.dk Åben indsigt på www.syddjurs.dk Rigsarkivets konference 4. november 2015 Jon Badstue Pedersen Afdelingsleder Digitalisering Syddjurs Kommune jbp@syddjurs.dk Agenda Manuel publicering Åben indsigt Åben

Læs mere

Att: Mads Ellehammer:

Att: Mads Ellehammer: KL Att: Mads Ellehammer: 27. august 2008 FESD-standardiseringsgruppen har nu færdigbehandlet de indkomne svar til høringen, som løb fra den 22. marts 2008 til 23. maj 2008, og ønsker med dette brev at

Læs mere

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg

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

Vilkår for brug af Støttesystemet Sags- og Dokumentindeks

Vilkå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 mere

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. 1 2 KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. Det er frivilligt for kommuner at aftage systemet. Iht. den fælleskommunale

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

BYG OG MILJØ SAGSBEHANDLER I BYG OG MILJØ. Version 2.0

BYG OG MILJØ SAGSBEHANDLER I BYG OG MILJØ. Version 2.0 BYG OG MILJØ SAGSBEHANDLER I BYG OG MILJØ Version 2.0 Januar 2019 Indholdsfortegnelse OM DENNE VEJLEDNING... 3 SAGSBEHANDLERADGANG I BYG OG MILJØ... 3 Modtagelse af ansøgninger hos myndigheden... 3 Sag

Læs mere

Sag og dokument standarderne - Hvad og hvorfor

Sag og dokument standarderne - Hvad og hvorfor Sag og dokument standarderne - Hvad og hvorfor > Sag og dokument standarderne Hvad og hvorfor Dette dokument kan frit anvendes af alle. Citeres der fra dokumentet i andre publikationer til offentligheden,

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline UBL 2.0 Datatyper OIOUBL Datatypes G29 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: IT- & Telestyrelsen E-mail: oioubl@itst.dk OIOUBL

Læs mere

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Bilag 1 Vurdering af økonomiske konsekvenser af beslutningsforslag B 103 1. Indhold i beslutningsforslag B 103 Det overordnede

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Dokument Reference UBL 2.0 Document Reference G21 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen

Læs mere

CCS Formål Produktblad December 2015

CCS Formål Produktblad December 2015 CCS Formål Produktblad December 2015 Kolofon 2015-12-14

Læs mere

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

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

Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem

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

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 17-06-2014 MST Oprettelse af krav 0.2 18-05-2014 MST Tilretning af tabeller 0.3 18.06.2014 PKR

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

Vejledning til KOMBIT KLIK

Vejledning til KOMBIT KLIK Vejledning til KOMBIT KLIK KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 0 Version Bemærkning til ændringer/justeringer Dato Ansvarlig 1.0 Første

Læs mere

Introduktion til OPC Access

Introduktion til OPC Access Introduktion til OPC Access OPC Access anvendes til at kommunikere med jeres produktionsudstyr via OPC. OPC Access kombinerer en SQL Server med OPC, således at jeres produktionsudstyr kobles sammen med

Læs mere

CCS klassifikation og identifikation

CCS klassifikation og identifikation UDVEKSLINGSSPECIFIKATION klassifikation og identifikation Udgivet 01.09.2017 Revision 0 Molio 2017 s 1 af 19 Forord Denne udvekslingsspecifikation beskriver, hvilke egenskaber for klassifikation og identifikation,

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

KOMBIT Byg og Miljø FAQ. Byg og Miljø. Version 1.1 24. januar 2014 BHE

KOMBIT Byg og Miljø FAQ. Byg og Miljø. Version 1.1 24. januar 2014 BHE KOMBIT Byg og Miljø FAQ Byg og Miljø Version 1.1 24. januar 2014 BHE Indhold Login og rettigheder... 3 Aktiviteter, sager, projekter... 4 Regler... 5 Proces... 6 Kommunikation... 7 Filer... 8 Integration

Læs mere

FESD Datafølgeseddel

FESD Datafølgeseddel FESD Datafølgeseddel Standard IT- og Telestyrelsen København den 11. december 2008. FESD-standardisering FESD Datafølgeseddel. Protokol. Version 1.1 Kolofon: FESD-standardisering. FESD Datafølgeseddel.

Læs mere

Introduktion til redigeringsfaciliteterne

Introduktion til redigeringsfaciliteterne Sitecore Foundry 3.0 Introduktion til redigeringsfaciliteterne 25. april 2012 - Version 1.2 Pentia A/S Store Kongensgade 66, Baghuset 1264 København K Telefon: 7023 3330 E-mail: info@foreningssite.dk Indholdsfortegnelse

Læs mere

Dokumentation af optagelse.dk

Dokumentation af optagelse.dk ApplicationService Indhold Versionsstyring Introduktion Navn URL Formål Sikkerhed Operationer echo() findftuapplicationids(...) findftuapplicationbyid(...) findftuapplicationpdfbyid(...) findftuapplicationenclosurezipurlbyid(...)

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

D INTEGRATIONSDESIGN FOR DATAAFTAGERE

D INTEGRATIONSDESIGN FOR DATAAFTAGERE DIGST ORKESTRERINGSKOMPONENT D0180 - INTEGRATIONSDESIGN FOR DATAAFTAGERE Version: 1.3 Status: Endelig Godkender: Forfatter: Copyright 2019 Netcompany. Alle rettigheder forbeholdes. Dokumenthistorik Version

Læs mere

Det skal understreges, at kassation af dokumenter er en mulighed, og ikke en pligt for kommunerne.

Det skal understreges, at kassation af dokumenter er en mulighed, og ikke en pligt for kommunerne. KL notat 26-06-2014/FLN Beslutning om kassation i ESDH-systemer med tjekliste Notatet er til brug for den kommunale myndigheds beslutning, om den vil gøre brug af muligheden for kassation fra ESDH eller

Læs mere

Vejledning i at anvende åbningskvittering. Juli 2016

Vejledning i at anvende åbningskvittering. Juli 2016 Vejledning i at anvende åbningskvittering Juli 2016 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du vil anvende åbningskvittering på materialer. Du skal have en af følgende roller

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

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...

Læs mere

Guide til Umbraco CMS

Guide til Umbraco CMS web Guide til Umbraco CMS Indhold Indledning 3 Kompatible browsere 3 Log ind i Umbraco 4 Content-delen 5 Indholdstræet 5 Tilføjelse af en side/sektion 7 Sortering af indhold 12 Galleri 14 Mediebibliotek

Læs mere

Dokumentation af optagelse.dk

Dokumentation af optagelse.dk ApplicationService Indhold Versionsstyring Introduktion Navn URL Formål Sikkerhed Operationer echo() findftuapplicationids(...) findftuapplicationbyid(...) findftuapplicationpdfbyid(...) findftuapplicationenclosurezipurlbyid(...)

Læs mere

Mdoc - dit fremtidige ESDH system

Mdoc - dit fremtidige ESDH system Mdoc - dit fremtidige ESDH system Dokumenthåndteringssystemet Mdoc samler alle organisationens dokumenter i ét system. Mdoc håndtere alle typer af dokumenter, e-mails, kontrakter, referater m.v. Samtidig

Læs mere

Standard IT- og Telestyrelsen København den 17. december 2007

Standard IT- og Telestyrelsen København den 17. december 2007 Standard IT- og Telestyrelsen København den 17. december 2007 FESD-standardisering FESD Datafølgeseddel. Protokol Version 1.0 Kolofon: FESD-standardisering. FESD Datafølgeseddel. Protekol. Version 1.0

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

Beskrivelse af KMD Nova ESDH Dagsorden version BESKRIVELSE AF RELEASE KMD NOVA ESDH. Side 1 af 23

Beskrivelse af KMD Nova ESDH Dagsorden version BESKRIVELSE AF RELEASE KMD NOVA ESDH. Side 1 af 23 rs BESKRIVELSE AF RELEASE 1.7.0 KMD NOVA ESDH Side 1 af 23 Forord KMD frigiver release 1.7.0 af KMD Nova ESDH den 17.11.2018. Dette dokument beskriver den nye funktionalitet Ønsker du en beskrivelse af

Læs mere

TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem

TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem 3456.78 123456 TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem 30. juli 2015 Indhold Indledning Side 3 Sådan kommer du i gang Side 4 Oprette nye varer Side 5 Ændre eksisterende

Læs mere

Introduktion til MeMo

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,

Læs mere

Høringssvar vedr. Serviceinterface for Person

Høringssvar vedr. Serviceinterface for Person Høringssvar vedr. Serviceinterface for Person 1. Indledning... 3 1.1 Arkitekturmæssige overvejelser... 3 2. Konkrete ændringsforslag... 5 2.1 Variable attributnavne... 5 2.2 Registeroplysninger fra akkreditiv...

Læs mere

FESD Ledelsesinformation

FESD Ledelsesinformation FESD Ledelsesinformation Version 2.1 Standard IT- og Telestyrelsen København den 18. december 2008. FESD-standardisering Ledelsesinformation. Modul. Version 2.1 Kolofon: FESD-standardisering. Ledelsesinformation.

Læs mere

DKAL Snitflader Masseforsendelse

DKAL Snitflader Masseforsendelse DKAL Snitflader Masseforsendelse 1 C.1 Indholdsfortegnelse C.1 INDHOLDSFORTEGNELSE... 2 C.2 LÆSEVEJLEDNING... 3 C.3 TILMELDINGSLISTE... 4 C.3.1 RECORD-STRUKTUR... 4 C.3.2 OIOXML-STRUKTUR... 5 C.4 MATERIALE-INDLÆSNING...6

Læs mere

ITD ecmr WEB Services. Af Allan Wisborg, IT Udvikler

ITD ecmr WEB Services. Af Allan Wisborg, IT Udvikler Af Allan Wisborg, IT Udvikler Til løsningen ecmr Det elektroniske fragtbrev udbydes en række offentlige WEB services. Dette er beskrivelsen af disse services og hvorledes de anvendes. 21. December 2015

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

GeoGIS2020. Installation. Udkast. Revision: 1 Udarbejdet af: BrS Dato: Kontrolleret af: Status: Løbende Reference: Godkendt af:

GeoGIS2020. Installation. Udkast. Revision: 1 Udarbejdet af: BrS Dato: Kontrolleret af: Status: Løbende Reference: Godkendt af: GeoGIS2020 Installation Udkast Revision: 1 Udarbejdet af: BrS Dato: 2015.08.31 Kontrolleret af: Status: Løbende Reference: Godkendt af: 1. GENERELT Side 2 af 16 Side 3 af 16 2. DOWNLOAD OG INSTALLATION

Læs mere

Vejledning i at oprette postkasser i Digital Post. August 2019

Vejledning i at oprette postkasser i Digital Post. August 2019 Vejledning i at oprette postkasser i Digital Post August 2019 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal oprette en postkasse og/eller mapper til postkasser. Du skal

Læs mere

VEJLEDNING Vejledning til lokaladministartorfunktionaliteten. Sundhedsdatastyrelsens Elektroniske Indberetningssystem

VEJLEDNING Vejledning til lokaladministartorfunktionaliteten. Sundhedsdatastyrelsens Elektroniske Indberetningssystem VEJLEDNING 2019 Vejledning til lokaladministartorfunktionaliteten Sundhedsdatastyrelsens Elektroniske Indberetningssystem Forord Dette er en brugermanual (1. udgave), der teknisk beskriver, hvordan man

Læs mere

Bilag 3. Teknisk løsningsbeskrivelse

Bilag 3. Teknisk løsningsbeskrivelse Bilag 3 Teknisk løsningsbeskrivelse Side 1 af 14 Indholdsfortegnelse 3 TEKNISK LØSNINGSBESKRIVELSE...3 3.1 Vejledning til udfyldelse af bilag...3 3.2 Vision for IT-arkitekturen...4 3.3 Generel arkitektur...5

Læs mere

Hvilke maskiner kan komme med på nettet.

Hvilke maskiner kan komme med på nettet. Maskiner på DMiBrugt Det er muligt at få både nye og brugte maskiner med på DMiBrugt. Der dannes en xml fil der overføres til DMiBrugt, som så opdaterer deres internet side over maskiner til salg. Hvilke

Læs mere

Pensioneringsprocessen/Statens Administration

Pensioneringsprocessen/Statens Administration PENSAB Pensioneringsprocessen/Statens Administration Indhold 1. Overblik over den samlede proces... 2 2. Tildel pensionssag... 3 2.1 Søg i listen [Pensionssager]... 5 2.2 Tildel sag... 5 2.3 Afgiv sag...

Læs mere

LinkGRC. Dokumenter. Brugermanual

LinkGRC. Dokumenter. Brugermanual Brugermanual 1 INDHOLD 1. Navigation 2. Dashboard 3. 4. Support 2 NAVIGATION 1 På forsiden finder du dine installerede moduler i LinkGRC løsningen og du kan her vælge hvilket modul du ønsker at arbejde

Læs mere

Specifikation af serviceinterface for sag. Denne standard er godkendt af OIO-komiteen december 2009

Specifikation af serviceinterface for sag. Denne standard er godkendt af OIO-komiteen december 2009 Specifikation af serviceinterface for sag Denne standard er godkendt af OIO-komiteen december 2009 > Specifikation af serviceinterface for sag Denne standard kan frit anvendes af alle. Citeres der fra

Læs mere

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang 29.04.2015 USS/XSTJ Version 1.3 1. Indledning... 2 2. Proces for kundestyret dataadgang... 2 2.1 Fuldmagtsgivning

Læs mere

Journalinstruks Aarhus Universitet gældende fra 1. december 2016 til 1. december 2021

Journalinstruks Aarhus Universitet gældende fra 1. december 2016 til 1. december 2021 Journalinstruks Aarhus Universitet gældende fra 1. december 2016 til 1. december 2021 Indhold Formål... 2 Lovgrundlag... 2 Lov om offentlighed i forvaltningen... 2 Forvaltningsloven... 2 Arkivloven...

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation Udgave 2 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Accepttest-specifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC

Læs mere

Grafdage Feltregistrering

Grafdage Feltregistrering Grafdage 2018 Feltregistrering Selv om rejsen fra papir til digital format har stået på i årtier, så er behovet for registrering langt fra dækket. Faktisk ser det ud til at behovet stiger, og især inden

Læs mere

BBR OIOXML. Vejledning til snitfladen: Address.wsdl

BBR OIOXML. Vejledning til snitfladen: Address.wsdl OIOXML Vejledning til snitfladen: En vejledning rettet mod 3. part. Ændringer i forhold til forrige versioner Version 1.0 Første version, 15.01.2010 Version 1.1.0 5.2.2010: Opdateret med de tilbagemeldinger

Læs mere

vorbasse.dk Redaktørmanual Kentaur

vorbasse.dk Redaktørmanual Kentaur Redaktørmanual Kentaur Indholdsfortegnelse Kapitel 1 - TYPO3 Brugerfladen 3 Log ind 3 Backend 4 Frontend 5 Hvor skal jeg klikke? 5 Gem, gem og vis, gem og luk 6 Kapitel 2 - Sider & menuer 7 Sammenhæng

Læs mere

Web governance model for SSI

Web governance model for SSI Web governance model for SSI Oplæg til web kommunikationsgruppen December 2008 1 Indledning... 3 Afgrænsning... 3 Roller og ansvar... 4 Webredaktøren... 4 Forfattere... 5 Overordnet ansvarlig... 5 Webredaktører

Læs mere

Bilag 3 FODS 8.2, Fuldt Digital Lokalplaner Kravspecifikation.

Bilag 3 FODS 8.2, Fuldt Digital Lokalplaner Kravspecifikation. HLA 11. juli 2012 Bilag 3 FODS 8.2, Fuldt Digital Lokalplaner Kravspecifikation. Dette notat indeholder kravspecifikationen til offentligt udbud vedrørende Fuldt Digitale Planer og udgør således bilag

Læs mere

Boligportal.dk s kravspecifikation til XML-feed

Boligportal.dk s kravspecifikation til XML-feed Boligportal.dk s kravspecifikation til XML-feed Introduktion I forbindelse med automatisk import af lejeboliger til Boligportal.dk skal der udarbejdes en XML-feed, som Boligportal.dk kan hente på en URL.

Læs mere

Login og introduktion til SEI2

Login og introduktion til SEI2 BRUGERVEJLEDNING 2019 Login og introduktion til SEI2 Sundhedsdatastyrelsens Elektroniske Indberetningssystem Forord Dette er en brugermanual (1. udgave), der teknisk beskriver, hvordan man logger på Sundhedsdatastyrelsens

Læs mere

Vejledning til brugeradministrator. EDI systemet for FP attester og journaloplysninger

Vejledning til brugeradministrator. EDI systemet for FP attester og journaloplysninger Vejledning til brugeradministrator EDI systemet for FP attester og journaloplysninger 1. april 2019 Vejledning til brugeradministrator oprettelse af afdelinger og brugere til EDI FP attester Denne vejledning

Læs mere

Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system.

Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system. Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system. I dette notat gøres rede for Hvordan visning af dagsordener og referater teknisk set kører i dag, Valg af

Læs mere

Dataanalyse og databaser

Dataanalyse og databaser Dataanalyse og databaser En database er lang række data, der er blevet struktureret således, at der er relationer mellem tabellerne og det er muligt at indsætte og udtrække den ønskede information fra

Læs mere

Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011

Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011 Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011 Indholdsfortegnelse 1. Indledning... 3 1.1 Baggrund... 3 1.2 Blanketternes anvendelse... 4 1.3 Den papirbaserede arbejdsgang... 5 1.4 Den fremtidige

Læs mere

N OT AT. Arbejdsgang i forbindelse med afsendelse af dokument til Dokumentboks. Overordnet vision til håndtering afsendelse af dokumenter

N OT AT. Arbejdsgang i forbindelse med afsendelse af dokument til Dokumentboks. Overordnet vision til håndtering afsendelse af dokumenter N OT AT Arbejdsgang i forbindelse med afsendelse af dokument til Dokumentboks Dette notat indeholder en beskrivelse af arbejdsgange til håndtering af afsendelse af dokumenter til Dokumentboksen eller måske

Læs mere

Sundhedsstyrelsens vejledning om udarbejdelse og revision af målbeskrivelser i speciallægeuddannelsen

Sundhedsstyrelsens vejledning om udarbejdelse og revision af målbeskrivelser i speciallægeuddannelsen VEJ nr 9005 af 01/01/2012 (Gældende) Udskriftsdato: 19. februar 2015 Ministerium: Ministeriet for Sundhed og Forebyggelse Journalnummer: Sundhedsstyrelsen, j.nr. Senere ændringer til forskriften Ingen

Læs mere

Boligportal.dk s kravspecifikation til XML-feed

Boligportal.dk s kravspecifikation til XML-feed Boligportal.dk s kravspecifikation til XML-feed Introduktion I forbindelse med automatisk import af lejeboliger til Boligportal.dk skal der udarbejdes en XML-feed, som Boligportal.dk kan hente på en URL.

Læs mere

1 Objekt informationsmodel - Byggeblok

1 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 mere

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen... 3 2 Formål

Læs mere

DDElibra H Å N D B O G

DDElibra H Å N D B O G H Å N D B O G Axiell Danmark A/S 2016-10-12 Version 9.11.60 GUI Copyright 2016 2 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Introduktion... 3 3 Søgning i dokumentationen... 3 4 Åbning af ""...

Læs mere

Vejledning i at anvende åbningskvittering. August 2019

Vejledning i at anvende åbningskvittering. August 2019 Vejledning i at anvende åbningskvittering August 2019 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du vil anvende åbningskvittering på materialer. Du skal have en af følgende

Læs mere

Vejledning til Jobnet for Arbejdsgiver JobAG. CV-søgning

Vejledning til Jobnet for Arbejdsgiver JobAG. CV-søgning Vejledning til Jobnet for Arbejdsgiver JobAG CV-søgning Version: 1.0 Oprettet den 20. december 2018 INDHOLD 1. INDLEDNING... 3 2. CV-SØGNING OG FORSIDEN AF JOBAG... 3 3. CV-SØGNING... 5 3.1 OPSÆTNING AF

Læs mere

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

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,

Læs mere

Generelle handelsbetingelser. Mail: Tlf.: Node Company IVS CVR.:

Generelle handelsbetingelser. Mail: Tlf.: Node Company IVS CVR.: Generelle handelsbetingelser Mail: kontakt@webmaestro.dk Tlf.: +45 25 13 17 21 CVR.: 38770578 Introduktion Dette dokuement indeholder generelle handelsbetingelser for ( Node Company ), der drives under

Læs mere

Anvendelse af dobbelthistorik i GD2

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:

Læs mere

Høringsnotat - specifikation af serviceinterface for SAG version 1 2

Hø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 mere

KOMBIT Videncenter. Bestemmelser til it-kontrakter om efterlevelse af Arkivloven. Version 1.0 (april 2017)

KOMBIT Videncenter. Bestemmelser til it-kontrakter om efterlevelse af Arkivloven. Version 1.0 (april 2017) KOMBIT Videncenter Bestemmelser til it-kontrakter om efterlevelse af Arkivloven Version 1.0 (april 2017) KOMBIT A/S, Halfdansgade 8, 2300 København S, CVR. 19 43 50 75 Indholdsfortegnelse 1. Indledning...

Læs mere

DAR OIO vejledning Version 1.2

DAR OIO vejledning Version 1.2 DAR OIO vejledning Version 1.2 Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer...

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.

Læs mere

Import af udtræk af ODIN-data i Access-databaser

Import af udtræk af ODIN-data i Access-databaser September 2006 OBS: Kun brugere, der har rettigheden Redningsberedskabsadministrator, kan eksportere data fra ODIN. Der er mange muligheder for udtræk af data fra ODIN, men ved at anvende udtrækkene Alarmer,

Læs mere

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere