Rapport om snitflader til publiceringsagent i Gentofte Kommune

Rapport om snitflader til publiceringsagent i Gentofte Kommune Connecting Business & Technology

Devoteam Fischer & Lorenz A/S 2004 Dette dokument er udarbejdet for af Devoteam Fischer & Lorenz A/S. har ret til at kopiere og distribuere dette dokument. Enhver anden kopiering og distribution må kun finde sted efter aftale parterne imellem. Enhver kopi skal være forsynet med rapportens titel, dato og denne notits.

Indholdsfortegnelse 1. Indledning...2 2. Publicerings konceptet...3 2.1. Version 1... 3 2.2. Version 2... 5 2.3. Version 3... 7 3. Standarder...8 3.1. OIO... 8 3.2. ebxml Core Component Specification... 8 3.3. Dublin Core... 9 3.4. DokForms Metadata-kerne... 9 3.5. RSS 2.0... 9 4. Vejledning til implementering...10 5. Snitflader...11 5.1. PublicationCollection... 11 5.2. TargetDocumentIdentifier... 13 5.3. PublicationSubscription... 14 5.4. PublicationNodeDetails... 14 5.5. PublicationNodeDetailsResponse... 15 5.6. UserIdentifier... 15 5.7. RequestChildNodeDetails... 16 5.8. RequestTargetDocumentIdentifierDetails... 16 5.9. PublicationFault... 16 5.10. NavigatePublicationTarget... 17 Bilag 1. Eksempel...18 v 1/21

1. Indledning Gentofte Kommune står overfor at skulle skifte Intranettets CMS-system til en SiteCore-baseret løsning. I den forbindelse skal der udvikles en ny publiceringsagent, der tager sig af publiceringen af dokumenter fra kommunens ScanJour ESDH-system til Intranettet. Publiceringsagenten skal på sigt kunne udbygges til at håndtere flere kilde- og publiceringssystemer. Devoteam Fischer & Lorenz har til opgave at udarbejde snitflader til den nye løsning, samt beskrive den løsning, de skal indgå i, på et konceptuelt niveau. Denne rapport samt bilag udgør leverancen fra Devoteam Fischer & Lorenz. Gentofte Kommune ønsker at basere løsningen på standardiserede snitflader, der lever op til OIO-reglerne for XML og WSDL. For det første for at undgå at skulle ændre snitfladerne på et senere tidspunkt. For det andet for at kunne stille dem til rådighed for andre organisationer, der ønsker denne form for publicering på tværs af systemer. Denne rapport beskriver dels konceptet omkring publiceringsagenten, dels de snitflader løsningen skal baseres på. Konceptet er beskrevet i en version 1, 2 og 3. Snitfladebeskrivelserne omfatter de standarder, der anvendes og de udviklede XML-skemaer og WSDL. v 2/21

2. Publicerings konceptet I dette afsnit præsenteres konceptet for den løsning, der ønskes i Gentofte Kommune og visionerne for fremtidige versioner, som grænsefladerne er klargjort til. Konceptet er beskrevet i tre versioner. I version 1 har ESDH-systemet kontrollen med publiceringen. Den styrer brugerdialogen, der knytter metadata til dokumentet og tillader brugeren at navigere efter den ønskede lokation i modtagersystemet. I version 2 overgår kontrollen til publiceringsagenten, der håndterer dialogen og knytter modtagerid til dokumentet. I version to åbnes således mulighed for, at flere afsendersystemer og flere modtagersystemer tilknyttes løsningen. I version 3 tilbydes de samme funktionaliteter som i version 2. Desuden åbnes muligheden for at tilknytte dokumenter en kategori, som modtagersystemer kan abonnere på. 2.1. Version 1 Version 1 ligner i høj grad den publiceringsagent, Gentofte Kommune har i dag. Målet er en løsning, der ikke kræver store ændringer i forhold til den nuværende, men som har standardiserede og fremtidssikrede snitflader. Fordelene ved denne løsning er, at det kræver minimale ændringer i ESDH-systemet og stiller meget få krav til CMS-systemet. En ulempe kan være, at der kun er mulighed for en-til-en publicering. Det opfylder dog Gentofte Kommunes nuværende behov. Publication NodeDetails -NodeIdentifier -NodeName - ScanJour ESDH SiteCore CMS Publicerings dialog Publicerings agent PublicationC ollection -Link to doc -Metadata Publication Subscription -TargetDocId -Ref:Publication Figur 1: Publiceringsagent version 1 v 3/21

