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

Transkript

1 Axapoint ApS Brunhøjvej 8, st. tv DK-8680 Ry Tel CVR nr Bank: Danske Bank. MOX-review Axapoint Reviewkommentar til MOX-specifikation Version udarbejdet af It-arkitekturrådets arbejdsgruppe Titel: MOX et forretningsmønster for fagsystemers udveksling af hændelser Reviewer Axapoint ApS Michael Nielsen Partner & konsulent T E: michael@axapoint.com Indhold Kort introduktion til Axapoint og virksomhedens baggrund for reviewkommentarer Review kommentarer til MOX-specifikation Bilag til review Kort introduktion til Axapoint og virksomhedens baggrund for reviewkommentarer Axapoint ApS har som sit fulde fokus, at understøtte realiseringen af den fælles kommunale rammearkitektur. Axapoint har gennem de sidste 4-5 år fungeret som udvikler og teknisk leverandør på et kommunalt grunddatasystem, der baserer sig på Sag og Dokument standarderne i KOMBIT rammearkitekturen. Dette arbejde er startet i et samarbejde med Odense Kommune, KL og ITST, og resulterede i APOS2 systemet, der bygger på S&D-komponenterne Organisation, Klassifikation, Part og Beskedfordeler (MOX). Arbejdet og implementeringen af APOS2 blev undervejs udvidet med København, Aarhus og Ballerup kommune, der alle har APOS2 kørende i fuld drift, tilpasset den enkelte kommunes systemopbygning og organisationsbehov. Systemerne er robuste, og kører stort set uden support til driften fra Axapoint. Senest er Gribskov kommune indtrådt i APOS2 samarbejdet og en række af kommuner er i dialog om indtrædelse samt universiteter og universitetshospitaler. APOS2 er således et grunddatasystem, der kan løse en effektiv håndtering af grunddata på alle plan - kommunalt, institutionelt, regionalt, statsligt og erhvervsmæssigt. Systemet kan opbygges til at håndtere data, på alle de måder som standarden tilsiger, og kan tilpasses præcist til den enkelte kundes behov. Da APOS2 implementerer de generelle egenskaber fra standarden komplet - med fuld undestøttelse for bitemporal tid, kan kundernes ønsker understøttes på en enkelt, fleksibel og elegant vis. APOS2 systemet er opbygget på en open source platform, og har en intuitiv brugerflade, der tillader individuel kommunal profilering/branding, men har en fælles tilgang til selve brugerfladens håndtering. Dette gør tilgangen for medarbejdere ens på tværs af kommuner, og gør det nemt at udnytte nye kommunale integrationer/udvidelser i opdaterede versioner af APOS2. Brugerfladen bygger på en softwareløsning fra Axapoint, der hedder DTE - Dynamic Template Engine, der gør den utrolig fleksibel og nem at udføre rettelser og tilpasninger i. Løsningen er desuden fri af specifik serverplatforms-software. Side 1

