Publiceringsagent i Gentofte Kommune (GPAC)

Transkript

1 Publiceringsagent i Gentofte Kommune (GPAC) Version 3.0, august Rev /01/SDE Indledning Dette dokument beskriver det overordnede koncept for Gentofte Kommunes publiceringsagent også kaldet GPAC (et mundret akronym, der står for Gentofte Kommunes PublicationAgent Concept). GPAC implementer en række software komponenter, som tilsammen giver mulighed for i al sin enkelhed at publicere dokumenter fra et system til et andet. Mens der således isoleret set, er tale om ret beskeden funktionalitet 1, er der en række andre grunde til, at konceptet er udtænkt. Konceptet opfylder nemlig en række arkitektur krav, som Gentofte Kommune mener, er vigtige at forfølge Uafhængighed af software leverandører Åbne ikke proprietære integrations snitflader, der ejes, er forankret og vedligeholdes af kommunen selv og/eller uvildige communities Konsekvent anvendelse af SOA understøttede, robuste og løst/koblede EDA integrationsmønstre Anvendelse/overholdelse af offentlige standardiserings produkter (så langt som muligt) I praksis betyder det at GPAC kan bruges til at implementere publicering af dokumenter fra et system til et andet, uden af de 2 systemer og deres respektive leverandører, kender noget til hinanden at implementering på både afsender og modtager side, kan gennemføres med en relativ lille indsats (3-6 relativt ukomplicerede services på hver side) at en eksisterende GPAC implementering på afsender side, kan genbruges i forhold til et nyt modtager system uden at afsender systemets skal tilrettes overhovedet (og vice versa). GPAC stilles til rådighed som på ITST softwarebørsen. Licenstype og governance model er ikke afklaret endnu. Baggrund Siden oktober 2003 har Gentofte Kommune (herefter GK) benyttet sig af ESDH systemet Scanjour som kommunens primære forvaltningsarkiv. I systemet produceres og arkiveres sagerog dokumenter indenfor forskellige sagsområder som fx. borgersag, byggesag, emnesag, personalesag mv. 1 Løsningen giver mulighed for metadataopmærkning af publicerings dokumenter, automatisk genpublicering mv., så en helt simpel kopieringsfunktion, er der trods alt ikke tale om. 1

2 Derimod har ESDH systemet ikke været tænkt til også at skulle understøtte kommunens behov for formidling af viden. Den rolle har siden 2001 primært været tiltænkt GKs intranet og hjemmeside platforme. Som konsekvens har GK siden første ESDH implementering i oktober 2003, suppleret ESDH løsningen med en såkaldt publiceringsagent, der har fungeret som bindeled mellem ESDH og intranet/hjemmeside platformen eller mere præcist, har givet brugere mulighed for at publicere dokumenter (formidlingsprodukter) fra ESDH systemet til udvalgte placeringer (mapper) på intranettet. Medio 2007, er løsningen udkommet i 3. generation i takt med løbende opgradering af både Intranet og ESDH systemer. Aktuelt er ca ESDH producerede dokumenter publiceret på kommunens Intranet, heraf er knap halvdelen i stående abonnement, dvs. de opdateres automatisk på Intranettet, når dokumentet redigeres i ESDH systemet. Over tid er løsningen udviklet med bistand fra flere forskellige leverandører, herunder naturligvis kommunens ESDH og Intranet/hjemmeside leverdører. Kommunen har desuden benyttet andre leverandører, til a) kvalitetssikring af konceptet og udarbejdelse af fx XML skemaer for udveksling, samt b) implementering af middleware publiceringsagent. Relevante dokumenter, herunder XML skemaer, er placeret i ISB en 2. Afgørende har dog været, at det er kommunen selv, der har haft/har ejerskab på konceptet og de snitflader, der sikrer uafhængighed mellem ESDH og CMS systemerne. Dette dokument beskriver publiceringsagenten i forskellige detail grader, således at løsningen kan inspirere (eller ligefrem erhverves) til brug for andre organisationer og i andre sammenhænge. Læsevejledning Dokumentet er udarbejdet, så primært forretnings rettede læsere, kan få udbytte af indholdet. En detaljeret teknisk beskrivelse er indeholdt i et selvstændigt dokument [endnu ikke publiceret]. Krav til publiceringsløsning Opfyldelse af en række krav har været styrende for udviklingen af publiceringsagenten: 1. Løsningen skal understøtte publicering fra mange dokument kilder til mange publiceringsdestinationer. I det følgende benyttes CMS (Content Managemenet System), som fælles betegnelse for destinationsystemer. 2. Løsningen skal implementeres uden bilateral/hård kobling mellem de IT-systemer, der indgår på begge sider af en publicerings session. Det skal forstås helt bogstaveligt; kildeog destinationsystemer må intet kende til hinanden. Dette krav skal sikre fleksibilitet og uafhængighed (af fx leverandører) ved opgraderinger, skift til andre platforme osv. 3. Løsningen skal understøtte automatisk genpublicering af dokumenter i CMS, når det tilsvarende dokument opdateres i ESDH (kilde) systemet. 2 ISB = InfoStrukturDatabsen i regi IT & Telestyrelsen. Link til GKs materiale: 2