Figur 1 viser konceptet for version 1. Her er det ESDH-systemet, der på samme måde som i dag har kontrollen over publiceringssituationen. Systemet håndterer publiceringsdialogen, hvor brugeren af systemet kan navigere i CMS-systemet og vælge placering af dokumentet vha. en web service, som CMS-systemet stiller til rådighed. Den returnerer PublicationNodeDetails. Desuden generer ESDH-systemet en XML-fil. XML-filen validerer imod XMLskemaet PublicationSubscription, som indeholder et link til den valgte destination i TargetDocumentIdentifier og en reference til et andet XML-skema PublicationCollection. PublicationCollection indeholder et link til det dokument, der skal publiceres samt metadata knyttet til dokumentet. Brugeren indtaster metadata i publiceringsdialogen, og de gemmes i XML-filen. I denne version anvender ESDH publiceringsdialog en filserver til at aflevere XML-filerne. Efter aflevering af XML-filer for publicering, er ESDH systemets del af opgaven afsluttet. Fra ESDH systemet afleveringspunkt flyttes dokumentet til CMS systemets afhentningpunkt. CMS-systemet afhenter nye dokumenter til publicering fra filserveren (CMS afhentningspunktet), hvorefter de slettes af CMS publiceringsagenten. Publication indeholder informationer om det dokument, der skal publiceres, mens PublicationSubscription indeholder informationer om modtagersystemet. Årsagen til at opsplitte skemaet i to er at informationer om modtagersystemet og om aftagersystemet (kanaler/medier) ønskes adskilt fra indhold (dokument/metadata). Dette med henblik på, på et senere tidspunkt, at udskillelse publicerings funktionaliteten fra ESDH-systemet og mulighed for at koble flere modtagersystemer og afsendersystemer på løsningen. Denne vision er beskrevet i version 2 og 3 i det nedenstående. v 4/21

2.2. Version 2 I version 2 overgår en del af kontrollen med publiceringssituationen fra afsendersystemet til publiceringsagenten. Publiceringsagenten kontrollerer publiceringsdialogen og kobler dokumentet og dets metadata til destinationen i modtagersystemet. Målet er en løsning med mulighed for flere afsendersystemer og flere modtagersystemer, men stadig kontrol med det dokument, der skal publiceres. Desuden har den den fordel, at den giver mulighed for en-til-mange publicering. Publishers Subscribers P1 Publiceringsdialog S1 Publication NodeDetails -NodeIdentifier P2 Publiceringsagent -NodeName - S2 P3 Publication Collection -Link to doc -Metadata Publication Subscription -TargetDocId -Ref:Publication S3 Figur 2: Publiceringsagent version 2 Figur 2 illustrerer konceptet for anden version af publiseringsagenten. I denne løsning er det publiceringsagenten, der håndterer publiceringsdialogen og håndterer forbindelsen mellem afsender- og modtagersystemet. Hermed kan løsningen omfatte mange forskellige afsendersystemer og mange forskellige modtagersystemet. I version 2 har man mulighed for at publicere ét dokument til flere forskellige modtagersystemer. Afsendersystemet anvender publiceringsagentens dialog, og brugere oplever således stadig, at der skal vælges destination(er) samt metadata for dokumentet. I version 2 er det dog publiceringsagenten, der styrer dialogen med modtagersystemerne via kald til den web service, de stiller til rådighed. Afsendersystemet skaber et XML-dokument, der validerer mod med reference til det dokument, der ønskes publiceret samt tilknyttede metadata. v 5/21