2 En distribueret arkitektur, som defineret af KOMBITs rammearkitektur, kræver en tilsvarende fleksibel og systemuafhængig brugerflade, således at arbejdsgange og interaktioner kan foregå på tværs af systemgrænser. Dette kræver en samstillingsteknologi som DTE en, for at kunne løfte denne opgave. APOS2 arbejdet har et stærkt socialt sigte, hvor ressourcestærke kommuner kan fordele integrationsopgaver mellem sig, og varetage omkostningerne til disse, hvorefter alle kommuner princippielt kan få glæde af dette integrationsarbejde i takt med implenteringen i nye APOS2 versioner. Der er således allerede udført en lang række integrationer i kommunerne, og arbejdet med at integrere til lønsystemer, KMD-systemer (LOS) m.fl. er fordelt mellem de nuværende APOS2 kommuner - og flere integrationer er undervejs, hvor Axapoint fungerer som support til tredieparts leverandører, der ønsker at integrere til APOS2. Axapoint kan bl.a. tilbyde disse APOS2 på en hardwarebox, så andre leverandører kan udvikle og teste integrationerne op mod disse. Axapoint har opbygget en indgående viden om hvordan alle standardernes specifikationer kan realiseres, og har omsat disse til virkelige softwareløsninger, der overholder specifikationerne og fungerer. Axapoint har på nuværende tidspunkt udviklet alle rammearkitekturens støttesystemer i form af Sag og Dokument standardens komponenter - Organisation, Klassifikation, Part, Sag, Dokument, Arkiv samt Beskedfordeler (MOX), der alle er testet og operationelle i forhold til rammearkitekturens krav, og kører i kommunal drift i form af APOS2. Axapoint har opbygget en udviklingsplatform, der gør det muligt, at udvikle alle nye grunddatakomponenter inden for 1-2 uger, i takt med, at der fremadrettet foreligger specifikationer på disse. Axapoint vil fremadrettet lave korrekte og komplette implementioner af alle rammearkitektur specifikationer som offentligøres. Dette vil ske uanset om de skal implementeres i projekter, som allerede har udvalgte og financerede leverandører eller ej. Axapoint vil gøre dette, så alle APOS2 kommuner er sikret adgang til disse, med sikkerhed for funktionalitet. Axapoint vil kunne stille sådanne implementationer og test suites tilgængelige for offentlige governance myndigheder, og vil til enhver tid kunne levere løsninger, som overholder standarderne. Axapoint arbejder aktivt på, at standarden overholdes af de leverandører, som skal integrere med APOS2. Axapoint er igang med udviklingen af en open source baseret decentral serviceplatform / servicebus, der kan dække behovet hos kommunerne. Axapoint er desuden ved at afslutte et pilotprojekt med KL, hvor systemet skal anvendes til distributionen af KLE og FORM til APOS2-kommunerne. Ballerup kommune har allerede implementeret FORM i sin APOS2-løsning, og anvender koderne i deres organisation. Alle APOS2 kunder vil kunne benytte KLE, FORM og andre offentlige klassifikationer ifm. udvikling / integration til deres systemer. Disse leveres via MOX beskedfordeler og replikeringsagent. Alle S&D-komponenter samt MOXbeskedfordeler er således udviklet, og kan indgå som sikre komponenter, i det videre udviklingsarbejde hos KL og KOMBIT, hvor disse dækker eller indgår i udbud som: KOB (100%), SAPA (Dokument, Sag og Arkiv komponenterne), Serviceplatform (Dele af Part samt øvrige fremadrettede grunddata pakker). Støttesystemerne, herunder Beskedfordeler (MOX), til Ydelsessystemerne, Fagsystemerne, Fællsessystemerne, Datasystemerne og koblingen til MetaData. Fundamentet er således en realitet - baseret på standarden. Side 2