3 4. Der skal kunne foretages opmærkning af dokumenter med nøgleord, med udgangspunkt i en fælles eksternaliseret (på tværs af platforme) nøgleordliste. Hensigten med dette krav er, at tilgodese strukturede (nøgleordbaserede) søgninger på tværs af kommunens IT-platforme. 5. Teknisk skal løsningen understøtte robust, nær-realtids (gen)publicering og entydig ansvarsfordeling mellem systemleverandører i driftsmiljøet. Ved robust drift skal blandt andet forstås, at publiceringer gennemføres pålideligt, dvs. enten er de gennemført med succes hele vejen eller også er de ikke gennemført overhovedet. Desuden, at hvis noget går galt undervejs skal ansvaret for den svigtende part, kunne identificeres entydigt, herunder leveres der passende fejl melding til den ansvarlige part. 6. Løsningen skal implementeres open source like uden brug af 3. parts komponenter og kildetekst skal være tilgængelig (efter nærmere aftale). Specielt skal løsningen kunne implementeres uden anskaffelse af bekostelig middelware (ESB, messagebrokers mv.). Afgrænsninger Grundlæggende er løsningen tænkt til at kunne publicere, hvad som helst, til flere destinationer på én gang. Den nuværende implementering er dog begrænset til kun at understøtte samtidig publicering af ét ESDH dokument til flere, men forskellige typer af destinationer, fx Intranet, Internet/hjemmeside, filsystem mv. Samtidig publicering af et ESDH dokument til forskellige placeringer i samme CMS indholdsstruktur er ikke understøttet pt., da det vil introducere en form for redundans, der i mange (vel de fleste) tilfælde ikke er ønskelig. Løsningen er endvidere begrænset til pt. kun at understøtte publicering af ét dokument ad gangen (men altså til flere typer af destination). I en efterfølgende version af løsningen, kan det overvejes at fjerne denne begrænsning, så fx et helt sagskompleks, eller en udvalgt gruppe af sager/dokumenter/elementer, kan publiceres i et hug. Selv om GPAC grundlæggende er tænkt platforms uafhængig, er den aktuelle implementering i GK gennemført i et MS baseret server miljø, herunder er der anvendt MS.Net teknologi til udvikling af løsningen. I version 3 af løsningen understøttes alle ovenstående krav. Dog er der endnu ikke konkret drift erfaring med implementering af flere kilder og CMS systemer. Løsningen er dog afprøvet på PoC niveau med flere kilder og mod flere destinationer (CMS). 3

4 Løsningsbeskrivelse Figur 1 illustrerer løsningen på en konceptuelt/overordnet niveau, for publicering mellem flere kilde- og flere destinationssystemer (Px til Sx). Figur 1, konceptuel løsningsbeskrivelse Løsningen er udviklet som en variation over et såkaldt klassisk publisher-subscribe design mønster 3, hvor flere udgivere (publishers) via en publiceringsagent sender dokumenter til en eller flere modtagere (subscribers). Udgiverne af materialet kender intet til modtagerne og omvendt, kender modtagerne intet til udgiverne, men tegner derimod abonnementer via en uvildig (publicerings)agent (controller). Abonnementer tegnes fx. på kategorier/typer af materiale, som agenten udstiller for interesserede modtagere/abonnenter. I den klassiske udgave, er det typisk modtageren af materiale der udvælger hvad der skal abonneres på. Med andre ord er produktion af materiale og tegning af abonnement på materialet 3 Publisher-Subscripe... ref. liste 4