Publiceringsagenten har som nævnt kontrollen over publiceringsdialogen. Desuden holder agenten styr på afsendersystemer og modtagersystemer. Publiceringsagenten skaber et XML-skema, der validerer mod PublicationCollection, på baggrund af de metadata brugeren indtaster og et link til det dokument, der skal publiceres. Agenten modtager linket fra afsendersystemet, som indikeret med den stiplede streg i figur 2. Desuden skaber publiceringsagenten et XML-skema, der validerer mod PublicationSubscription og kobler TargetDocumentIdentifier til SubscriptionCollection. v 6/21

2.3. Version 3 I version 3 er publiceringsagenten udviklet efter et klassisk publish-subscribe mønster, hvor afsendersystemet ikke kender modtagersystemet og omvendt. Her fungerer publiceringen ved at abonnenter henter opdateringer i en kategori hos publiceringsagenten via RSS feeds. Denne løsning giver mulighed for at publicere dokumenter til mange modtagere via kanaler. Publishers Subscribers P1 Publiceringsdialog Publication NodeDetails - NodeIdentifier - NodeName - S1 P2 Publiceringsagent S2 Subcription - getupdates P3 Publication Collection - Link to doc - Metadata RSS Category - CategoryId - Ref:Publication S3 Figur 3: Publiceringsagent version 3 Figur 3 illustrerer version 3 af publiceringsagenten. Udover den samme funktionalitet som i version 2, hvor publiseringsagenten stiller en publiceringsdialog til rådighed for afsendersystemet er der i version 3 også mulighed for at vælge at publicere et eller flere dokumenter til en kategori. Modtagersystemerne kan abonnere på forskellige kategorier, og forespørger på opdateringer i kategorien. Som i version 2 er det publiceringsagenten, der styrer publiceringsdialogen mellem afsendersystemet og modtagersystemerne. Publiceringsagenten skaber et XML-dokument, der validerer mod PublicationCollection med reference til det dokument, der ønskes publiceret samt tilknyttede metadata. Desuden knytter publiceringsagenten dokumentet til en RSS kategori. Modtagersystemerne kan via web servicen Subscription hente opdateringer i forskellige kategorier. v 7/21

3. Standarder Publiceringsagentens databeskrivelser og servicebeskrivelser skal i så høj grad som muligt baseres på allerede eksisterende standarder. De standarder, der har været overvejet i udvekslingen er OIO, ebxml, Dublin Core, DokForm-gruppens metadata-kerne til udveksling mellem ESDH-systemer og RSS 2.0. Her gælder det, at internationalt godkendte standarder skal genbruges før nationale, og at kernekomponenter skal genbruges før domænekomponenter. I det følgende beskrives standarderne, og de overvejelser, der er blevet gjort omkring dem i projektets forløb. Det er Devoteam Fischer & Lorenz vurdering, at skemaerne kan godkendes som Domæneklasse -elementer, idet de overholder NDR3-regelsættet. De er syntaktisk og semantisk korrekte, genbruger relevante elementer fra Dublin Core, DokFormgruppen, ebxml og Kerneklassen, de lever op til navngivningen og dokumentation. Der tages dog det forbehold, at FESD eller FESD-leverandørerne har påbegyndt arbejdet med udvikling af publiceringssnitflader. 3.1. OIO OIO har en række regler for udvikling af XML skemaer. Disse regler er formuleret i NDR 3.0, som vil blive overholdt i udviklingen af XML skemaer til publiceringsagenten. Udover regler omkring modellering er der nogle faste krav om genbrug i OIO. I udviklingen af XML skemaer, er der derfor blevet søgt genbrugelige elementer i Infostrukturbasen med henblik på at undgå at definere allerede eksisterende dataelementer. OIOXML skemaer skal desuden registreres i Infostrukturbasen og igennem en høringsproces. OIO stiller ligeledes en række krav til udvikling af WSDL. Det er bl.a., at WSDL bør udvikles i hånden, inden implementeringen (kontrakt først), at de XMLskemaer, WSDL en baserer sig på, skal være OIOXML, at WSDL en skal overholde retningslinier fra WS-I Basic Profile 1.1. og at WSDL en skal registreres i Infostrukturbasen. 3.2. ebxml Core Component Specification EbXML Core Components specificerer en række kernekomponent-typer som beløb, tid, dato osv. Core Component Types er adopteret i OIOXML som kerneelementer og skal derfor genbruges i andre OIOXML-skemaer. v 8/21

