Informationsmøde for it-leverandører om afprøvning

Relaterede dokumenter
P R O J EKTSKITSE ( B I L A G 7. 1 )

Om projektet afprøvning af MOX-konceptet

1. Ledelsesresumé. Den 2. juli Jnr Ø90 Sagsid Ref NSS Dir /

Sager på tværs. MOX giver sammenhængende processer på tværs af it-systemer

Indeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76

Version Dato Beskrivelse /11/2012 Initial version /03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Axapoint Reviewkommentar til MOX-specifikation Version udarbejdet af It-arkitekturrådets arbejdsgruppe

Realisering af gevinster på Sag- og Dokumentområdet

MOX et forretningsmønster for fagsystemers udveksling af hændelser

Hvad er sket i juni-august 2006 Følgende kommuner deltager i projektet: 1. Gentofte 2. Greve 3. Helsingør 4. Herning. De 18 tilmeldte kommuner

Bilag 1: Arkitekturrapport, EDS Hjælpemidler

1. ordinære møde og social-fagligt døgn i Kommunernes It-Arkitekturråd

Referat af 3. ordinære møde i Kommunernes It- Arkitekturråd

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

Mødet afholdes onsdag den 12. september 2012, kl i KL- Huset, Weidekampsgade 10, 2300 København S, i mødelokale S-10.

Kommunal Ledelsesinformation - KOMLIS

OS2MO arkitekturgruppe møde

Status på Sag og Dokument

Afbud: Thomas Martinsen, it-arkitekt i Digitaliseringsforening Sjælland (DIGIT) Lasse, KOMBIT, Rikke Vester Nielsen, KOMBIT

DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

N O TAT. Udkast til: KL s politik på sags- og dokumentområdet. Anbefalinger i KL s politik på sags- og dokumentområdet

STS ARBEJDSGRUPPEMØDE VEJLE

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

Sag og dokument standarderne - Hvad og hvorfor

Rammearkitekturen og services i et lokalt perspektiv

Bilag 8: Program for temadag. Bilag til dagsordenspunkt 13: Temadag om arkitekturstyring Revideret pr. 10. september 2013

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014

6. Status på arbejdet med fælles infrastruktur (fast punkt)

Fællesoffentlig beskedmodel version 1.0

Høringssvar vedrørende Specifikation af serviceinterface for person (part)

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

KMD Sag II udfasningsassistance. Bilag G: Grænsefladedokumentation til KMD Sag. Dokumentet er udarbejdet af KMD. Version 2.1.

Forord. Versioner. Version Date Description /06/2013 Initial version /07/2013 URI er ændret

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

Kommentarer til dokumentet MOX et forretningsmønster for fagsystemers udveksling af hændelser

D A G S ORDEN. 4. ordinære møde i Kommunernes It-Arkitekturråd

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

OS2MO 2.0 Fugl Fønix

Socialanalyse Øget datadeling på socialområdet

R EF ER AT. Referat af 4. ordinære møde i Kommunernes It-Arkitekturråd

Kommunale cases: Frederiksberg & VeRA. Marius Hartmann It og forretningsarkitekt Frederiksberg kommune

Version 1.0. Vejledning til brug af Støttesystemet Organisation

Høringssvar vedrørende FESD Datafølgeseddel

En mappe anvendes til at organisere postkasser. Man kan godt lave et hierarki

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks

SPOR 2: STØTTESYSTEMER

Rammearkitekturer der hænger sammen

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS

1. Godkendelse af referat og dagsorden Dagsordenens oprindelige punkt 3 rykkes op som nyt punkt 2

SAPA Kommunenetværk Øst & Vest. KMJ 28. august 2013, Værløse 29. August 2013, Middelfart

SNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser

Bilag 2: Høringssvar til Forslag til resultatorienteret forretningsarkitektur på beskæftigelsesområdet

Sag og Dokument: Eksempel på brug af generelle egenskaber

R E F E R A T. Referat af 2. møde i styregruppen for MedCom11-projektet Modernisering af MedCom Infrastruktur POC

STS ORGANISATION. 26. februar 2019

Underbilag 2O Beskedkuvert Version 2.0

ESDH - DET SIKRE VALG I DIN DIGITALE HVERDAG. Jørgen Hedegård. 13. september 2018 IMPULS 2018

