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. Dokument oversigt: APOS2 Bulk data import / export APOS2 Security APOS2 Installation, Operation and Monitoring APOS2 Service Catalogue APOS2 Data Models APOS2 Administration Guide Alle dokumenterne kan findes på: http://axapoint.com/ Versioner Version 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. 1.2.1 07/03/2013 Tilføjet eksempel med Advisér MOX agent, tilføjet parametre forklaring. Tabel 1: Dokument historik 2
Indhold 1 Synopsis 4 2 Beskedfordeling 5 2.1 Exchanges konfiguration............................ 5 2.2 Exchange headers................................ 5 2.3 Rækkefølge af beskeder............................. 6 2.4 Garanti for leverance.............................. 6 2.5 Besked indhold................................. 6 3 Sikkerhed 7 3.1 SSL....................................... 7 4 APOS2 MOX Client 7 5 MOX Agenter 8 5.1 Template MOX Agent............................. 8 5.2 Advisér MOX Agent.............................. 10 5.3 Callback MOX Agent............................. 11 5.4 Eksempel MOX Agent............................. 11 3
1 Synopsis APOS2 er en implementation af Sag & Dokument standarderne for Organisation, Part og Klassifikation. Ændringer i objekterne indholdt i APOS2 skaber beskeder fra registreringer der kan fordeles ved hjælp af MOX konceptet. Den underliggende infrastruktur implementeres af RabbitMQ, som er en open source server der implementerer AMQP standarden. Dokumentet er tænkt læst af IT arkitekter og tekniske anvendere af APOS2 MOX. Første del beskriver overordnet sammenhæng og anvendelse mens sidste del af dokumentet tackler de mere konkrete problemstillinger med eksempler og dybdegående forklaring. 4
2 Beskedfordeling beskedfordelingen foregår via et setup af exchanges og queues. APOS2 standard konfiguration er at opsætte en headers exchange. For mere info om exchanges og queues, se http://www.rabbitmq.com/tutorials/amqpconcepts.html Både publisher og consumer kender til exchange opsætningen hvilket betyder at de kan declare publisher eller consumer queues i uvilkårlig rækkefølge. 2.1 Exchanges konfiguration Til hvert miljø oprettes der en exchange på RabbitMQ serveren med tilhørende navn. For hvér applikation der publisher eller consumer oprettes en queue, det giver følgende konfiguration til miljøet test. Exhange name Queue name test-app-organisation test-app-klassifikation test-app-part test-composite-services test-oio-organisation test-oio-klassifikation test-oio-part Tabel 2: Eksempel på deklarationer af queues Ved at alle publishers har en queue til samme exchange skal en consumer blot lave en queue til den exchange for at lytte på alle beskeder. Der er mulighed for at kunne filtrere beskeder på nogle overordnede attributter i headers for at lave en grov sortering. 2.2 Exchange headers Headers, der kan filtreres på, fremgår af nedenstående tabel. APOS2 default konfiguration matcher på headers med x-match=any. Det betyder at hvis headers er sat matcher den hvis blot den ene attribut matcher. Axapoint tilbyder en MOX client der er prekonfigureret til opsætning af exchanges. Exchanges er default durable hvilket vil sige at de persistereres ved server genstart. 5
Header domain rid uuid type livscyklus Beskrivelse hvilket domain entitetens type tilhører, kan være Organisation, Klassifikation eller Part id på registrerings objektet entitetens uuid entitetens type, eks. Klasse, OrganisationFunktion, Bruger osv. livscyklus på registering, kan være OPRETTET, RETTET, PASSIVERET, IMPORTERET, SLETTET Tabel 3: Headers der kan filtreres på 2.3 Rækkefølge af beskeder Beskederne bliver sendt til consumer i samme rækkefølge som de blev sendt fra publisher. Er der flere consumers på samme queue, så bliver de default fordelt med round-robin. 2.4 Garanti for leverance Beskeder sendt til serveren gemmes til disk i RabbitMQ s egen database som default. Læs mere på RabbitMQ s hjemmeside. http://www.rabbitmq.com/semantics.html 2.5 Besked indhold Beskeder indeholder registreringen på objektet. Det vil sige alle ændringer foretaget som en del af registreringen. Herunder er et eksempel på en registreringsbesked hvor en OrganisationEnhed er flyttet, dvs. overordnet relation er ændret. <?xml version="1.0" encoding="utf-8"?> <orgenhed:registreringbesked xmlns:orgenhed="urn:oio:sagdok:organisation:orgenhed:2.0.0" xmlns:orgfaelles="urn:oio:sagdok:organisation:2.0.0" xmlns:sd="urn:oio: <orgenhed:objektid> <sd:urnidentifikator>organisationenhed</sd:urnidentifikator> <sd:uuididentifikator>2bbc4d40-8ff0-4e24-9472-71ed8948ec2f</sd:uuididentifikator> </orgenhed:objektid> <orgenhed:registrering> <sd:fratidspunkt> <sd:tidsstempeldatotid>2012-11-26t17:17:57.000+01:00</sd:tidsstempeldatotid> </sd:fratidspunkt> <sd:livscykluskode>rettet</sd:livscykluskode> <sd:brugerref> <sd:uuididentifikator>00000000-0000-0000-0000-000000000000</sd:uuididentifikator> </sd:brugerref> <orgenhed:attributliste> </orgenhed:attributliste> <orgenhed:tilstandliste> </orgenhed:tilstandliste> <orgenhed:relationliste> <sd:overordnet> <sd:virkning> <sd:fratidspunkt> 6
<sd:tidsstempeldatotid>2012-11-21t12:59:59.000+01:00</sd:tidsstempeldatotid> </sd:fratidspunkt> <sd:tiltidspunkt> <sd:tidsstempeldatotid>2012-11-25t12:59:59.000+01:00</sd:tidsstempeldatotid> </sd:tiltidspunkt> <sd:aktoerref> <sd:uuididentifikator>00000000-0000-0000-0000-000000000000</sd:uuididentifikator> </sd:aktoerref> <sd:aktoertypekode>bruger</sd:aktoertypekode> </sd:virkning> <sd:referenceid> <sd:uuididentifikator>f63df5b4-620c-4d64-8953-00b6b67d3417</sd:uuididentifikator> </sd:referenceid> </sd:overordnet> <sd:overordnet> <sd:virkning> <sd:fratidspunkt> <sd:tidsstempeldatotid>2012-11-25t12:59:59.000+01:00</sd:tidsstempeldatotid> </sd:fratidspunkt> <sd:tiltidspunkt> <sd:tidsstempeldatotid>3197-09-14t02:00:00.000+02:00</sd:tidsstempeldatotid> </sd:tiltidspunkt> <sd:aktoerref> <sd:uuididentifikator>00000000-0000-0000-0000-000000000000</sd:uuididentifikator> </sd:aktoerref> <sd:aktoertypekode>bruger</sd:aktoertypekode> </sd:virkning> <sd:referenceid> <sd:uuididentifikator>32fdbabf-5610-4010-9344-514cd8550cc8</sd:uuididentifikator> </sd:referenceid> </sd:overordnet> </orgenhed:relationliste> </orgenhed:registrering> </orgenhed:registreringbesked> 3 Sikkerhed Beskeder fra APOS er databærende med indhold som for eksempel CPR nummer, hvorfor en krypteret forbindelse er nødvendig. 3.1 SSL APOS2 tilbyder en nem opsætning med certifikater via SSL. Axapoint anvender OpenS- SL og kan udstede certifikater eller kan anvende certifikater efter integrerende parts ønske. Der vil være krav om certifikat på RabbitMQ instanser der er tilgængelige udenfor firewalls. Internt kan der efter kundens ønske blot laves encryption via SSL. 4 APOS2 MOX Client Axapoint stiller en MOX client til rådighed for integrerende parter. Denne kræver minimum Java SE 5. Andre dependencies fremgår af tabellen. Trust via SSL certifikat konfigureres med en KeyStore i Java. 7
Dependency Version log4j 1.2.16 rabbitmq AMQP client 2.8.4 Tabel 4: MOX Client dependencies 5 MOX Agenter Til at automatisere processer kan man med fordel lave et lille program der lytter på beskeder og reagerer på dem ud fra indholdet. Disse programmer kan holdes meget små, men kan have en stor effekt. Fordelen ved at dsitribuere arbejdsopgaver til mindre agenter, er at man holder en arkitektur der er fleksibel, uden at skulle programmere mere kompleksitet end nødvendigt ind i de enkelte fag- og støttesystemer. I de følgende afsnit er beskrevet eksisterende MOX Agent integrationer. 5.1 Template MOX Agent En kunde har behov for at nye organisatioriske enheder altid skal have en personale leder funktion. Den funktionalitet er implementeret via en MOX Agent, som lytter på beskeder og reagerer, når beskeden fortæller om en nyoprettet enhed. Den kalder herefter APOS2, og sørger for at oprette de ønskede lederfunktioner, på den nyoprettede enhed. Dette vil tage ganske få millisekunder, den eneste begrænsning er netværk. Se figur 1. Figur 1: MOX Template Agent sequence. 8
mqserver.queuename lederbetegnelsebvn lederansvarbvn Agent kø navn Brugervendtnøgle på klasse til betegnelse på lederfunktion skabelon Brugervendtnøgle på klasse til ansvar på lederfunktion skabelon Tabel 5: Parametre på template agent 9
5.2 Advisér MOX Agent En kunde har behov for at give besked til ledere med specifikt ansvar for en afdeling når en ny medarbejder ansættes, flyttes dertil eller opsiges. MOX agenten konfigureres med 2 forskellige leder ansvar. Det ene ansvar er for den leder der kun skal have besked ved en nyansættelse, den anden er for lederen der skal have besked i alle tilfælde. Når en ansættelse flyttes meddeles det til lederen af den afdeling der flyttes til. Eksempel på ansættelse ses af figur 2. Email en indeholder en beskrivende tekst af hændelsen med dybe links ind i APOS2 admin grænsefladen. Figur 2: MOX Adviser Agent sequence. 10
mqserver.queuename AdviserPrimaerBetegnelseBVN AdviserSekundaerBetegnelseBVN EmailBVN SMTPConn Agent kø navn Brugervendtnøgle på klasse der angiver primær ansvar Til sekundært ansvar Brugervendt nøgle på klasse anvendt til email kontaktkanal connection string til SMTP server Tabel 6: Parametre på email agent 5.3 Callback MOX Agent En kunde har et behov for at få opdateret AD realtime når der sker ændringer i organisationen. De har et system der sørger for opdateringen fra APOS2 til AD, men dette system kan ikke tale OIO, og kan ikke lytte efter MOX beskeder. For at overholde den løse arkitektur er der implementeret en MOX Agent, der fortolker på beskeder, og fortæller det integrerende system, at der er en ændring. MOX Agenten kommunikerer med det integrerende system via systemets egne eksisterende API er. Mønstreret og agenten kan anvendes til at migrere gradvist mod en løsere koblet arkitektur uden at kræve implementation af nye interfaces i eksisterende systemer. mqserver.queuename RESTCallbackURL Agent kø navn URL beskeder videresendes til Tabel 7: Parametre på callback agent 5.4 Eksempel MOX Agent Axapoint kan pakke en dummy agent til hurtig ibrugtagning for integrerende partnere. Udover krav til selve klienten kræver denne minimun Servlet api 2.4, som er tilgængligt i J2EE 1.4 og senere. mqserver.queuename Agent kø navn Tabel 8: Parametre på Agent 11