3.3. Dublin Core Dublin Core metadata initiativet er en organisation, der udvikler og forsøger at udbrede anvendelsen af interoperable metadata standarder. Dublin Core har defineret en lang række metadataelementer, som blandt andet titel, afsender, ejer, dato osv. Dublin Core elementerne er adopteret i OIOXML som kerneelementer og er derfor obligatoriske at genbruge, når man ønsker at udvikle OIOXMLskemaer. 3.4. DokForms Metadata-kerne DokForm-gruppen i regi af Digital Forvaltning har udviklet en række elementer til udveksling af metadata mellem ERM-systemer. Elementerne er f.eks. afsendelsesdato, modtager, ejer og oplysninger om rettigheder. Elementerne er godkendt som kerneelementer i Infostrukturbasen og skal derfor genbruges i andre OIOXML-skemaer. 3.5. RSS 2.0 RSS er et syndikeringsformat til webindhold, og i øvrigt en XML-dialekt. RSS anvendes af mange CMS-systemer og blogs til syndikering. RSS 2.0 er et simpelt og standardiseret format til at kategorisere indhold og sende automatiske feeds af indholdet på websider. RSS 2.0 er et udbredt og åbent format og bør derfor anvendes i en version 3 af publiceringsagenten, hvor man ønsker automatisk syndikering af indhold til abonnenter. v 9/21

4. Vejledning til implementering I dette afsnit nævnes kort en række anbefalinger til implementeringen af publiceringsagenten. For det første anbefales, at så mange metadata om det publicerede dokument i PublicationCollection som muligt autogenereres. Dvs., at hvis data allerede findes i ESDH-systemet bør de lægges direkte i PublicationCollection og ikke være op til brugeren at udfylde. De resterende metadata, der ikke findes i ESDH-systemet indtastes af brugeren i publiceringsdialogen. Det anbefales, af implementeringen foregår efter anbefalinger i It- og Telestyrelsens OWSA model T: http://www.oio.dk/files/owsa_model_t_1.0_pdf.pdf. Her findes en lang række anbefalinger for sikkerhed, transport og fejlhåndtering ved udvikling af web services. I WSDL en NavigatePublicationTarget er der implementeret fejlhåndtering vha. SOAP:Fault. Dette skal ligeledes implementeres i løsningen. v 10/21

5. Snitflader I dette afsnit beskrives de snitflader, der er udviklet til løsningen. Det er XMLskemaerne PublicationCollection, PublicationSubscription, PublicationNodeDetails, PublicationNodeDetailsResponse, PublicationNodeCollectionResponse samt servicebeskrivelsen NavigatePublicationTarget. 5.1. PublicationCollection PublicationCollection beskriver det dokument, der skal publiceres. PublicationCollection indeholder en reference til dokumentet eller selve dokumentet, samt metadata knyttet til dokumentet. Metadata er f.eks. emneord, dokumentejer, publiceringsdato og url til dokumentets placering i afsendersystemet. I de nedenstående skemaer beskrives de enkelte elementer, der indgår i skemaet. Skemanavn Top element navn GK_PublicationCollection PublicationCollection Indholdsmodel for PublicationCollection Elementnavn (forekomster) Beskrivelse PublicationBody (1) Body udgøres af en reference til et dokument i ethvert format eller en del af det nærværende dokument baseret på XHTML eller et andet skema i det nærværende namespace. Title (1) Subject (1) PublicationDate (1) PublicationExpiryDate (0-1) PublicationNotificationIndicator (1) PublicationBody anvendes til at sende filen/link til filen, man ønsker publiceret. Brevets titel. Elementet har en direkte reference til elementet title i dc_elements.xsd (Dublin core). Elementet kan indeholder de emneord som er relevante for publikationen. Elementet har en direkte reference til elementet subject i dc_elements.xsd (Dublin core). Dato for publicering af dokumentet, angives i datetype fra UBL core component types. Dato for udløb af publisering, kan evt. anvendes til automatisk fjernelse af dokumentet ved udløb. Indikator for hvorvidt opdatering i kildedokumentet skal medføre notificering af abonnenter på publiceringen. Indikatoren kan sættes til "true", hvorved der sker en notificering eller "false", hvorved abonnenter ikke adviseres. v 11/21