DUBU digitalisering af udsatte børn og unge

(Bilag til dagsordenspunkt 8, Sikkerhedsstandarder og løsninger på sundhedsområdet).

REFERENCEARKITEKTUR FOR OPSAMLING AF HELBREDSDATA HOS BORGEREN. Pia Jespersen Thor Schliemann

Introduktion til MeMo

Overordnet set vurderer Odense Kommune, at både det foreliggende udkast og det bagvedliggende arbejde er af høj kvalitet.

EKSTERNT REFERAT. Møde den: 24. september It-forum mødereferat

Arkitekturrapport: KITOS - Kommunens It-Overbliks System

Styr på data er fundamentet for værdi

D A G S ORDEN. Sjette netværksmøde i Sammen om de unge implementering af ungepakken. Tid: Onsdag den 26. oktober 2011 kl

OS2 Rollekatalog i Horsens Kommune. Tanker om ibrugtagning

DOKUMENTBROKER Koncept

Referat fra møde i kommunaldirektørnetværket i den midtjyske region

Opsamling af leverandørdialog

Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks

DPR anvendelse Applikationer, som trækker på DPR

Dagsorden og referat bestyrelsesmøde den 8. april 2019

Der var en drøftelse om de kreative fag som f.eks. billedkunst, som kræver mere tid for komme i dybden med et læringsforløb, skal

DPR anvendelse Applikationer, som trækker på DPR

Dagsorden 5. ordinære møde i Kommunernes It-Arkitekturråd

NOTAT Til Arbejdsgruppen vedrørende den fremtidige lokalradioog tv-ordning

Dagsorden til 7. ordinære møde i Kommunernes It-Arkitekturråd

Referat af DU-møde 3. maj

Referat Informationsmøde 5. oktober 2018

Introduktion Fokusområde: Kendskab Fokusområde: Kompetencer Fokusområde: Succes sammen Fokusområde: Politisk dagsorden...

Guide til NemLog-in Security Token Service

STS NETVÆRKSDAGE. Spor 3: Beskedfordeler. 11. og 12. marts Christian Callsen

FJERNPRINTLEVERANDØRMØDE 25. JANUAR 2017

G E O D A N M A R K B E S T Y R E L S E S M Ø D E

TØNDER DISTRIKTSSKOLE Møde Dato Kl. Lokale

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

1 Objekt informationsmodel - Byggeblok

NOTAT REFERAT AF DIGITALISERINGSNETVÆRK DEN 19. MAJ 2010

REFERAT Skolebestyrelsesmøde Dagsorden. Til drøftelse: Torsdag den 10. marts 2016 kl Konferencelokalet

Brugerklubben SBSYS en værdiskabende andelsbevægelse i fremtidens digitale landskab. V/ Jes Rønnow Lungskov, Vejle Kommune

Referat af bestyrelsesmøde onsdag d kl

Fællesskabet der vil noget mere

IKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION

Referat fra Lollands Banks ordinære generalforsamling onsdag den 6. april 2016

Referat Hovedbestyrelsesmøde

Introduktion til Støttesystemet Beskedfordeler

SF1460_C Aflever besked Integrationsbeskrivelse - version 2.2.2

Transkript:

R EFERAT Informationsmøde for it-leverandører om afprøvning af MOX-specifikationen KL-huset, 24. september 2012 13.00 1500 På mødet deltog: It-leverandører: Jesper Vejs, IBM Esben Zeuthen, Medialogic A/S Christian Poulsen, Medialogic A/S Steen Jensen, KMD Kent Aabjerg Nielsen, Silkeborg Data Jørgen Hedegård, Traen Thomas Groenbaek, Dafolo Claus Simonsen, Convergens Jens Bruntt, Convergens Michael Nielsen, Axapoint Kommuner/KL David Schwartz Møller, Svendborg Kommune Martin Scheil Corneliussen, Hjørring Kommune Rasmus Vandkjær Rasmussen, Frederikshavn Kommune Marc David Martin, Horsens Kommune Erik Helweg Larsen, KL Nikolaj Skovmann Malkov, KL Den 2. oktober 2012 Jnr 01.04.02 P20 Sagsid 000245418 Ref NSS nss@kl.dk Dir 2478 6165 Weidekampsgade 10 Postboks 3370 2300 København S Tlf 3370 3370 Fax 3370 3371 www.kl.dk 1/5 Referent: Nikolaj Skovmann Malkov Mødet var indkaldt i anledning af, at KL og Kommunerne igennem en arbejdsgruppe under Kommunernes It-Arkitekturråd (Arkitekturrådet) i efteråret 2012 vil gennemføre en række konkrete afprøvninger af Specifikation for MOX et forretningsmønster for fagsystemers udveksling af hændelser. It-