3 Review kommentarer til MOX-specifikation Generelt: Det er Axapoints erfaring, at beskedbaserede integrationer er langt bedre end traditionelle mønstre. Axapoint er derfor enig med MOX-arbejdsgruppen og ser store muligheder for at opnå robuste, genbrugelige agenter, som vil generalisere og indkapsle fagsystemerne. Mange af vores kommentarer går på følgende aspekter: 1. Der skal kun sendes OIO-data i beskederne, ikke metadata. For hvis data er nødvendig, bør dette være en del af objekterne og ikke ustruktureret ekstra data. Det er Axapoints erfaring, at der ikke er behov for metadata. Dette ud fra vores arbejde med MOX-pilot for både lønsystem integration og KLE/FORM klassifikation data replikering. 2. Alle processer skal ikke foregå vha. beskeder. Mange lokale integrationsagenter vil benytte serviceoperationerne: opret og ret for at modificere objekterne. 3. Det giver god mening med de basale agenter - repliker, læs, søg, liste, der kan benyttes som byggeklodser i de foretningsspecifikke agenter. Alle de andre agenter vil, ud fra vores erfaring, skulle designes ud fra den konkrete integration af et fagsystem. 4. Det at en agent via MOX BF kan søg, læs og liste objekter er meget vigtigt og simplificerer systemkonfigurationen. APOS2 MOX BF benytter dette, når data kommer fra et andet domæne - f.eks. når KLE-data replikeres fra KL s klassifikation til en kommune. Review af MOX-Specifikation 0.76 s.8 En besked vedrører et objekt og udtrykker en tilstandsændring for objektet. F.eks. at et dokument er registreret i en dokumentservice, som typisk er realiseret fysisk i et fagsystem. En agent er en tilføjelse til et eksisterende system og kan udføre en proces med beskeden som input. Når den har gennemført sin proces, giver den besked herom. Hvis den ikke kan gennemføre sin proces, giver den også besked. Dette er den måde som APOS og SD-Løn benytter beskeder til at initiere og angive om replikering af løn organisationen, som administreres i APOS, bliver replikeret ind i SD-Løn. Processen starter på basis af en registreringsbesked og der udsendes en statusbesked om hvad resultatet blev. Måden hvorpå status gives er ved at referer vha. UUID til det IT system og den regel/process som blev udført. Den simpleste form for regel/process er blot en beskrivelse af denne. En generel system log kan abonnere på status beskeder og derved danne overblik over rammearkitekturens komponenter og processer. Succes status beskeder kan start nye MOX processer i andre IT-Systemer. Et konkret eksempel er flyt af en enhed. Når der ikke opstår en fejl vil statusbeskeden blot have status 200. I tilfælde af fejl vil koden være specifik til og defineret for processen. F.eks. kan flyt ikke udføres, da SD-Løn ikke tillader at flytte en enhed under en enhed, som har enhedstypen: niv-0. Statusbeskeden vil, ud over status koden og fejl besked fra SD-Løn, også ref. til APOS IT-System UUID og SD-Løn UUID og hvilken regel som fejlede. Axapoint er igang med at designe en regelmotor, som APOS2 vil benytte til at validere operationer således, at fejl kan fanges inden flyt operationens registrering udføres. Dette er dog uden for scope for disse review-kommentarer. s.8: En specificeret MOX proces kan driftmæssigt afvikles i en vilkårlig agent, hvis det tilknyttede it-system, der afvikles i samme driftmiljø kan håndtere den pågældende opgave. Hvad er værdien af, at agenter skal være generiske, når det tilknyttede IT-System skal kunne afvikle en specifik opgave? Bliver den generiske skal ikke blot Beskedfordeler client API et som alle agenter benytter? Side 3

4 s.10: Det er MOX processens ansvar, at bruge startbeskedens informationer til at udføre operationen. Forventer I at MOX-beskeden indeholder alle de informationer, som kræves af agenten for at IT-Systemet kan udføre processen? Hvis ikke, hvor og hvordan skal de manglende data fremfindes? s.10: Agenten skal kunne tilføje sådanne beskedmetadata i grænselaget imellem den specifikke hændelsesbesked (den egentlige forretningshændelse) og transportlaget (adressering, protokol og wireformat) Beskrivelsen af den generelle hændelsesbesked og brugen af meta besked data skyder helt forbi målet, ud fra vores vurdering. De tekniske aspekter af hvordan besked infrastrukturen ønskes, svarer ikke til resten af dokuments scope. Axapoint vil gerne gennemgå hvordan APOS2 MOX beskedfordeler er implementeret på standard messaging AMQP protokolen. s.11: Vi forestiller os, at der er behov for flere beskedfordelere, som kan abonnere på hinandens beskeder APOS2 beskedfordeler kan være klient af en eller flere andre beskedfordelere. Dette er måden hvorpå beskeder kommer fra et domæne (KL) til et andet (BALK), og hvor f.eks. KLE automatisk opbygges som et replika. En beskedfordeler kan være direkte koblet med en anden ved at benytte en beskedrepeater-agent. Den anden er ved at benytte en replikeringsagent som i KLE piloten. Derved opstår der nye registreringer i den lokale APOS2 som bevirker at der udsendes registreringsbeskeder på dette domænes lokale MOX beskedfordeler. s.12: Det er bl.a. nærliggende at implementere konceptet på de statslige autoritative registre, som holder grunddataobjekterne Det vil være meget irationelt, hvis grunddata objekterne ikke kan udstille deres registreringer som beskeder. Axapoint har en implementering af Person på DPR, som udsteder registreringsbeskeder når persondata ændres, så som navn og adresse. s.17: Forretningsmæssigt kan det være en fordel, hvis denne delproces sker så tidligt som muligt, hvormed man kan få stillingsbetegnelser, periode osv. med i beskeden. Jeg går ud fra, at med et ansættelsesforhold mener I et engagement modeleret vha. en Organisatoriskfunktion, som udpeger virkningsperioden, enheden, stilling og andre klassifikationer. I så fald hvordan har I så tænkt jer, at stillingsbetegnelsen kommer med i beskeden? s.17: Med replikerer aktør distribueres organisationsoplysninger til de organisationsoplysninger, der abonnerer på dem. Hvorledes har I tænkt jer, at f.eks. SD Løn skal fremfinde de Person data og adresse data, der referes til i Organisation, således at SD Løn kan opbygge sin interne version af løn organisationen? Side 4