Indholdsmodel for PublicationCollection PublicationsResponsibleName (1) PublicationResponsibleIdentifier (0-1) Creator (1) CreatorIdentfier (0-1) Owner (1) VersionNumber (0-1) PublicationContentCode (0-1) MunicipalRecordIdentifier (0-1) IsPartOf (0-1) SourceDocumentIdentifier (1) PublicationActionCode (1) Process (0-1) SecurityClassification (0-1) AccessRights (1) Navn på den medarbejder, der har ansvaret for pågældende publicering. Navnet er bygget op af PersonGivenName, PersonMiddleName og PersonSurnameName fra EBXML. Identifikation af den medarbejder, der har ansvaret for pågældende publicering. Elementet kan anvendes af modtagersystemet til at forespørge på detailoplysninger om personen som fx email, telefon osv. Oplysninger om den entitet, der har det primære ansvar for indholdet. Elementet har en direkte reference til element creator i dc_elements.xsd (Dublin core). Identifikation af skaberen af dokumentet. Elementet er en unik identifikation af personen og kan anvendes af modtagersystemet til at forespørge på detailoplysninger om personen som fx email, telefon osv. Ejeren (institution eller organisation) af det system, der sender publikationen. Elementet har en direkte reference til owner i DKFM_elements.xsd Angiver dokumentets versionsnummer, hvis et sådan eksisterer. Kategorisering af dokumentets indhold. Der kan tilknyttes et scheme, der angiver udfaldsrummet. Dokumentets nøgle i KL's journalplan som en string Dokumentet er en logisk eller fysisk del af den refererede ressource. Det vil typisk være nummeret på den sag, dokumentet er en del af. Har en direkte reference til Dublin Core, dcterms:ispartof Dokumentets Identifikation i afsendersystemet af typen anyuri. Besked til modtagersystemet om hvad der skal gøres ved det modtagne dokument, det kan være [create, update, delete]. Elementet angiver hvor i sagsbehandlingsprocessen, dette dokument befinder sig. Det kan være [i behandling; til udtalelse; til godkendelse; til høring; endelig godkendelse]. Elementet har en direkte reference til dkfm:process Kode eller beskrivelse for sikkerhed. Der kan anvendes et scheme, som fastlægger sikkerhedsniveauet for ressourcen ved fastlagt udfaldsrum. Elementet har en direkte reference til dkfm:securityclassification Information om, hvem der må tilgå ressourcen, kan være [ingen stillingtagen; offentligt; ikke-offentligt]- v 12/21

Indholdsmodel for PublicationCollection Elementet har en direkte reference til dkfm:accessrights 5.2. PublicationCollectionIdentifier PublicationCollectionIdentifier er en reference til en PublicationCollection xmlfil. Skemanavn Top element navn GK_ PulicationCollectionIdentifier PublicationCollectionIdentifier Indholdsmodel for PublicationSubscription Elementnavn (forekomster) Beskrivelse PublicationCollectionIdentifier(1) Reference til et PublicationCollection xml document angivet som anyuri 5.3. TargetDocumentIdentifier TargetDocumentIdentifier er dokumentets id i modtagersystemet. Skemanavn Top element navn GK_ TargetDocumentIdentifier TargetDocumentIdentifier Indholdsmodel for PublicationSubscription Elementnavn (forekomster) Beskrivelse TargetDocumentIdentifier(1) Dokumentets identifikation i modtagersystemet angivet som anyuri 5.4. TargetNodeIdentifier TargetNodeIdentifier er den node, hvor dokumentet placeres i modtagersystemet. Skemanavn Top element navn GK_ TargetNodeIdentifier TargetNodetIdentifier v 13/21