leverandørerne var inviteret igennem en åben invitation for alle itleverandører på kl.dk. Erik og Nikolaj gennemgik på vegne af arbejdsgruppen indledningsvis meget kort tankerne bag specifikationen, der ligger til grund for afprøvningen og ridsede planerne for de konkrete afprøvninger op: En afprøvning foregår i en kommune og involverer typisk to leverandører Beskedfordeling foregår i afprøvningen via en lokal instans af en RabbitMQ server. Forestiller vi os. Der kan i de enkelte afprøvninger være forhold, der gør, at en central instans er bedre egnet. Scope for en afprøvning er ikke en hel proces, men derimod en overførsel mellem to leverandørers systemer via beskeder. Fx overførsel af et objekt, der beskriver et dokument eller en sag. Leverandøren skal - som et led i afprøvningen - lave agenten til eget system, der oversætter egne snitfladeinformationer til OIO-besked og omvendt kan modtage OIO-besked og oversætte den til egne snitfladeinformationer. Der er ingen krav om, at afprøvning skal foregå i produktionsmiljø. Afprøvningerne er tænkt til at løbe fra nu og frem til uge 51. Der foreligger ikke initialt en driftsmodel for MOX-konceptet efterfølgende. Erfaringerne fra afprøvningerne skal være med til at kunne opstille nogle scenarier for det videre forløb, som Arkitekturrådet kan tage stilling til. De kommunale deltagere i arbejdsgruppen har en opstillet en række forslag til konkrete afprøvninger, som de gerne vil have prøvet MOX-konceptet af på: Svendborg Kommune: Medialogic Workbase og Traen Acadre o Journalisere Workbase-dokumenter i Acadre Hjørring Kommune: KMD Care og SB-SYS o Journalisere Care-dokumenter i SB-Sys Frederikshavn Kommune: Dafolo blanketsystem Traen Acadre o Journalisere Dafoloblanket i Acadre Odense Kommune: Convergens/KMD LOS/APOS2 o Vedligehold af organisationsoplysninger KL/Ballerup Kommune: APOS2/APOS2 o Distribution af ændringer i klassifikation (KLE/FORM) ved hjælp af beskeder i APOS2 Beskedfordeling er et vigtigt middel i MOX-konceptet. Men etablering af en beskedfordeler er ikke et mål i sig selv. Til beskedfordeling anvendes i hver 2

afprøvning en instans af RabbitMQ, der kører på AMQP-protokollen for beskedudveksling. AMQP er en åben, internationalt afprøvet og anvendt standardprotokol for beskedudveksling. Den er udviklet med programmeringssproget ERLANG, der ligger til grund for de fleste internetroutere. RabbitMQ er et open source produkt, der kører på AMQP-protokollen. RabbitMQ anvendes blandt andet af flere store firmaer i den finansielle sektor og findes også i kommercielle udgaver, hvor man kan få lov til at betale for support mv., bl.a. VM Ware har den som produkt. RabbitMQ kan også håndtere federation i fald der kommer mere end en beskedfordeler i spil. Det vil formentlig ikke være tilfældet i afprøvningen, men er et realistisk scenarie for den fremtidige arkitektur. Erik gennemgik formatet for beskeden, der vil bestå af en header med en række key values, som anvendes i forbindelse med routing af beskeden. Endvidere gennemgik han yderligere omkring beskedfordelingen i afprøvningen. For nærmere information om RabbitMQ henvises til www.rabbitmq.com. Der var spørgsmål fra en deltager omkring indholdet af beskeden. Erik redegjorde for tre muligheder: 1. Det hele i besked (metadata + evt. fil) 2. Metadata med pegepind. En evt. fysisk fil bliver på sin oprindelige placering. 3. Metadata med pegepind. Den fysiske fil hentes efterfølgende igennem et kald. Det gav anledning til en diskussion omkring tolkning af OIO-standarden for Dokument på netop dette område. Dokument adskiller sig fra standarderne for Klassifikation, Organisation og Sag ved, at den udover metadata også skal kunne rumme håndtering af en fysisk fil. Drøftelsen gik på, om den fysiske fil medsendes i besked, blot er en henvisning via en url, eller om den er en url, og derefter hentes. IBM påpegede i den sammenhæng, at repositories kan være en god ide pga. performance. Silkeborg Data gav udtryk for, at en forståelse, hvor dokumentet ikke kan medsendes i beskeden, er en udfordring i forhold til deres måde at gøre tingene på. Silkeborg Data har ikke selv dokumentopbevaring i deres system og har ladet ESDH-systemet varetage dokumenthåndteringen. Hvis MOX betyder, at de er nødt til at have et dokumentlager for at registrere og have et sted at pege på dokumentet, er det svært at se rationalet for deres kunder. 3