5 Og hvordan skal SD Løn modtage opdateringer af disse ikke organisation data når de ændres? s.20: Som vi så tidligere, bliver disse oplysninger replikeret til de øvrige udgaver af organisationssystemet Det vil være korrekt, at SD-Løn skaber engagement funktionen i organisation. P.t. arbejder vi med en løn organisation, hvor enhederne er tilknyttet til enheder i den administrative organisation. Der kan være enheder i løn, som ikke findes i adm. Og der vil være mange enheder i adm org. som ikke skal være i løn org. Engagementerne findes idag i adm. org. som Løn ikke kender, så det skal vi finde en løsning på. Den resterende del af dokumentet baserer sig på det samme, og det ser fornuftigt ud. Der vil ifm. poc skulle undersøges de komplekse situationer, ala den beskrevet ifm. s.20. SD og Axapoint laver en konkret beskedbaseret integration, som netop gennemgår en sådan integration i design og implementation. MOX Bilag 0.76 s.3: Organisatorisk funktion som er det objekt, der kan bruges til at beskrive den funktion, der udføres i organisationen. Udføres der ikke flere funktioner end en? s.4: Forventer I at Beskedfordeler objektet: Abonnement skal overholde de generelle egenskaber? Hvis ja, skal andre typer af data formidlere så også overholde dem: FTP, HTTP, FILER? s.6: serviceinterface gennemføre en transaktion (two-phase commit) Commit scope sammen med besked arkitektur? Dette skyder helt forkert, bør fjerens eller beskrives med konkret eksempel. s.8, Tilføjer klasseobjekt: Processen kan berige en dokument besked med relation til klassifikation En dokument besked kan ikke beriges uden data er ændret! Beskeder afspejler kerne komponenternes data, så berigelse af et dokument kan kun ske ved at en agent/bruger opdatere dokumentet med type (klasse) som derved generere en registreringsbesked. Beskeder må ikke manipuleres direkte! s.9, Tilføjer aktør: Samme som under klassifikation, beskeder må ikke manipuleres direkte. s.10, Præjournaliserer dokument Dokumentmetadata? Hvorfor inderholder objektet dokument ikke alt viden om dokumentet? Agenten skal ud fra objektet Dokument afgøre hvilke(n) regler, som kan/skal udføres på dokumentet og udsender statusbeskeder med uuid på dokumentet og reglerne. Andre agenter kan så behandle dokumentet. s.10, Sender dokument Metadata igen, er dokumentets parter ikke findes i dokument objektets data og ud fra disse sende dokumentet? s.10, Fodnote Når man laver dokumentindex, hvorfor så ikke blot benytte den fulde implementation af Dokument? APOS2 har fuld implementationer som kan være index vha. replikeringsagenter. Side 5