Indholdsmodel for PublicationSubscription Elementnavn (forekomster) TargetNodeIdentifier(1) Beskrivelse Den node hvor dokumentet skal placeres i modtagersystemet angivet som anyuri 5.5. PublicationSubscription PublicationSubscription kobler dokumentbeskrivelsen sammen med en url til dokumentets placering i modtagersystemet. Skemanavn Top element navn GK_PublicationSubscription PublicationSubscription Indholdsmodel for PublicationSubscription Elementnavn (forekomster) PublicationCollectionIdentifier (1) TargetDocumentIdentifier (1) TargetNodeIdentifier (1) Beskrivelse Reference til en PublicationCollection xml fil som anyuri Dokumentets identifikation i modtagersystemet, angivet ved anyuri Den node hvor dokumentet skal placeres i modtagersystemet 5.6. PublicationNodeDetails PublicationNodeDetails beskriver en node i modtagersystemets navigationstræ. En node har en identifier, en forælder og et navn. Skemanavn Top element navn GK_PublicationNodeDetails PublicationNodeDetails Indholdsmodel for PublicationNodeDetails Elementnavn (forekomster) Beskrivelse NodeIdentifier (1) Identifikation af den pågældende node, angivet som anyuri NodeName (1) Navnet på den pågældende node, angivet ved en string på 250 karakterer v 14/21

Indholdsmodel for PublicationNodeDetails ParentNodeIdentifier (0-1) NodeAvailableIndikator (1) ChildContainerIndikator (1) Identifikation af den pågældende nodes forældre, angivet som anyuri Indikerer om noden kan anvendes til publisering af dokumentet. Hvis elementet sættes til "true" kan dokumenter publiseres på denne node, hvis "false" kan de ikke Indikerer hvorvidt noden har børn, der er tilgængelige som containere, hvor dokumenter kan publiceres. Det skal hjælpe publiceringsagenten til at navigere gennem træet. Hvis elementet er "true" har noden børn, der er tilgængelige for publicering, hvis "false" har den ikke 5.7. PublicationNodeDetailsResponse PublicationNodeDetailsResponse anvendes i modtagersystemets web service. Når publiceringsagenten forespørger på en nodes børn returneres PublicationNodeCollectionResponse, som består af et ubegrænset antal PublicationNodeDetails. Skemanavn Top element navn GK_PublicationNodeDetailsResponse PublicationNodeDetailsResponse Indholdsmodel for PublicationNodeDetailsResponse Elementnavn (forekomster) PublicationNodeDetails (unbound) Beskrivelse En eller flere noder i modtagersystemets navigationstræ. 5.8. UserIdentifier Useridentifier er en unik identifikation af den bruger, der anvender publiceringsagenten. Skemanavn Top element navn GK_UserIdentifier UserIdentifier Indholdsmodel for UserIdentifier v 15/21

Indholdsmodel for UserIdentifier Elementnavn (forekomster) Beskrivelse UserIdentifier (1) Identifikation af den bruger, der publicerer dokumentet 5.9. RequestChildNodeDetails RequestChildNodeDetails angiver input til operationen GetChildNodes. Skemanavn Top element navn GK_RequestChildNodeDetails RequestChildNodeDetails Indholdsmodel for RequestChildNodeDetails Elementnavn (forekomster) UserIdentifier (1) NodeIdentifier (1) Beskrivelse Identifikation af den bruger, der publicerer dokumentet. Identifikation af den node, hvis børn man ønsker returneret, angivet som anyuri. 5.10. RequestTargetDocumentIdentifierDetails RequestTargetDocumentIdentifierDetails angiver de felter operationen GetTargetDocumentIdentifer skal bruge som input. Skemanavn Top element navn GK_RequestTargetDocumentIdentifierDetails RequestTargetDocumentIdentifierDetails Indholdsmodel for RequestTargetDocumentIdentifierDetails Elementnavn (forekomster) UserIdentifier (1) NodeIdentifier (1) Beskrivelse Identifikation af den bruger, der publicerer dokumentet Identifikation af den node, hvis børn man ønsker returneret, angivet som anyuri 5.11. PublicationFault PublicationFault anvendes til fejlbeskeder, hvis der opstår fejl i web service kaldene. v 16/21