Erik har efterfølgende undersøgt standarden. Specifikation af Dokument beskriver på side 21 en attribut, der benævnes Indhold. Den indeholder en pegepind (URI) til dokumentdelens binære indhold., når man læser og udfører opret, ret og import. Det binære dokument er altså ikke med i operationerne kun referencen (URI). Dermed bør beskeden om dokumentet heller ikke medsende dokumentet. Vi har valgt, at MOX-beskeder udgøres af den specifikke hændelsesbesked med hele objektet (ID, Type, livscyklus, attributter, tilstande og relationer) på et bestemt registreringstidspunkt men i alle objektets virkningsperioder. Beskeden vil blive ledsaget af generel hændelsesbeked kuverten - med transportoplysninger og oplysninger til brug for fordeling (header med keywords i AMQP-format). Nærmere om hændelsesbesked i de generelle egenskaber side 27. I forhold til registrering af dokumenter kom Erik på arbejdsgruppens vegne med en præcisering i forhold til MOX-specifikationen. Et dokument skal have en registrering ved modtagelse/oprettelse. Det kan ikke eksistere uden. Traen kom med et ønske om, at sikkerhed ikke blev skudt for længe, hvilket flere af de øvrige deltagere bakkede op omkring. I forhold til afprøvningen er sikkerhed håndteret ved, at afprøvningen foregår indenfor en afgrænset del af kommunens sikkerhedsdomæne. Det gav dog anledning til en drøftelse af de videre perspektiver i forhold til sikkerhed. KMD påpegede, at det i meget vid udstrækning er en forretningsmæssig udfordring snarere end en teknisk udfordring, i det der er forskellige udfordringer på kommunens forskellige forretningsområder. Medialogic fulgte op og påpegede, at noget af det afgørende er, hvem der kan abonnere på hvad. Flere af de deltagende leverandører, bl.a. Traen og Medialogic gav udtryk for, at den stramme tidsplan kan være et problem i forhold til deres deltagelse. Arbejdsgruppen tager det til efterretning og vil efter en efterfølgende bilateral dialog med de enkelte leverandører vurdere, om det giver anledning til, at tidsplanen må ændres. Afslutningsvis blev spørgsmålet om den videre drift og governance for MOX-konceptet drøftet. Bl.a. IBM gav udtryk for, at det kunne give god mening, at lave en driftsmodel med en central drift af konceptet. Flere af de tilstedeværende bakkede op om, at en driftsmodel med 98 forskellige instanser kunne være en udfordring. Arbejdsgruppen lyttede interesseret til alle input men påpegede, at det er beslutninger, der skal træffes i de rigtige fora efter forelæggelse for Arkitekturrådet og på baggrund af bl.a. erfaringerne fra afprøvningerne. 4

Som en opfølgning på mødet vil de deltagende leverandører blive kontaktet bilateralt af arbejdsgruppen med henblik på at følge op på interessen og forudsætningerne for at deltage i de konkrete afprøvninger. Udover indeværende referat lovede arbejdsgruppen også at fremsende et skriv, der ridser perspektiver og argumenter for deltagelse op for leverandørerne. 5