5 ift. et givent modtagersystem, principielt 2 uafhængige situationer, som herunder, ift. det generelle mønster, udføres af forskellige brugere 4. GKs publiceringsløsning tager afsæt i, at den bruger der producerer formidlings-materiale, også bedst ved eller i alle fald, har en idé om hvilke medier og/eller kanaler materialet skal udstilles i/på. Samtidig, at produktion og formidling af materiale, er en del af et samlet forløb i modsætning til 2 uafhængige forløb, som beskrevet ovenfor. Endelig og ret lavpraktisk, har processen med at publicere materiale direkte til Intranettet igennem CMS platformens egne værktøjer (især i GKs tidligere CMS generationer), været temmelig vanskelig/fejlbehæftet, hvorfor en let tilgængelig ESDH tilknyttet publiceringsmulighed, har været set som en vej til, at facilitere øget formidlig af viden til kommunens medarbejdere et vigtigt forretningsmål i sig selv. I løsningen er der derfor implementret en publiceringsdialog, som brugeren anvender fra ESDH systemet, når et dokument, ønskes publiceret til kommunens Intranet. Dialogen åbnes fra ESDH systemet og opleves af brugeren, som en del af ESDH systemet men er i virkeligheden blot den synlige komponent i publicerings agent komplekset. Et abonnement repræsenteres for publiceringsagenten af samlet set af 3 filer; 1) det fysiske dokument, 2) et XML dokument der beskriver metadata for dokumentet og 3) endnu et XML dokument der beskriver destinationen for dokumentet. Løsningen beskrives i det følgende med udgangspunkt i konkret publicerings case fra Scanjour Captia til GKs Intranet (der er baseret på Sitecore CMS platformen). Case 1, publicering fra Scanjour Captia til Intranet a) I Captia er oprettelse/redigering af et dokument afsluttet. Med dokumentet i fokus, åbner brugeren en publiceringsdialog ved klik på Publicér knappen (figur 2). Figur 2, Captia aktivering af Publicér menupunkt 4 I praksis kan processerne selvfølgelig være tættere integreret, brugeren en og samme person osv. Uanset, så forfølges den diskussion ikke yderligere her. 5

6 Som resultat åbnes publiceringsdialogen modalt 5. Figur 3, publiceringsdialog Dialogen er forudfyldt med metadata hentet fra ESDH systemet (Captia), som fx dokumentnr., sagsbehandler, organisatorisk enhed og titel. b) Brugeren udfylder dernæst dialogen med yderligere oplysninger: Publiceringsmål. Hvor skal dokumentet placeres i CMS indholdstrukturen? Placeringen udvælges ved (on-line/realtid) at navigere rundt i en stifinder lignende dialog, der repræsenterer CMS systemets indholdsstruktur (sitemap). Dialogen åbnes ved klik på ikonen. Stifinderen er vist i figur 4. 5 Modal åbning betyder, at det bagvedliggende ESDH system ikke kan betjenes, før publiceringsdialogen lukkes igen. 6

7 NB! I den aktuelle implementering, præsenteres brugeren kun for ét publiceringsmål. Men løsningen er designet således at, at det via konfigurations indstillinger, er muligt at tilføje og dermed vælge andre samtidige publiceringsmål, som fx hjemmeside, filsystem, eksterne sites (fx borger.dk) osv. I den situation er publiceringsdialogen, udvidet med flere CMS browser ikoner ( ) og sti visningesfelter i publiceringsdialogen én for hvert destinations CMS system. Brugeren vælger konkret placering i det pågældende CMS, ved at browse rundt i det CMS systemet (CMS browser dialog i figur 4, genbruges til formålet) og dernæst vælge placering. Figur 4, dialog for valg af dokument placering (mappe) på Intranet Tidspunkt for publicering og afpublicering angives (i GK udfyldes felterne med standardværdierne, publicering = dags dato, afpublicering = dags dato + 1 år). Brugeren tager dernæst stilling til om dokumentet automatisk skal genpubliceres i CMS, når det rettes i kilden (Captia). Denne indstilling er central for løsningen, da den for de 7