Skemanavn Top element navn GK_ PublicationFault PublicationFault Indholdsmodel for PublicationFault Elementnavn (forekomster) PublicationFault (1) Beskrivelse Fejlbesked om fejl opstået i kaldet til web servicen, angivet som en string. 5.12. NavigatePublicationTarget NavigatePublicationTarget er WSDL for modtagersystemets web service til at navigere i dets indholdsstruktur. NavigatePublicationTarget tilbyder tre operationer, det er GetRootNode, GetChildNodes og GetNewTargetDocumentIdentifier. Service navn Address Location NavigatePublicationTarget http://www.gentofte.dk/webservice/1/navigatepublication.asmx Indholdsmodel for NavigatePublicationTarget Operation Beskrivelse GetRootNode GetRootNode modtager UserIdentifier som inputparameter og returnerer rodnoden i form af PublicationNodeDetailsResponse. GetChildNodes GetChildNodes modtager en NodeIdentifier og UserIdentifier som input parameter og returnerer nodens børn i form af PublicationNodeResponse. GetNewTargetDocumentIdentifier GetNewTargetDocumentIdentifier modtager en NodeIdentifier som input parameter og returnerer det id, det publicerede dokument skal have i modtagersystemet. Id skal validere imod TargetDocumentIdentifier. v 17/21

Bilag 1. Eksempel I dette eksempel beskrives en tænkt publiceringssituation og de skemaer, der udveksles i denne. I eksemplet ønsker Steen Deth at publicere denne rapport om publiceringsagenten fra ESDH-systemet til tre noder i CMS-systemet. Steen åbner publiceringsdialogen i ESDH-systemet og indtaster metadata omkring dokumentet. ESDH-systemet genererer filen GK_PublicationCollectionExample.xml: <?xml version="1.0" encoding="utf-8"?> <PublicationCollection xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:docstd="http://rep.oio.dk/dkfm.dk/docstd/xml/schemas/2003/07/22" xmlns:dkfm="http://rep.oio.dk/dkfm.dk/xml/schemas/2002/07/" xmlns:ebxml="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:cct="urn:oasis:names:tc:ubl:corecomponenttypes:1.0:0.70" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_publicationcollection.xsd"> <PublicationBody> <dc:source>f/it/udvikling/projekter2005/publiceringsagent/rapport.txt</dc:source> </PublicationBody> <dc:title>rapport om publiceringsagent</dc:title> <dc:subject>it, publicering, cms, esdh</dc:subject> <PublicationDate>2005-12-15</PublicationDate> <PublicationExpiryDate>2006-12-15</PublicationExpiryDate> <PublicationNotificationIndicator>true</PublicationNotificationIndicator> <PublicationsResponsibleName> <ebxml:persongivenname>steen</ebxml:persongivenname> <ebxml:personsurnamename>deth</ebxml:personsurnamename> </PublicationsResponsibleName> <PublicationResponsibleIdentifier>f/persons/it/135</PublicationResponsibleIdentifier> <dc:creator>signe Wagner, Devoteam Fischer og Lorenz</dc:creator> <CreatorIdentifier>http://www.devoteam.dk/persons/SWA</CreatorIdentifier> <dkfm:owner>steen Deth</dkfm:owner> <VersionNumber>1.0</VersionNumber> <PublicationContentCode>it-projekt</PublicationContentCode> <MunicipalRecordIdentifier>85.11</MunicipalRecordIdentifier> <dcterms:ispartof>100.254.333</dcterms:ispartof> <SourceDocumentIdentifier>f/it/udvikling/projekter2005/publiceringsagent/Rapport.txt</SourceDocumentIdentifier> <PublicationActionCode>create</PublicationActionCode> <dkfm:process>godkendt</dkfm:process> <dkfm:securityclassification>low</dkfm:securityclassification> <dkfm:accessrights>offentligt</dkfm:accessrights> </PublicationCollection> Desuden vælger Steen CMS-systemet som det system, han ønsker at publicere dokumentet i. v 18/21

