Teknisk uddybning af generelle egenskaber for sags- og dokumentområdet
|
|
- Sigrid Mathiasen
- 8 år siden
- Visninger:
Transkript
1 Teknisk uddybning af generelle egenskaber for sags- og dokumentområdet
2 Teknisk uddybning af generelle egenskaber for sags- og dokumentområdet Denne vejledning kan frit anvendes af alle. Citeres der fra vejledningen i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Vejledningen er udarbejdet af OIOudvalget for tværgående sags- og dokumenthåndtering. Kontaktperson for OIO-udvalget: Projektleder Carsten Rohde Mailadresse: carr@itst.dk Direkte telefon: Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade København Ø Telefon: Fax: Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside: ISBN (internet): ISBN:
3 Teknisk uddybning af generelle egenskaber for sags- og dokumentområdet OIO-udvalget for sags- og dokumentområdet 18. marts 2011
4 Indhold > 1. Indledning Læsevejledning Målgruppe Notation 5 2 Fra forretningsobjekt til serviceinterface Objektets anatomi Objektets ID ObjektRegistrering Attributter Relationer Tilstande UML Diagrammering Eksempel på Objekt Dokument Registrering Attributter Relationer Tilstande Samlet virkning Temporale egenskaber Systemtid Registrering Virkning Eksempel 26 3 Service Operationer Løsningsarkitektur Input Output Fejlhåndtering Transportprotokol Data Service API Opret Læs Opdatér Slet Import Passiv List Søg Hændelser Baggrund Hvad er en hændelse? Operation API for Hændelser Hændelsesfordeler HændelsesModtager 37 4 Referencer 38
5 1. Indledning > 1.1 Læsevejledning Dette dokument knytter sig til de Sag og dokument specifikationer, som er udarbejdet under OIO-udvalget for sags- og dokumentområdet, og som blev godkendt som standarder af OIO-komitéen i december Nærmere bestemt er nedenstående en teknisk uddybning af den ene af disse standarder, Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet, og indeholder en mere detaljeret gennemgang af de generelle egenskaber ved de forskellige serviceinterfaces. Dette er således det dokument som i høringsbrevet i forbindelse med specifikationerne, nævnes som yderligere dokumentation for de generelle egenskaber 2. Dette dokument beskriver objekter, tilstande og relationer, men beskæftiger sig især indgående med de temporale egenskaber (registrering og virkning) samt de til specifikationerne knyttede operationer. Det skal videre nævnes, at IT- og Telestyrelsen har gennemført en POC (Proof of Concept), der illustrerer, at principperne bag specifikationerne kan implementeres i systemer, samt at Odense Kommune har gennemført en POB (proof of Business), hvor standarden Organisation er implementeret på en kørende organisatiosnkomponent 3. Nærværende dokument er inspireret af den førstnævnte POC, der har brugt specifikationen Specifikation af serviceinterface for dokument som grundlag, hvorfor serviceinterfacet Dokument bruges som eksempel i store dele af materialet Målgruppe Målgruppen for dette dokument er i første række arkitekter hos softwareleverandører, som skal implementere disse interfaces. I anden række arkitekter i den offentlige sektor, som overvejer at anskaffe interfaces som beskrevet i specifikationerne Notation UML - Der bruges UML 2.0 notation i diagrammerne og domæne modeller. Pseudokode der bruges pseudokode i eksemplerne. Der bruges XML fragmenter i nogle af eksemplerne. Kode/Pseudokode er skrevet i NewCourier font
6 2 Fra forretningsobjekt til serviceinterface Referencearkitekturen 4 ( Referencearkitektur for sags- og dokumentområdet (ESDH), 2008 ), har defineret en række forretningsobjekter, og det er bl.a. dem som efterfølgende er udmøntet i specifikationer for serviceinterfaces på områderne: Sag Dokument Arkivstruktur Organisation Klassifikation Specifikationerne har følgende implicitte forudsætninger: De angiver de informationer et objekt indeholder og hvordan operationer påvirker det. Et serviceinterface bliver repræsenteret som et service endpoint med metoder (operationer). Serviceinterfacets logiske struktur bliver returneret efter et servicekald. Beskrivelsen af objekter i den følgende dokumentation vedrørende serviceinterfaces bygger på, at der er en række fælles generelle egenskaber for objekterne. 2.1 Objektets anatomi Der kan opstilles en udbygget generaliseret model for alle objekter i de nævnte specifikationer, som vist i nedenstående figur 1. Modellen giver overblik over objekt, attributter, tilstande og relationer samt temporale egenskaber (se senere om virkning og registrering som behandles mere grundigt i afsnit om Tidsbaserede ændringer temporale egenskaber )
7 class ObjektRegistreringUdfoldet TilstandVirkning - aktørid : UUID - fra: Timestamp - note: Text Registrering - aktørid : UUID - fra: Timestamp - livcyklus: LivCyklus - note: Text Name: ObjektRegistreringUdfoldet Author: Agata Version: 1.0 Created: :56:28 Updated: :37: AttributModel Tils tand «virkning» T:Tilsta ndsmodel +Tilstande A:AttributModel R:RelationsModel T:Tilsta ndsmodel ObjektRegistrering A:AttributModel - objektid: UUID +Attributter + attributmodel() : A:AttributModel + relationmodel() : R:RelationsModel + tilstandmodel() : T:TilstandsModel 1 1 «virkning» Attribut 1 TilstandsModel Virkning - aktørid: UUID - fra: Timestamp - note: Text + til: Timestamp Relationer 0..* R:Rela tions Model Relation «virkning» + note: Text 1 RelationsModel Figur 1. ObjektRegistrering med stereotyper Alle begreberne i ovenstående diagram er forklaret i følgende tabel: Diagramelement Forklaring ObjektRegistrering ObjektRegistrering er en supertype, som repræsenterer tilstanden for en ressource efter kaldet af en service operation. ObjektRegistrering er modelleret som en TemplateType, der er afhængig af en AttributModel, en RelationsModel og en TilstandsModel. Konkret betyder det at subtyper, såsom Dokument, bliver bundet til supertypen ved at de definerer deres egne modeller. Registrering En ObjektRegistrering har tilknyttet en unik Registrering, som repræsenterer transaktionstidspunktet for serviceoperationen. Virkning Virkning bruges til at udstyre dele af objektet (Attributter, Relationer, Tilstande) med egenskaber vedr. tidsperspektiv. TilstandVirkning En tilstand kan også have en virkning, men den må ikke have en udløbsperiode. 7
8 AttributModel RelationsModel TilstandsModel Attribut Relation Tilstand På det generelle niveau er AttributModellen abstrakt. Den er implementeret for det enkelte serviceinterface og beskriver, hvilke attributter servicen har. På det generelle niveau er RelationsModellen abstrakt. Den er implementeret for det enkelte Serviceinterface og beskriver, hvilke relationer servicen har. Samlingen af relationer i et objekt kaldes for Relationsmodellen På det generelle niveau er TilstandsModellen abstrakt. Den er implementeret for det enkelte serviceinterface, og beskriver hvilke tilstande servicen har. Repræsenterer en datastruktur, som er et delelement af objektet. Attributter kan tilknyttes Virkning. Repræsenterer en reference til en ressource (et fremmed forretningsobjekt), som skal tilgås via en service. Relationer kan tilknyttes Virkning. Tilstand specificerer en semantisk egenskab ved objektet. Vi opererer med få tilstandstyper pr. objekt, hver med fastdefinerede værdier Objektets ID Objektet får tildelt en globalt entydig objektid af typen UUID, når den oprettes. Selv om objektet skifter tilstand og indhold over tid, kan dens UUID ikke ændres det er en del af servicens forretningslogik. UUID bruges til at knytte data sammen på tværs af services, og på tværs af Registreringer og Virkninger ObjektRegistrering Et objekt i denne sammenhæng er egentlig en instans af et objekt, som det ser ud på et givet registreringstidspunkt det omtales som instansens registrering eller Objekt(Ix,rx). På denne måde er ethvert Objekt repræsenteret af en eller flere ObjektRegistreringer. En instans af et objekt bevarer sin Objekttype og objektid i forskellige registreringer. O(i1,t1), O(i1,t2), O(i1,t3)... 8
9 En ObjektRegistrering er immutabel, dvs. den kan ikke ændres. I stedet for skal servicen danne nye instanser af ObjektRegistering, med ny registreringstid, opdaterede værdier og evt. med ændret livscyklus. En ny ObjektRegistreringsinstans bliver skabt efter hvert af følgende operationskald: Opret Ret Slet Importer Passiver Der kan kun rettes og slettes på baggrund af den seneste registrering af instansen. Derimod kan man liste og/eller søge alle registreringer af objektinstansen. (Se endvidere afsnit om Service operationer for yderligere beskrivelse af operationer knyttet til serviceinterface) Attributter En attribut er et element, som har en virkningsperiode. Dermed kan attributternes indhold ændres over tid. Objekter kan indeholde Attributter. For eksempel har klassen dokument en attribut, kaldet DokumentEgenskaber: Relationer DokumentEgenskaber Titel:Text AndenTitel:Text... En relation udtrykker en reference til en ressource i en anden service, kaldet FremmedObjekt. Relationer har virkningsperiode. Dermed kan relationens indhold ændres over tid. Samlingen af relationer i et objekt kaldes for Relationsmodellen. Som eksempel vises et udsnit af relationsmodellen for Dokument i figur 2, og det fremgår at: Dokument har en relation til en række af ressourcer i servicen Dokument (sig selv, eller en anden), og relationen hedder Bilag. Der findes endnu en relation af kardinaliteten 1..n til servicen Dokument, med navnet AndetDokument. Der findes en relation med kardinaliteten 1 til servicen Dokument med navnet Udgangspunkt. Dokument har en relation til en række ressourcer i servicen Arkiv. 9
10 Af figuren fremgår endvidere at Dokument har en single relation til aktør og en pluralrelation til Aktør. Figur 2. Relationsmodel, her vist for nogle af relationerne defineret i Dokument Tilstande Tilstande bliver defineret med faste udfaldsrum, da tilstand er en egenskab, der kan beskrive noget om objektet på en tidsakse. Den kan f.eks. beskrive fremdrift, publicering, kvalitet o.l. Tilstande kan også have en virkning, men denne fungerer lidt anderledes end for almindelig virkning. En TilstandVirkning har et fra tidspunkt, men ikke noget til. Dermed kan en tilstand kun afløses af en anden tilstand. 10
11 2.1.6 UML Diagrammering Temporal mønster og Stereotypen <<virkning>> Vi har valgt at anvende gentagne mønstre til at illustrere, hvordan tidsmæssig virkning hænger sammen med modellens elementer. For at ende med overskuelige diagrammer, er det valgt at bruge stereotyper til at præsentere det tidsmæssige mønster med virkning. Vi anvender stereotyper til at præsentere ændringer over tid for: Virkning på Tilstande Virkning på Attributter Virkning på Relationer Specielle tilpasninger, specifikke for det enkelte serviceinterface. Vi tegner stereotypen <<virkning>> henover en UML-association for at angive, at der i virkeligheden findes en Kollektion af elementer, hver med deres Virkning. Vi siger, at vi filtrerer objektet mht. et virkningsinterval, når der vælges en delmængde, som svarer til en bestemt virkningsperiode. Dette mønster og notationsform følger Martin Fowlers Temporal Patterns, se [Fowler]. Nedenfor vises et eksempel på et udsnit af UML diagrammet for Dokument, hvor stereotypen <<Virkning>> er anvendt i target-role endepunktet for associationerne fra DokumentRelationModel. I virkeligheden findes der en Kollektion af relationer af typen Arkiv, hver med deres Virkning. Men da virkninger ikke kan overlappe, er der til hvert tidspunkt kun én ArkivRelation, som gælder. Collection<Arkiv> 11
12 class DokumentTemporalMønster RelationsModel DokumentRelati onmodel FlerArkivRelation «virkning» Arkiv 1 «virkning» FlerDokumentRelation 0..1 Bil ag Diagrammering med temporal mønster præsenteret vha sterotypen <<virkning>> «virkning» 0..1 AktørRelation PrimærSags behandler :DokumentRelationModel 1 ArkivVirkninger 1..* Arkiv :FlerArkivRelation BilagVirkninger Bilag : FlerDokume ntrelation 0..* Diagrammering med temporal mønster præsenteret uden sterotypen <<virkning>> Figur 3. Temporal mønster vises i UML diagram med stereotypen <<virkning>> Template klasser og <<binding>> Vi anvender en parameteriseret klasse (aka template typer) til at definere en generel struktur som en template. Funktionaliteten kan implementeres ved at binde en type til den parameteriserede klasse og når der bindes skal det fremgå, hvilke typer, der bliver bundet til hvilke parametre. Et klassisk sted, hvor parameteriserede klasser bliver brugt er i Kollektionsbiblioteket i Java/C#. ObjektRegistrering er en parameteriseret klasse, med følgende parametre: A er et parameter af typen AttributModel R er et parameter af typen RelationsModel T er et parameter af typen TilstandsModel I stedet for at en klasse specialiserer en template klasse, kan det anføres, at klassen bindes til Template klassen. 12
13 Det foregår ved at bruge en dependency association sammen med <<bind>> stereotypen. Af eksemplet nedenunder fremgår, at Dokument er bundet til ObjektModel med følgende parametre: DokumentAttributModel i stedet for A DokumentRelationsModel i stedet for R DokumentTilstandModel i stedet for T. 2.2 Eksempel på Objekt Dokument Som beskrevet i forrige kapitel er der knyttet en række generelle egenskaber til de enkelte objekter. I dette kapitel vil et konkret eksempel på en informationsmodel modellen for Dokument blive gennemgået med henblik på at beskrive, hvorledes den konkrete model relaterer sig til de generelle egenskaber Registrering Figur 5 viser et udsnit af informationsmodellen for Dokument. Objektet Dokument indeholder i overensstemmelse med beskrivelsen af de generelle egenskaber et ID af typen UUID. Derudover indeholder Dokument en brugervendt nøgle. Formålet med den brugervendte nøgle er at have en uforanderlig identifikation af dokumentet, som, i modsætning til dokumentets ID, kan præsenteres for brugeren. 13
14 Figur 4. DokumentRegistrering Et dokument indeholder et antal registreringer kaldet DokumentRegistrering. Der skabes en ny DokumentRegistrering, hver gang der udføres en operation, som ændrer dokumentets attributter, tilstande eller relationer. Elementet Registrering angiver dato og tid for registreringen, en henvisning til den aktør, som har foretaget registreringen, samt dokumentets livscyklus. Endelig er det muligt at knytte en note til registreringen. 14
15 2.2.2 Attributter Til ethvert objekt er knyttet et antal attributter. I informationsmodellen for Dokument anbringes disse attributter i et element kaldet DokumentAttributListe. Til en given DokumentRegistrering hører netop en DokumentAttributListe. For Dokument findes der netop en type af attribut, nemlig attributten Egenskaber, som er af typen DokumentEgenskaber. Selve typen DokumentEgenskaber består af et antal felter, som er nærmere beskrevet i standarden for Dokument. I denne forbindelse er der to forhold, som det er værd at bemærke: For det første repræsenterer feltet Titel i attributten Egenskaber dokumentets Objektnavn. Titel er således den konkrete betegnelse for den generelle betegnelse Objektnavn. For det andet har DokumentEgenskaber tilknyttet Virkning. Det betyder, at dokumentets Egenskaber kan ændre sig over tid. For en konkret DokumentRegistrering kan man imidlertid se, hvilke Egenskaber, der har været gældende på hvilke tidspunkter. Figur 5. Attributter 15
16 Markeringen <..> i elementet DokumentAttributListe i figur 6 angiver, at det er tilladt for en konkret anvendelse af informationsmodellen for Dokument at tilføje yderligere attributter. Det er dog et krav, at disse attributter skal have Virkning. Figur 7 angiver et eksempel på en konkret anvendelse, hvor der er tilføjet en ekstra attribut: EngelskOversættelse: Relationer Figur 6. Dokument med ekstra attribut Til ethvert objekt er knyttet et antal relationer. I informationsmodellen for Dokument anbringes disse relationer i et element kaldet DokumentRelationListe. Til en given DokumentRegistrering er knyttet netop en DokumentRelation- Liste. Markeringen <..> i elementet DokumentRelationListe i figur 8 angiver, at det er tilladt for en konkret anvendelse af informationsmodellen for Dokument at tilføje yderligere relationer. Det er dog et krav, at disse relationer skal være enten af typen Relation eller af typen FlerRelation. Figur 8 angiver et eksempel på en konkret anvendelse, hvor der er tilføjet en ekstra relation: Kommentarer: 16
17 Figur 7. Relationer Alle relationer nedarver enten fra det generelle element Relation, som repræsenterer en reference til et enkelt andet objekt af en bestemt type, eller fra det generelle element FlerRelation, som repræsenterer referencer til et antal objekter af en bestemt type. Figur 8 angiver modellen for Relation og FlerRelation. Bemærk, at såvel Relation som FlerRelation har Virkning. Selve referencen repræsenteres i modellen ved hjælp af et UUID. 17
18 2.2.4 Tilstande Til ethvert objekt er knyttet et antal tilstande. I informationsmodellen for Dokument anbringes disse attributter i et element kaldet DokumentTilstandListe. Til en given DokumentRegistrering hører netop en DokumentTilstandListe. For Dokument findes der netop en tilstand, nemlig tilstanden Fremdrift, som er af typen DokumentFremdrift. Selve typen DokumentFremdrift består af et to felter, nemlig feltet Status, som angiver tilstandens status samt feltet Virkning, som angiver at tilstanden har Virkning. Det er altså muligt ud fra den enkelte DokumentTilstandListe at se, hvad dokumentets Fremdrift har været på forskellige tidspunkter. Bemærk, at virkningen for Tilstande, TilstandVirkning, adskiller sig fra den generelle Virkning ved ikke at have et Til-felt. Dette skyldes, at der for tilstande i modsætning til attributter og relationer ikke kan være huller i registreringen. Et Dokument skal således altid have en Fremdrift. Feltet Til ville således være redundant og er derfor ikke medtaget i informationsmodellen. 18
19 Figur 8. Tilstande Markeringen <..> i elementet DokumentTilstandListe i figur 9 angiver, at det er tilladt for en konkret anvendelse af informationsmodellen for Dokument at tilføje yderligere tilstande. Det er dog et krav, at disse relationer skal have Status (som er en enumereret liste) og Virkning (af typen TilstandVirkning). 19
20 Figur 10 angiver et eksempel på en konkret anvendelse, hvor der er tilføjet en ekstra tilstand: Godkendelse: Figur 9. Dokument med ekstra tilstand. 20
21 2.2.5 Samlet virkning Figur 11 viser den samlede informationsmodel for Dokument. Som det fremgår af figuren er der udover de allerede beskrevne elementer tilføjet en ekstra Virkning på DokumentRelation. Denne Virkning angiver den samlede Virkning for dokumentet. Dokument har en række obligatoriske elementer: Egenskaber er et eksempel på et sådant obligatorisk element, Ejer er et andet. Selvom disse elementer er obligatoriske, kan der godt være huller i deres Virkning. Der kan imidlertid kun være et hul i et obligatorisk elements Virkning, hvis selve Dokumentet på det tidspunkt ikke havde Virkning. Dokumentets samlede Virkning angiver altså de perioder, hvor mindst ét af dokumentets elementer (herunder samtlige obligatoriske elementer) havde virkning. Figur 10. Den samlede informationsmodel for Dokument. 21
22 2.3 Temporale egenskaber Når det drejer sig om tidsmæssige ændringer, anvender vi begrebet temporale egenskaber. Begrebet kommer fra databaseverdenen, hvor det giver mulighed for at repræsentere registreringer, som ændrer sig over tid i en database. Vi anvender denne struktur for at få mulighed for at tilgå information, ikke kun på nuværende relationer, men også på tidligere og fremtidige registreringer Systemtid Begrebet systemtid bruges til at definere det tidspunkt, hvor servicens operation bliver kaldt (andre steder kaldet transaktionstid). Systemtiden repræsenteres af et tidsstempel: Timestamp = T23:59: Udover de almindelige tidsangivelser, er der også brug for at angive logisk minimum og maximum af systemtiden: minimum betegner det tidligste tidspunkt, som kan udtrykkes i systemtid. maximum betegner det seneste tidspunkt, som kan udtrykkes i systemtid. Intervallet ]minimum, maximum[ betyder derfor i praksis ALTID Registrering Ethvert objekt består af en række registreringer. En registrering svarer til den viden om objektet, som var til rådighed ved tidspunktet for et operationskald. Vi lader registreringen være immutabel, hvorved den altså ikke kan ændres. I stedet for bliver der dannet nye afledte registreringer ved nye operationskald. Det betyder, at vi betragter et objekt som en samling af nøgler og værdier, hvor Registrering er nøgle, og ObjektRegistreringer værdier. I datalogiske termer har vi at gøre med et Map. 22
23 D(ID1) : Map<Registrering, Document> = [R1->D(ID1, t1), R2-> D(ID1,t2),... Rn- >D(ID1,tn)] UML modellen for registrering: Registrering fra:timestamp livscyklus:livscyklusenum aktørref: UUID Forklaring af felterne: Fra Livscyklus Aktør Tidsstempel, automatisk tilføjet af servicen med tidspunktet for operationskaldet. En af enumerationens muligheder (Opstået, Importeret, Passiveret, Nedlagt). En reference til den ansvarlige aktør det kan være bruger, eller brugerens organisation. Værdien bliver automatisk tilføjet af servicen. Eksempel. For dokument, kan stereotypen realiseres vha. følgende XML-fragment: <Document xmlns="urn:oio:sagdok:1.0.0" > <ObjectId>112</ObjectId> <Registration> <lifecycle>opstået</lifecycle> <actorid>117</actorid> <from>-minimum</from> </Registration> </Document> 23
24 2.3.3 Virkning Virkning giver mulighed for at angive en række alternative versioner af samme element. Virkning fra: TimeStamp til:timestamp aktør: Aktør note:string Forklaring af felterne: Fra Til Aktør Note Starten af Virkningsintervallet. Slutningen af Virkningsintervallet. En reference til den ansvarlige aktør det kan være bruger, eller brugerens organisation. Værdien bliver automatisk tilføjet af servicen. Kan bruges som kommentar Forretningslogik Tidsintervallet skal være sammenhængende, fra skal være mindre end til Hvis intet tidsinterval er angivet, er default værdien ]minimum,maximum[ Tidsintervallet kan være et af følgende: [t_0, t_1] - lukket interval ]minimum,t_0], [t_0, maximum[ - halvåbent interval ]minimum,maximum[=altid åbent interval i praksis lig med altid Aktør er optionel. Hvis den ikke er angivet, er default værdien "Organization ID". Tidsintervaller for en virkning indenfor samme registrering kan godt være usammenhængende, dvs. vi tillader huller. Lukkede tidsintervaller for en virkning indenfor samme registrering kan ikke overlappe. Halvåbne og åbne intervaller må godt overlappe i input. Det bliver af servicen omsat til lukkede intervaller. 24
25 Eksempel: UPDATE( [t1, maximum]: titel-> hej ) R1 UPDATE( [t2, maximum]: titel-> hej2 )-> R2 R2 = [t1,t2]: titel-> hej, [t2,maximum]:titel-> hej Forklaring af stereotypen <<Virkning>> - med DokumentEgenskaber som eksempel Stereotypen <<virkning>> bliver brugt i UML diagrammer som en notations genvej. Dokument definerer en DokumentAttributModel, og den har annoteret relationen mellem DokumentAttributModel og DokumentEgenskaber (attribut) med stereotypen <<>>. Mønstret fortæller os, at selv om dokumentet på et givent tidspunkt har præcis ét element med DokumentEgenskaber, har vi i virkeligheden en Kollektion af DokumentEgenskaber. XML-fragmentet nedenunder viser, hvordan et dokument kan have to virkninger af samme Attribut DokumentEgenskaber. Den første har fra virkningsdato titlen Hej, hej verden!!!. Den anden har fra virkningsdato titlen Hejsa. <Document> <DocumentProperties> <Validity from=" T23:59: " to="maximum"/> <Title>Hej, hej verden!!! </Title> </DocumentProperties> <DocumentProperties> <Validity from=" T23:59: " to="maximum"/> <Title>Hejsa</Title> </DocumentProperties> </Attributes>... </Document> 25
26 2.3.4 Eksempel En klient kalder Dokument Service gentagne gange. 1. Opret dokument og registrer følgende virkninger for attributten titel : 1. Fra [t1,t2) er værdien title=hej 2. Ret dokument 1. Fra [t2,maximum) er værdien title=hello 3. Læs dokument (ingen tid angivet) 1. Det returnerede DokumentRegistrering bliver filtreret som default virkninger efter dags-dato, og det svarer til titlen Hej. En titel attribut bliver derfor returneret som en del af registreringen. 4. Læs dokument (fra=t1,maximum). 1. Det returnerede DokumentRegistrering bliver filtreret efter virkningsintervallet [t2,maximum) og returnerer 2 værdier for titel som en del af data: Hej, og Hello. 26
27 3 Service Operationer 3.3 Løsningsarkitektur Med definitionen af operationer bevæger vi os væk fra informationsmodeller og semantiske standarder ind på løsningsarkitektur. Det er ikke data det er services, som kan gøre noget ved data, der er det centrale. Dette afleder en række tekniske krav til: Infrastruktur Sikkerhed, SignOn, Rettighedsstyring Service Level Agreement for service anvender Life Cycle Management for service udbyder SOA Governance for økosystemets levetid De ovenstående tekniske krav behandles ikke i denne sammenhæng, men vil blive behandlet i den kommende vejledning om tekniske krav for dataservices, der bruger Sag og dokument standarder. 3.4 Input Hver operation på hvert enkelt serviceinterface defineres af sin egen model. Navngivningen følger reglen: ServiceOperationInput. For eksempel hedder Schema for Dokument Opret: DocumentCreateInput.xsd. I designet af API'et er der taget størst mulig hensyn til, at det skal være nemt at bygge klienter, som kan anvende service endepunkterne. Dette inkluderer at definere en forretningslogik, som tildeler default værdier for obligatoriske XML-elementer, så servicen kan være tilgivende overfor klienten. De fleste moderne systemer lader XML parsning foregå automatisk, i specielle klasser som er genereret ud fra Schemaet. Dette giver maksimal typesikkerhed, og udviklere behøver ikke arbejde med XML kode. Afledte skemaer kan bruge samme klasser. Skemaer med en ny struktur kræver, at der kompileres nye klasser. XSD Autogenererede parserklasser For at undgå unødvendig kompleks programmering bør de enkelte objekt specifikationer sørge for at input-strukturerne ligger i samme target namespace, og udvider samme typer som informationsmodellen. 27
28 3.5 Output Servicen returnerer altid metadata for den sidste ObjektRegistrering, som defineret i informationsmodellen. De returnerede data indeholder alle de ændringer, som er foretaget af servicen, og vil som regel være forskellig fra input data. Undtagelsen her er søg/list, som returnerer Kollektioner, der indeholder ObjektRegistreringer. Navngivningen følger navnet på forretningsobjektet for den pågældende service. For eksempel hedder Schema for Dokument: Document.xsd Fejlhåndtering Hvis kaldet er mislykket, returneres en fejlmeddelelse. Fejlmeddelelsen indeholder en fejlkode og en meddelelse Transportprotokol Man kan implementere servicen ved brug af: REST WS-* stak Asynkron messaging Den enkelte organisations krav til bl.a. sikkerhed er afgørende for valget. 3.6 Data Service API Vi betragter servicen som et datalag og eksponerer derfor kun dataoperationer. Der er tale om operationerne CRUD + søg, list og passivér/importer Opret Operationen Opret CREATE er ansvarlig for at skabe et Objekt og en ObjektRegistrering og returnere ObjektRegistreringen. CREATE(DocumentCreate.xml) -> D(UUID1,t1) Input Modellen for input til det enkelte serviceinterface skal som udgangspunkt være tilgivende, og tillade at bruge så lidt information som muligt for at oprette et objekt. Hvis der findes obligatoriske elementer, er det et designvalg, om forretningslogikken skal sørge for at definere default værdier for disse. 28
29 OpretInput virkning:virkning attributter [0..n]:Attribut relationer [0..n]:Relation tilstande [0..n]:Tilstand Elementforklaring: Element Obligatorisk Default værdi tildelt af systemet Virkning Nej ]minimum, maximum[ Attributter Defineret af forretningslogik Relationer Nej/Ja 5 Defineret af forretningslogik Tilstande Defineret af forretningslogik For eksempel kan et tomt Dokument Objekt oprettes ved at kalde Opret operationen i DokumentService med følgende XML-fragment: <oio:document xmlns:oio="urn:oio:sagdok:1.0.0" xmlns:xsi=" xsi:schemalocation="urn:oio:sagdok:1.0.0 DokumentCreateInput.xsd " /> Output Returværdien er en ObjektRegistrering, som indeholder den nye UUID, svarende til returværdien fra et kald til READ(UUID1) Forretningslogik Servicen opretter et nyt Objekt, og tildeler den en unik, global UUID. Livscyklus tilstanden sættes til OPSTÅET. Servicen skaber en ObjektRegistrering, og befolker datastrukturen, som angivet af input-strukturen. 5 Dette afhænger af det enkelte forretningsobjekt. Som udgangspunkt skal det være obligatorisk at have de elementer med, som er obligatoriske i informationsmodellen, men som ikke kan tildeles en fornuftig default værdi. 29
30 3.6.2 Læs Operationen Læs READ har ansvar for at returnere den sidste ObjektRegistrering Input Som input angives objektid samt et optionelt virkningsinterval. Parametre: Element Obligatorisk Default værdi tildelt af systemet objektid JA Fejl! virkningsinterval Nej NU Output Output er Objektstruktur som defineret af informationsmodellen, og det tilsvarende Schema. F.eks. returneres fra DokumentService et XML dokument, genereret på Document.xsd schema Forretningslogik Returnerer altid sidste ObjektRegistrering Alle objekter kan læses også de udstemplede. En angivelse af virkningsinterval filtreres igennem ObjektRegistreringen. Kaldet fejler, hvis objektid ikke findes Opdatér Operationen Opdater - UPDATE har ansvar for at skabe en ny ObjektRegistrering, og indføre de ændringer, som er angivet i input-strukturen. UPDATE(DocumentUpdate.xml) D(UUID1,t1) Input Som udgangspunkt ville vi gerne nøjes med kun at have ændringerne som input parameter. Det er dog lidt kompliceret med kollektioner, idet der skal kunne slettes et kollektionselement. 30
31 Element Obligatorisk Default værdi tildelt af systemet objektid JA Fejl! Attributter Tilstande Relationer NEJ NEJ NEJ Forhenværende registrerings data videreføres Forhenværende registrerings data videreføres Forhenværende registrerings data videreføres Output Den nye registrering, svarende til returværdien for READ Forretningslogik Når et objekt rettes, dannes en klon af de elementer, der ændres og der kan tilføjes elementer, der ikke fandtes i forvejen. Hvert af de oprindelige elementer, der bliver ændret, får registrerettil=ts(), mens de nye elementer får registreretfra=ts(). Det nye element får de nye værdier. Hvis man forsøger at rette i et udstemplet objekt eller et udstemplet element, vil det være som at oprette det på ny dvs. der dannes ingen klon. Hvis UUID mangler eller ikke kan matches af et eksisterende objekt, fejler kaldet. Hvis et element i en kollektion mangler, svarer det til sletning Slet Slet har ansvar for at skabe en ny registrering, med Livscyklus tilstanden sat til NEDLAGT. Et objektid. Delete(uuid1) D(UUID1,t1) Input 31
32 Output Den nye registrering bliver returneret, svarende til READ operationen Forretningslogik Et objekt med den angivne UUID skal være defineret, og må ikke have tilstanden NEDLAGT. Livscyklus variablen bliver ændret til NEDLAGT Import Import har ansvar for at skabe et nyt Objekt og en ny ObjektRegistrering i servicen, baseret på data hentet fra en anden service (den oprindelige service). IMPORT(DocumentImport.xml) D(UUID1,t1) Input Et komplet Objekt, som inkluderer objektid, svarende til returværdien fra READ i den oprindelige service Output Servicen returnerer den nye registrering, svarende til et kald for READ Forretningslogik Et nyt Objekt og en ny ObjektRegistering bliver skabt men servicen genererer ikke en ny UUID. UUID skal være sat i input-strukturen. Livscyklus bliver sat til Importeret. Når et importeret objekt læses, skal det fremgå af StdRetur, at registreringer før importeret ikke har fundet sted i denne service Passiv Passiv har ansvar for at markere, at servicen ikke er ansvarlig for at vedligeholde et objekt. Specielt behøver den ikke abonnere på hændelser. Passiv(UUID1) D(UUID1,t1) Input Et objektid Output Servicen returnerer den nye registrering, svarende til et kald for READ. 32
33 Forretningslogik Når et objekt passiveres, er det alene livscyklustilstanden passiv, der bliver sat med registreretfra = ts() Passiv betyder, at vedligeholdelse af objektet ikke finder sted i den pågældende service. Når et passiveret objekt læses, skal det fremgå af StdRetur at registreringer efter passiveret ikke finder sted i denne service List List bruges til at arbejde med tidsperspektivet, og kan derfor filtrere på Registreringsinterval og Virkningsinterval. LIST([UUID1,..UUIDn], ValidPeriod, RegistrationPeriod) [D(UUID1,t1), D(UUID1,t2)... D(UUID2,t3),... ] Input Liste af ObjektId - obligatorisk Virkningsperiode - optionel Registreringsperiode optionel Output En liste af objektregistreringer filtreret igennem virkning og registrering Forretningslogik List kan returnere forhenværende ObjektRegistreringer Søg Baseret på søgekriterie fx ligesom mig - returnerer SEARCH en liste af relevante ObjektRegistreringer. Det er muligt at angive et Registreringsinterval. Hvis dette udelades, foregår søgningen kun på de seneste registreringer. SEARCH(SearchInput.xml, ValidPeriod, RegistrationPeriod) [D(UUID1,t1), D(UUID1,t2)... D(UUID2,t3),... ] Input En tilgivende Dokument.xsd variant, som gør det muligt at udelade ting, eller have for mange med, fx en liste af objektid'er, eller en regular expression i stedet for titel. 33
34 Output En liste af registreringer som modsvarer søgekriterierne Forretningslogik Som minimum skal søgning kunne returnere objektregistreringer svarende til objektid. Forskellige søgningsstrategier er tilladte. Der bruges paginering for at begrænse returmængdens størrelse. 34
35 4. Hændelser > 4.1 Baggrund Referencearkitekturen for sags- og dokumentområdet definerer begreberne Hændelse, Specifik Hændelse og HændelsesFordeler, som skal binde den serviceorienterede arkitektur sammen. Med baggrund i Anbefaling for en generel hændelsesbesked version indeholder nærværende dokument et forslag til en specifik hændelsesbesked, som kan håndteres af den generelle hændelsesbesked. Standarden Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet 7 og vejledningen Vejledning om ikke-funktionelle krav 8, behandler infrastrukturen og de ikke-funktionelle krav. Det følgende er en semantisk gennemgang af hændelse. 4.2 Hvad er en hændelse? Der udstedes en hændelse for et objekt når dets data bliver ændret, det vil sige, når der bliver skabt en ny registrering. Sag og dokument definerer en Specifik Hændelse, som er en minimal notifikationsstruktur. Denne bliver indlejret i Extension Structure fra standarden for Generel Hændelse. Generel Hændelse er som en ydre konvolut, og Specifik Hændelse er som indholdet
36 Figur 11. Specifik Hændelse Operation API for Hændelser Da vi ikke vil stille krav om infrastruktur, opererer vi med en minimalistisk hændelsesmodel, og en push-notify arkitektur. Denne løsning kan både tilbydes i et avanceret enterprise miljø, men også i et miljø med masser af legacy - det er nok at have et URI Hændelsesfordeler Hændelsesfordeler, som har operationerne Opret og Afmeld. Ved Opret angives et søgekriterie, som repræsenterer de ressourcer, som man er interesseret i at modtage hændelser for. 36
37 Hændelsesfordeler Opret(AbonnementInputMeddelse): Abonnement Afmeld(abonnementsID:UUID): StandardRetur HændelsesModtager Dette er en call-back URI, altså et interface man skal have, for at kunne modtage en hændelse. HændelsesModtager Modtag(GenerelHændelse):StandardRetur 37
38 4 Referencer Notation [Fowler] [UML] [Etutorials] Reference Martin Fowler: Temporal Patterns ml Martin Fowler, UML distilled Etutorials.org 6.+Class+Diagrams+Advanced+Concepts/Parame terized+class/ 38
39
Sag og Dokument: Eksempel på brug af generelle egenskaber
Sag og Dokument: Eksempel på brug af generelle egenskaber Der er knyttet en række generelle egenskaber til de enkelte objekter som beskrevet i dokumentet Generelle egenskaber for serviceinterfaces på sags-
Læs mereUnderbilag 2O Beskedkuvert Version 2.0
Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...
Læs mereAnvendelse af dobbelthistorik i GD2
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:
Læs mereSag 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 mereVejledning i kravspecificering af Sag og Dokument standarder (Revideret udgave; januar 2011)
Notat Vejledning i kravspecificering af Sag og Dokument standarder (Revideret udgave; januar 2011) Denne version af vejledningen er identisk med første udgave fra august 2010 bortset fra redaktionelle
Læs mereKommentar fra KMS til Specifikation af Serviceinterface for Person
Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt
Læs mereDKAL Snitflader REST Register
DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4
Læs mereSTEDBEVIDST UDVIKLING. Jes Ryttersgaard Kort og Matrikeldtyrelsen
STEDBEVIDST UDVIKLING Jes Ryttersgaard Kort og Matrikeldtyrelsen - bevidst om at bruge stedet som indgang til digital forvaltning - bevidst om hvordan vi sikrer, at det giver mening at bruge stedet - bevidst
Læs mereCCS Formål Produktblad December 2015
CCS Formål Produktblad December 2015 Kolofon 2015-12-14
Læs mere1 Objekt informationsmodel - Byggeblok
1 Objekt informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Objekt Modellen beskriver og viser hvordan Forretningsobjekt "Objekt" kan forstås. Modellen er generisk, og kan derfor bruges
Læs mereOverordnet set vurderer Odense Kommune, at både det foreliggende udkast og det bagvedliggende arbejde er af høj kvalitet.
Høringssvar på Specifikation af Serviceinterface for Sag standard for Specifikation af Serviceinterface for Sag og har flg. bemærkninger. og det bagvedliggende arbejde er af høj kvalitet. MFD, MIB Der
Læs mereVideregående Programmering for Diplom-E Noter
Videregående Programmering for Diplom-E Noter 1. Uddelegering Ét af de væsentlige principper i objektorienteret programmering er, at enhver klasse selv skal kunne "klare ærterne". Enhver klasse skal altså
Læs mereSpecifikation 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 mereVersion Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.
MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.
Læs mereOIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen
> OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen Publikationen kan også hentes på IT- & Telestyrelsens Hjemmeside: http://www.itst.dk ISBN
Læs mere1 Tilstand informationsmodel - Byggeblok
1 Tilstand informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Tilstand : Overordnet model til at beskrive "tilstande". Modellen er generisk og kan bruges som skabelon på tværs af forretningsområder
Læs mereGenerelle egenskaber for serviceinterfaces på sags- og dokumentområdet. Denne standard er godkendt af OIO-komiteen december 2009
Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet Denne standard er godkendt af OIO-komiteen december 2009 Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet Denne
Læs mereTypografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem
Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem 1 Indholdsfortegnelse A3.1 INTRODUKTION 3 A3.1.1 HENVISNINGER 3 A3.1.2 LÆSEVEJLEDNING 4 A3.1.2.1 SÅDAN
Læs mereUdgivelsen 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 mereDKAL Snitflade Webservice
DKAL Snitflade Webservice Typografidefinition: Overskrift 1: Skrifttype: Indrykning: Venstre: 0 cm, Hængende: 0,76 cm, Sideskift før Typografidefinition: Overskrift 2;H2;h2;2;headi;hea ding2;h21;h22;21;heading
Læs mereAssignment #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 mereFESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø
FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har
Læs mereAbstrakte datatyper C#-version
Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Abstrakte datatyper C#-version Finn Nordbjerg 1/9 Abstrakte Datatyper Denne note introducerer kort begrebet abstrakt datatype
Læs mere0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.
Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012
Læs mereSpecifikation af serviceinterface for arkivstruktur. Denne standard er godkendt af OIO-komiteen december 2009
Specifikation af serviceinterface for arkivstruktur Denne standard er godkendt af OIO-komiteen december 2009 Specifikation af serviceinterface for arkivstruktur Denne standard kan frit anvendes af alle.
Læs mereUdgivelsen 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 mereSpecifikation af serviceinterface for dokument. Denne standard er godkendt af OIO-komiteen december 2009
Specifikation af serviceinterface for dokument Denne standard er godkendt af OIO-komiteen december 2009 > Specifikation af serviceinterface for dokument. Version 1.1.1 Denne standard kan frit anvendes
Læs mereSTS ORGANISATION. 26. februar 2019
STS ORGANISATION 26. februar 2019 Indhold Baggrund og ophæng til rammearkitekturen Hvordan fungerer Organisation? Anvisninger til anvendelse af Organisation Guide til udlæsning af Organisation Dokumentation
Læs mere3.0 Velkommen til manualen for kanalen Shift 1. 3.1 Introduktion til kanalen 1. 3.2.1 Hvad er et spot? 2. 3.2.2 Opret et nyt spot 2
3.0 Velkommen til manualen for kanalen Shift 1 3.1 Introduktion til kanalen 1 3.2 Shift kanalside 1 3.2.1 Hvad er et spot? 2 3.2.2 Opret et nyt spot 2 3.2.3 Aktivt og inaktivt spot 3 3.2.4 Rediger et spot
Læs mereHøringssvar vedrørende Specifikation af serviceinterface for person (part)
IT- og Telestyrelsen Holsteinsgade 63 2100 København Ø Høringssvar vedrørende Specifikation af serviceinterface for person (part) Dette er KLs høringssvar på den offentlige høring om specifikation af serviceinterface
Læs mereSpecifikation af serviceinterface for organisation. Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13.
Specifikation af serviceinterface for organisation Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13. november 2009 Specifikation af forretningsservice for Organisation Denne
Læs mereHøringsnotat - specifikation af serviceinterface for SAG version 1 2
N OTAT Høringsnotat - specifikation af serviceinterface for SAG version 1 2 Specifikation af serviceinterface for SAG Version 1.2 (Sag-standard) Den fællesoffentlige styregruppe for Sag og Dokument sendte
Læs mereJAR Øvelse nr. 2. JAR-Manual, Version 1.0. Avanceret søgning. Regionsvejledning
JAR Øvelse nr. 2 Avanceret søgning Regionsvejledning JAR-Manual, Version 1.0 Øvelse ID: 2 Øvelsesemne: Avanceret søgning Øvelsesbeskrivelse: Gør dig i stand til at bygge avancerede søgninger op. Formål:
Læs mereIDAP manual Analog modul
IDAP manual Analog modul Dato: 15-06-2005 11:01:06 Indledning Til at arbejde med opsamlede og lagrede analoge data i IDAP portalen, findes en række funktions områder som brugeren kan anvende. Disse områder
Læs mereBIM Shark brugervejledning v1 Februar 2016
Indholdsfortegnelse 1 BIM Shark's mission... 2 2 Kom godt i gang... 2 2.1 Oprettelse af bruger... 2 2.2 Oprettelse af virksomhed... 3 2.3 Inviter medlemmer/accepter invitation/sende invitationer... 3 2.3.1
Læs mereSpecifikation af serviceinterface for dokument. Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13.
Specifikation af serviceinterface for dokument Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13. november 2009 Specifikation af serviceinterface for dokument Denne standard
Læs mere<navn på proces eller use case>
-- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der
Læs mereNotat om metadata om grunddata
Bilag 16 - Fælles arkitekturramme for GD1-GD2-GD7 Notat om metadata om grunddata 6. december 2013 SAR & PLACE Indledning Metadata data om data betegner ikke en entydig klasse af data. Anvendelsen af betegnelsen
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
22.3.27 SortimentStruktur. DataStructure: SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
8..27 SortimentOverfør Kort beskrivelse: Denne service distribuerer ØiR Sortimenter til It-systeminstanser, der abonner på sortimentet på vegne af en myndighed. Servicen udstilles som integrationen SF_72
Læs mereAxapoint Reviewkommentar til MOX-specifikation Version 0.76 - udarbejdet af It-arkitekturrådets arbejdsgruppe
Axapoint ApS Brunhøjvej 8, st. tv DK-8680 Ry Tel. +45 23 10 83 44 CVR nr. 32 15 37 98 info@axapoint.com www.axapoint.com Bank: Danske Bank. www.axapoint.com MOX-review Axapoint Reviewkommentar til MOX-specifikation
Læs mereFællesoffentlig beskedmodel version 1.0
Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles
Læs mere1 Brug af snitfladebeskrivelsen... 2. 2 Formål og beskrivelse... 2. 2.1 Hvad er formålet med snitfladen?... 2. 2.2 Beskrivelse af snitfladen...
AUB - Indberet skoleophold(al8) Indholdsfortegnelse Indholdsfortegnelse 1 Brug snitfladebeskrivelsen... 2 2 Formål og beskrivelse... 2 2.1 Hvad er formålet med snitfladen?... 2 2.2 Beskrivelse snitfladen...
Læs mereUdgivelsen er beskyttet af Creative Commons license, Navngivning 2.5
OIOUBL Guideline OIOUBL Adresser UBL 2.0 Address G36 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Adresser Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen
Læs mereGrunddatabeskedmodel version 1.0
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,
Læs mereBBR 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 mereSpecifikation af serviceinterface for klassifikation. Denne standard er godkendt af OIO-komiteen december 2009
Specifikation af serviceinterface for klassifikation Denne standard er godkendt af OIO-komiteen december 2009 > Specifikation af serviceinterface for klassifikation Udgivet af: IT- & Telestyrelsen Denne
Læs mereSTØTTESYSTEMET KLASSIFIKATION
STØTTESYSTEMET KLASSIFIKATION v/ Martin Bo Jensen 26. februar 2019 KOMBITs løsninger og fælleskommunal infrastruktur 2 Kommunale fagområder Arbejdsmarked og erhverv Social og sundhed Børn og læring Mit
Læs mereUdgivelsen er beskyttet af Creative Commons license, Navngivning 2.5
OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen
Læs mereObjektorientering. Programkvalitet
1 PROSA-Bladet nr. 4 1993 Objektorientering = Programkvalitet? Af Finn Nordbjerg, adjunkt ved Datamatikeruddannelsen, Aalborg Handelskole 1. Indledning Objektorientering er blevet et edb-fagets mest udbredte
Læs mereUML til kravspecificering
UML til kravspecificering UML mini-kompendium - til brug i forbindelse med modellering af kravspecifikationer. Copyright 2006 Teknologisk Institut, IT-Udvikling Aktivitetsdiagram 2/9 Aktion Aktionsnavn
Læs mereNotat. Introdansk beskrivelse af fastlagte krav til indberetning af statistikoplysninger fra udbydere 27.06.2012 JL
Notat Vedrørende: Skrevet af: Introdansk beskrivelse af fastlagte krav til indberetning af statistikoplysninger fra udbydere Jesper Lund Version: 1.4: rev. af Ankestyrelsen, januar 2014 27.06.2012 JL I
Læs mereTilbudsportalen REST testklient
Socialstyrelsen Tilbudsportalen REST testklient REST testklienter.net Søren Korgaard Nielsen, Socialstyrelsen 28-01-2014 Indhold 1 Indledning... 3 2 XSD og autogenereret kode... 4 3 Opbygning af blanketter...
Læs mereIntroduktion. Jan Brown Maj, 2010
Jan Brown Maj, 2010 Introduktion OIOXML har eksisteret som det centrale datastandardiseringsparadigme siden 2002. Til OIOXML-konceptet er der et regelsæt betegnet OIO Navngivnings- og Deignregler (NDR),
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
8.2.27 SortimentStruktur. SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis i en given
Læs mereEksamensadministration, EUD, udtrækning af elever Sidst opdateret 16-03-2010/version 1.3 /UNI C/Steen Eske Christensen
Eksamensadministration, EUD, udtrækning af elever Sidst opdateret 16-03-2010/version 1.3 /UNI C/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange mv. Vejledningen består
Læs mereBILAG A KØBENHAVNS UNIVERSITET IKT-TEKNISK KOMMUNIKATIONSSPECIFIKATION
KØBENHAVNS UNIVERSITET BILAG A IKT-TEKNISK KOMMUNIKATIONSSPECIFIKATION PROJEKT ID: KU_xxx_xx_xx_xxxx (se bilag G, pkt. 0.0) PROJEKTNAVN: xxx DATO: xx.xx.xxxx VERSION: 1.1 VERSIONSDATO: 28.03.2014 02 BILAG
Læs mereKlasser og Objekter i Python. Uge 46 Learning Python: kap 15-16, 19-22.
Klasser og Objekter i Python Uge 46 Learning Python: kap 15-16, 19-22. Klasser og objekter En klasse beskriver en klump af samhørende funktioner og variable En klasse er en beskrivelse. En kage form Klassens
Læs mere1 Begrebsmodel for Ydelsesindeks
1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående
Læs mereST Sortiment Informationsmodel
.5.27 ST Sortiment Informationsmodel .5.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
2.9.27 SortimentStruktur. SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis i en given
Læs mereVilkår for brug af Støttesystemet Sags- og Dokumentindeks
Version 1.0 Vilkår for brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og
Læs mereKontroller af tekniske regler ved indsendelse af digitale årsrapporter
Oversigt over: Kontroller af tekniske regler ved indsendelse af digitale årsrapporter Erhvervsstyrelsen, december 04 Version.3 Erhvervsstyrelsen, december 04, Version.3 Side Forord Siden maj 009 har Erhvervsstyrelsen
Læs mere2.15 21/05/2013 Tilføjet dokumentation af bvn input for GetEngagementDetailed
APOS2 REST API Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.
Læs mereSpecifikation af serviceinterface for organisation. Denne standard er godkendt af OIO-komiteen december 2009
Specifikation af serviceinterface for organisation Denne standard er godkendt af OIO-komiteen december 2009 Specifikation af serviceinterface for Organisation Denne standard kan frit anvendes af alle.
Læs mereKontroller af forretningsregler ved indsendelse af digitale årsrapporter
Oversigt over: Kontroller af forretningsregler ved indsendelse af digitale årsrapporter Erhvervsstyrelsen, september 201 Version 1.2 Erhvervsstyrelsen, september 201, Version 1.2 Side 1 Forord Dette dokument
Læs mereAnvisning i aflevering af bitemporale data
UDKAST udgivet juni 2019 Anvisning i aflevering af bitemporale data Baggrund Aflevering af data fra it-systemer til et offentligt arkiv er baseret på aflevering af en arkiveringsversion i en relationel
Læs mereITD 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 mereVejledning til Privat-konferencer
Vejledning til Privat-konferencer 6. udgave, oktober 2008 Tilpasset FirstClass version 9.106, dansk 2 1 Om Privat-konferencer... 4 2 Oprettelse af hovedkonference... 5 2.1 Fremgangsmåde... 5 2.2 Standardopsætning
Læs mereHVORDAN KAN REFERENCEARKITEKTUR IMPLEMENTERES I EN STANDARDISERET DOKUMENTATION?
HVORDAN KAN REFERENCEARKITEKTUR IMPLEMENTERES I EN STANDARDISERET DOKUMENTATION? Strukturering af dokumentation er et must, hvis der skal være genkendelighed og ensartethed i dokumentationen. Det samme
Læs mereIndeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76
MOX bilag Indeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76 Rapporten og bilaget udgør et foreløbigt udkast til rapportering
Læs mereSide 1 af 16. Vedligehold decentrale stamdata i SKS
Side 1 af 16 Vedligehold decentrale stamdata i SKS Indholdsfortegnelse Side 2 af 16 1. Indledning... 3 2. Generelt om stamdata i SKS og vedligeholdelse af disse... 3 2.1. CENTRALE STAMDATA... 4 2.2. DECENTRALE
Læs mereUnderbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 2.0
Underbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 20 Begrebsmodellen for Ydelsesindeks Begrebsmodellen med de centrale forretningsobjekter er illustreret i Figur Begrebsmodel og definition
Læs mereVersionsbrev LUDUS Web version 2.10.0. LUDUS Web 2.10.0. Den 2. oktober 2009. J. nr: 4004-V1288-09
Versionsbrev LUDUS Web version 2.10.0 J. nr: 4004-V1288-09 Journal nr.. 4004-V1288-09 LUDUS Web version 2.10.0 Side 1 af 12 1. Leverancens omfang... 3 2. Fremgangsmåde... 4 2.1 Opdatering... 4 2.2 Nyinstallation...
Læs mereKlik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks
23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk
Læs mereCCS 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 mereBruger (kursist/deltager) Kom godt i gang med plan2learn. Version 0.01 Versionslog: 0.01
Bruger (kursist/deltager) Kom godt i gang med plan2learn Version 0.01 Versionslog: 0.01 1 Oprettet: 01.08.2014 Indhold 1. Formål med vejledningen...3 2. Katalogforsiden...4 2.1 Brugeradgang...5 2.2 Skift
Læs mereMiniprojekt i Programmering (MIP) for DAT2 og SW2, Forår 2012
Miniprojekt i Programmering (MIP) for DAT2 og SW2, Forår 2012 Opgaven er delt op i 2 dele. Læs hele opgaven igennem inden I begynder. 1. Struktur I denne opgave skal der laves et system der håndterer salg
Læs mereKlik her for at angive tekst.
30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav
Læs mereIndholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase
Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...
Læs mereKlik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks
30. april 2013 NOTAT Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks Indhold: 1. Indledning og vejledning... 3 2. Krav vedr. Systemets anvendelse af Støttesystemet
Læs mere1 Klassifikation-version2.0
1 Klassifikation-version2.0 Formål med Klassifikationsmodellen Her specificeres Klassifikationsmodellen, som en informationsmodel for Klassifikationer. Klassifikationer (eller klassifikationssystemer)
Læs mere1. Services, egne (udgående)
1. Services, egne (udgående) Navn: navn på egen service, eksempelvis: BrugsenhedAjourfoer Formålet med servicen beskrives kort, eksempelvis: Formålet med servicen er at oprette en den Brugsenhed som beskriver
Læs mereHoldingsItem (beholdningsdata) i Brønd 3.5
1 HoldingsItem (beholdningsdata) i Brønd 3.5 Formålet med at inkludere beholdningsdata i brønden, er at kunne afgrænse søgeresultater i forhold til tilgængelighed af materiale. Fx søgning på materialer,
Læs mereVejledning til SLS webservice Løbende løndele
Side 1 af 12 Vejledning til SLS webservice Løbende løndele Indholdsfortegnelse Ændringslog... 1 Formålet med webservicen... 2 Forretningsmæssig beskrivelse... 2 Wsdl-dokumenter... 2 OIOXML-skemaer... 3
Læs mereGenerelt Internationalisering
Bekendtgørelse om krav til anvendelse af Informations- og Side 1 af 7 Generelt Digital Konvergens samarbejdet, har i sit hidtidige arbejde fokuseret på at implementere vindende, digitale standarder, der
Læs mereSitecore - basisvejledning Version 2. September 2010
Sitecore - basisvejledning Version. September 00 Sådan opretter du en ny artikelside... Sådan omdøber du et artikelnavn så du får vist æ,ø og å... Sådan udgiver (publiserer) du nyt eller redigeret indhold...4
Læs mereSpecifikation af serviceinterface for Sag version 1.2
Høringssvar fra KMD vedrørende Specifikation af serviceinterface for Sag version 1.2 KMD takker for muligheden for at kommentere på specifikationen. Det er KMDs vurdering, at der generelt er tale om fornuftige
Læs mereVejledning 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 mereNetprøver.dk. Brugervejledning til Eksamensansvarlige
Netprøver.dk Brugervejledning til Eksamensansvarlige 11. marts 2016 Indhold 1 Introduktion... 3 2 Forberedelser før prøvedagen... 4 2.1 Sådan logger du på www.netprøver.dk... 4 2.2 Sådan godkender du indlæsninger
Læs mereDigital 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 mereNyt i SkoleIntra 5.11
Nyt i SkoleIntra 5.11 Sidst ændret den 26 02 2016 Ændringer i bookingsystemet Af hensyn til arbejdet med at udforme en ny og mere centralt placeret kalender i Det Nye Skoleintra, har vi lavet nogle ændringer
Læs mereDigital Kommuneplan. Kravsspecifikation gennem brugerinvolvering
Digital Kommuneplan Kravsspecifikation gennem brugerinvolvering Indhold Introduktion Afklaring af behov: Hvad skal digitale kommuneplaner kunne? Udarbejdelse og test af løsning: Hvordan skal digitale kommuneplaner
Læs mere1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær.
EfterUddannelse.dk FraværService - systemdokumentation BRUGERDOKUMENTATION: WEB-SERVICE Af: Logica Indhold 1. Indledning... 1 1.1 Formål... 1 1.2 Webservice version... 1 1.3 Historik... 1 2. Absence Webservice...
Læs mereHø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 mereDen Gode VANSEnvelope. MedCom
Den Gode VANSEnvelope MedCom Den Gode VANSEnvelope Jacob Glasdam Bolette Friis Jensen KMD Erik Jacobsen Multimed Ole Vilstrup CSC Thomas Jørgensen Evenex Dorthe Skou Lassen MedCom Gitte Fleckner Henriksen
Læs mereUNI Login. UNI Login webservice. ws-04
UNI Login UNI Login webservice ws-04 UNI Login UNI Login webservice 1.4 Indhold 1 UNI Login webservice... 1 1.1 Informationsmodel... 1 1.2 Entiteter og attributter... 2 1.2.1 Person... 2 1.2.2 Funktion...
Læs mereSortiment Informationsmodel
2.9.27 Sortiment Informationsmodel 2.9.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereUniq.Survey-Xact.DK. Vejledning. Rambøll Management Olof Palmes Allé 20 DK-8200 Århus N Denmark. Tlf: 8944 7800 www.ramboll-management.
Uniq.Survey-Xact.DK Vejledning Rambøll Management Olof Palmes Allé 20 DK-8200 Århus N Denmark Tlf: 8944 7800 www.ramboll-management.dk TU1.UT TUIndledningUT TU2.UT TUKlargøring TU3.UT TUOprettelse TU4.UT
Læs mereUdbud.dk Brugervejledning til leverandører
Udbud.dk Brugervejledning til leverandører Vejledning til at anvende Udbud.dk Januar 2014 Indholdsfortegnelse 1. INDLEDNING... 3 2. OVERORDNET OPBYGNING AF UDBUD.DK... 4 2.1 FORSIDE OG NAVIGATION... 4
Læs mere