8 ESDH dokumenter der redigeres løbende sikrer automatisk opdatering på Intranettet, uden brugeres stillingtagen, fra gang tll gang. Med et flag (Advis), har brugeren mulighed for at angive om publiceringen, skal resultere i, at CMS systemet sender advis/notifikation til de brugere i CMS systemet, som abonnerer på dokumentet (direkte eller indirekte). Flaget forudsætter at CMS systemet understøtter adviseringer til brugere hvilket er tilfældet med GKs Intranet og vel de fleste andre CMS ser. Endelig er der mulighed for angivelse af relevante nøgleord for det pågældende dokument. c) Brugeren klikker dernæst på OK for at acceptere publiceringen (og det implicitte abonnement, der tegnes). d) Dialogen lukkes og brugeren vender tilbage til ESDH systemets brugergrænseflade. e) Efter relativ kort tid (2-15 minutter) dukker dokumentet op på Intranettet i den mappe, som brugeren udpegede i CMS stifinderen (figur 4). Herefter behøver brugeren i princippet aldrig at tænke på publiceringen (abonnementet) igen. Hvis brugeren har tilvalgt genpublicering ved opdateringer, genpubliceres dokumentet (inkl. evt. advis til Intranet brugerne), når dét selv eller metadata (fx sagsbehandler), opdateres i Captia. Hvis brugeren har angivet en udløbsdato i publiceringsdialogen, afpubliceres dokumentet fra Intranettet når datoen oprinder (men abonnementet består, så dokumentet kan reaktiveres for publicering, hvis behovet skulle opstå). Publiceringsdialogen kan til enhver tid åbnes igen og indholdet redigeres. Fx kan der vælges en anden placering i CMSs indholdsstruktur og/eller der kan tilføjes yderligere nøgleord. Ved klik på OK, genpubliceres dokumentet (dokumentet flyttes fx til ny placering i CMS og tagges med nye nøgleord). Fra Captia med et tidligere publiceret dokument i fokus kan brugeren endelig vælge at slette en publicering helt (dvs. et publiceringsabonnement) ved at vælge menupunktet Slet publicering (se figur 2, til højre for Publicér menupunktet). Det medfører, at det tilsvarende dokument i CMS systemet slettes og abonnementet opsiges for stedse. Dokumentet kan efter sletning, publiceres igen, men der vil i givet fald, være tale om et nyt abonnement, sidestillet med en førstegangspublicering. 8

9 Overordnet teknisk koncept Som nævnt tidligere er GPAC implementeret med anvendelse af SOA design principper og EDA integrationsmønstre, som faste arkitektur pejlemærker. Dette afsnit beskriver et spadestik dybere, hvad GPAC består af, og hvordan GPAC kan anvendes til at etablere et dokument publicerings scenarie. For en dyb teknisk beskrivelse, henvises til den system dokumentation, der leveres sammen med kildekoden til GPAC. Figur 5, viser hvilke komponenter/snitflader og sammenhænge GPAC består af. Figur 5, GPAC komponenter og service snitflader GPAC leveres med de komponenter, der er skitseret inden for den håndtegnede ø i figur 5. Med udgangspunkt i figuren, beskrives hvilke services, der benyttes undervejs i en publicerings cyklus. 9