ESDH-systemet kalder CMS-systemets web service NavigatePublicationTarget. Først kaldes operationen GetRootNode, der tager UserIdentifier som inputparameter: <?xml version="1.0" encoding="utf-8"?> <UserIdentifier xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_useridentifier.xsd">f/persons/it/135</useridentifier> og returnerer rodnoden i form af PublicationNodeDetailsResponseExample.xml: <?xml version="1.0" encoding="utf-8"?> <PublicationNodeDetails xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_publicationnodedetails.xsd"> <NodeIdentifier>SC/</NodeIdentifier> <NodeName>RootName</NodeName> <ParentNodeIdentifier>/</ParentNodeIdentifier> <NodeAvailableIndikator>false</NodeAvailableIndikator> <ChildContainerIndikator>true</ChildContainerIndikator> </PublicationNodeDetails> På baggrund af outputtet og UserIdentifier kaldes operationen GetChildNodes med inputtet RequestChildNodes <?xml version="1.0" encoding="utf-8"?> <RequestChildNodeDetails xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_requestchildnodedetails.xsd"> <UserIdentifier>f/persons/it/135</UserIdentifier> <NodeIdentifier>SC/</NodeIdentifier> </RequestChildNodeDetails> GetChildNodes returnerer PublicationNodeDetailsResponse: <?xml version="1.0" encoding="utf-8"?> <PublicationNodeDetailsResponse xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_publicationnodedetailsresponse.xsd"> <PublicationNodeDetails> <NodeIdentifier>SC/organisation/</NodeIdentifier> <NodeName>Organisation</NodeName> <ParentNodeIdentifier>SC/</ParentNodeIdentifier> <NodeAvailableIndikator>false</NodeAvailableIndikator> <ChildContainerIndikator>true</ChildContainerIndikator> </PublicationNodeDetails> <PublicationNodeDetails> <NodeIdentifier>SC/news/</NodeIdentifier> <NodeName>News</NodeName> <ParentNodeIdentifier>SC/</ParentNodeIdentifier> <NodeAvailableIndikator>true</NodeAvailableIndikator> v 19/21

<ChildContainerIndikator>true</ChildContainerIndikator> </PublicationNodeDetails> <PublicationNodeDetails> <NodeIdentifier>SC/projekter2005</NodeIdentifier> <NodeName>Projekter 2005</NodeName> <ParentNodeIdentifier>SC/</ParentNodeIdentifier> <NodeAvailableIndikator>true</NodeAvailableIndikator> <ChildContainerIndikator>true</ChildContainerIndikator> </PublicationNodeDetails> </PublicationNodeDetailsResponse> Der foretages flere kald af denne type efterhånden som Steen ned igennem CMSsystemets træ. Den valgte node gemmes som TargetNodeIdentifier. Han finder frem til den node, hvor han ønsker dokumentet publiceret. Her kaldes GetNewTargetDocumentIdentifier med inputparameteren RequestTargetDocumentIdentifierDetails: <?xml version="1.0" encoding="utf-8"?> <RequestTargetDocumentIdentifierDetails xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_requesttargetdocumentidentifierdetails.xsd"> <UserIdentifier>f/persons/it/135</UserIdentifier> <NodeIdentifier>SC/organisation/it/it-projekter2005</NodeIdentifier> </RequestTargetDocumentIdentifierDetails> GetNewTargetDocumentIdentifier returnerer TargetDocumentIdentifier, som er det id, det publicerede dokument skal have i modtagersystemet: <?xml version="1.0" encoding="utf-8"?> <TargetDocumentIdentifier xmlns="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:dkfm="http://rep.oio.dk/dkfm.dk/xml/schemas/2002/07/" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/xmlschemainstance" xsi:schemalocation="http://rep.oio.dk/gentofte.dk/xml/schemas/2005/09/12/://rep.oio.dk/gentofte. dk/xml/schemas/2005/09/12/gk_targetdocumentidentifier.xsd"> SC/organisation/it/it-projekter2005/1164</TargetDocumentIdentifier> På baggrund af den modtagne id og de indtastede metadata genererer publiceringsagenten/esdh-systemet GK_PublicationSubscriptionExample.xml: <?xml version="1.0" encoding="utf-8"?> <PublicationSubscription xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:docstd="http://rep.oio.dk/dkfm.dk/docstd/xml/schemas/2003/07/22" xmlns:dkfm="http://rep.oio.dk/dkfm.dk/xml/schemas/2002/07/" v 20/21