10 A1) Publiceringsdialogen er en selvstændig web (GUI) applikation/komponent ( ), som via ESDH systemets brugergrænseflade, åbnes for inddatering af publiceringsmål osv., som beskrevet under case 1 ovenfor. A2) Når dialogen åbnes hentes metadata (som fx sagsbehandler) fra ESDH systemet ved kald af GetDocMetadata() og evt. tidligere dialogvalg hentes via GetConfig() servicekald. GetDocMetadata() er sammen med andre services, implementeret i en web service komponent tæt på ESDH systemet ( ). GetConfig() og de øvrige xxxconfig() service kald er også implementeret i en selvstændig web service komponent ( ). A3) Udvælgelse af publiceringsmål (mappe) i CMS modtager systemet, sker ved hjælp af de 3 service kald (GetRootNode(), GetChildrenNodes() og GetNewIdent()). De 3 kald er implementeret som en selvstændig web service komponent (typisk i nærheden af modtager systemet). Nøgleord (A2) væles tilsvarende ved kald af GetKeywordsCat() og GetList(), implementeret i selvstændig web service komponent ( ). Når indtastning i publiceringsdialogen afsluttes med brugerens accept (OK), gemmes dialog valg (A2 SetConfig()) og dokumentet sættes i publicerings abonnement i maven på ESDH systemet (via service kaldet SetSubscription()). A4) Foruden ESDH nære services, som fx GetDocMetadata(), implementerer ESDH systemet internt en mekanisme/trigger, der holder øje med om dokumenter der er i abonnement eller metadata vedrørende ditto, opdateres. Når et dokument i ESDH er blevet opdateret af en bruger, sender ESDH systemet besked til GPAC via web service kaldet SignalDocChanged() implementeret i web service komponenten ( ). Når SignalDocChanged() kaldes, bygges der 3 dokumenter et publiceringssæt som består af dokumentet selv, metadata om dokumentet og publiceringsmål for dokumentet. De 3 dokumenter kommer til live ved kald af GetDocMetadata(), GetDocument() og GetConfig(). De 3 dokumenter placeres i en kø (illustreret ved filesharet \\FromEsdh2GW i figur 6). 10

11 SJ Publiceringsdialog \Teknik og miljø\...\lokalplaner Gennemse A B C CMS OK Ident DB abc.doc abc.doc abc.xml \\FromEsdh2GW \\FromGW2CMS abc.xml 18/ , SDE Figur 6, GPAC dokument flow fra ESDH til CMS Den såkaldte publiceringsagent (grå kasse med skarpe hjørner i figur 5), holder øje med, om der ligger nye dokumentsæt til behandling i \\FromEsdhGW køen. I givet fald påbegynder agenten en udredning af, om det er første gang dokumentet publiceres, om der er tale om genpublicering eller evt. om dokumentet skal slettes. Uanset konsulterer publiceringsagenten den mapnings database, som indeholder nøglepar og publiceringsmål for dokumenter, der allerede er i abonnement. Denne konsultation sker også via web service kald (uddybes senere). Mapningsdatabasen opdateres evt. og dokumentsættet fra \\FromEsdhGW rettes evt. en smule til, og kopieres derefter til \\FromGW2CMS filesharet endnu en kø. Nu er publiceringen for så vidt GPAC konceptet selv overstået. Dokumentsættet ligger for føderne af CMS systemet, som dernæst har ansvaret for at indlæse dokumentet til sig selv og placere det i den mappe, der tidligere blev udvalgt i publiceringsdialogen, samt endelig at opmærke dokumentet med eventuelle metadata. CMS systemet tager sig af denne indlæsning ved at implementere en passende lytte/indlæsnings service. Hvad skal der til for at bruge/genbruge GPAC Som nævnt indeholder GPAC out of the box alle de komponenter og services der ligger inde på ø en i figur 5. 11

12 Når løsningen frigives på software børsen, vil den indeholde 2 teststubbe, der vil udgøre det for et ESDH system, henholdsvist et CMS system. Tanken er, at GPAC efter installation i et udviklingsmiljø, kan afvikles 100% med afsæt i dette simple ESDH-CMS teststub scenarie. ESDH leverance For at indgå i GPAC konfiguration, skal ESDH eller afsender leverandøren, implementere følgende services: GetDocument() GetDocMetadata() SetSubscibtion() SignalDocChanged() og den service, der holder øje med, at et dokument eller metadata til et dokument er opdateret. Når der sker opdateringer (for dokumenter i abonnement), kaldes web services SignalDocChanged() indtil kaldet lykkes. ESDH skal desuden (og selvfølgelig) implementere en registrering af, hvilke dokumenter, der er i opdaterings abonnement. CMS leverance For at indgå i GPAC konfiguration, skal CMS leverandøren eller modtager systemet implementere følgende services: GetRootNode() GetChildNodes() GetNewIdent() og den service, der holder øje med at et dokumentsæt er placeret i det fileshare (\\FromGW2CMS ), som CMS systemet er konfigureret til at lytte på- og indlæse dokumenter fra