Deployment vy

Innehåll:

Deploy komponenter

Engagemangsindex består av följande komponenter som skall driftsättas:

1. Applikation
2. Köhanterare
3. Databas

Dessa beskrivs var för sig ur ett driftsättningsperspektiv nedan.

Applikationen

För att möjliggöra att engagemangsindex kontinuerligt kan ta emot uppdateringar från källsystem samt andra federerade engagemangsindex instanser så är applikationen uppdelad i två delar:

1. frontend-app
   Tar emot uppdateringar och lägger på kö för bearbetning, behöver ej tillgång till databas.
   
   
2. backend-app
   Bearbetar meddelanden från kön, uppdaterar databasen samt notifierar prenumeranter. Tillhandahåller också sökfunktionen mot databasen.
   
   

Denna uppdelning medför att engagemangsindex kan ta emot uppdateringar även om backend-app'en och/eller databasen är nere (planerat eller oplanerat).
Applikationen är baserad på Mule ESB.

Se instruktioner för driftspersonal och support för detaljer om hur applikationen skall konfigureras och övervakas.

Köhanterare

Engagemangsindex använder Apache ActiveMQ som JMS kompatibel köhanterare och förlitar sig dessutom på funktioner i ActiveMQ som inte specificeras av JMS såsom funktionalitet för hög tillgänglighet och omsändningspolicies.

Se instruktioner för driftspersonal och support för detaljer om hur ActiveMQ skall konfigureras och övervakas.

Not: ActiveMQ kan i princip ersättas med valfri JMS kompatibel köhanterare så länge som köhanteraren har motsvarande egenskaper som ActiveMQ för funktioner som inte täcks in av JMS specifikationen, t ex hög tillgänglighet och omsändningspolicies.

Databas

Engagemangsindex använder MySQL som JDBC kompatibel databas och förlitar sig dessutom på funktioner i MySQL som inte specificeras av JDBC såsom funktionalitet för hög tillgänglighet.

Se instruktioner för driftspersonal och support för detaljer om hur MySQL skall konfigureras och övervakas.

Not: Applikationen använder ramverket spring-data och JPA 2.0 för att förenkla byte av databas och därmed är SKLTP's engagemangsindex implementation väl förberedd för att fungera ihop med valfri JDBC kompatibel databas såsom Microsofts SQL Server, IBM DB2, Oracle eller PostgreSQL.

Övervakning

Processer som behöver övervakas:

1. Mule ESB, t ex minne och cpu
2. ActiveMQ, t ex ködjup och ålder på meddelanden
3. MySQL, t ex diskutnyttjande, cpu och minne

Externa RIV-TA Web Service enpunkter beskrivna i den logiska vyn (= enpunkter som passerar den "gröna" gränslinjen för EI i bilden på sidan logisk vy) behöver också övervakas.
Detta görs lämpligen genom att dess PingForConfiguration-tjänst anropas med lämpliga intervall.

Interna JMS endpunkter behöver övervakas enligt följande:

1. JMS Process Queue (skltp.ei.update)
   Blir det meddelande liggandes här indikerar det att EI's backend applikation inte är igång eller inte kommer åt sin databas.
   Vid ett misslyckat försöka att bearbeta ett meddelanden på kön kommer ett felmeddelande skickas till ERROR-LOG kön och som i sin tur ger upphov till ett larm.

2. JMS Notification Queues (EI.NOTIFICATION.<logisk adress prenumerant>)
   På dessa köer sparas uppdateringar som skall skickas till EI's prenumeranter. Blir det meddelande liggandes här indikerar det en prenumerant inte svarar.
   Vid ett misslyckat försöka att bearbeta ett meddelanden på kön kommer ett felmeddelande skickas till ERROR-LOG kön och som i sin tur ger upphov till ett larm.
   
   

För detaljer om hur övervakning sätts upp se instruktioner för drift och övervakning av SKLTP EI.

Typfall av konfigurationer

Engagemangsindex kan konfigureras för att möte en rad olika behov, allt från enklast möjliga single-server lösning till uppskalade cluster-lösningar. Engagemangsindex kan användas ihop med övriga delar av SKLTP men också som en fristående komponent utan närvaro av övriga komponenter i SKLTP.

Engagemangsindex är primärt tänkt att driftsättas på en Mule instans, antingen Mule CE eller Mule EE, men kan också driftsättas i en enkel web-server som stöttar WAR-fil koncepter från Java EE, t ex Tomcat eller Jetty.

Nedan beskrivs några typfall av konfigurationer:

Single-server

Enklast möjliga lösning med alla SKLTP komponenter inklusive köhanterare och databas i en och samma server. Typiskt tillämpbart för mindre installationer såsom i en mindre kommun eller för utvärdering/test/utbildning.

Multi-server med hög tillgänglighet

I en uppskalad och verksamhetskritisk tillämpning är det viktigt att enskilda fel (t ex att en server kraschar) inte påverkar tillgängligheten av engagemangsindex. För att undvika det måste man dubblera (eller mer) alla komponenter. Applikationen exekverar typiskt på ett antal parallella aktiva servrar och en lastdelare ställs framför för att fördela inkommande trafik. Köhanterare och databas konfigureras också, baserat på respektive produkt egenskaper, för hög tillgänglighet. För ActiveMQ och MySQL används master/slave konfigurationer för att erhålla hög tillgänglighet.

HA, skalbarhet, master/slave AMQ och DB

I en uppskalad tillämpning kan engagemangsindex exekvera på separata servrar

Multi-server med hög tillgänglighet i dedikerade servrar

Om lasten på engagemangsindex når upp till väldigt höga nivåer kan man behöva dedikerade servrar för att bara exekvera engagemangsindex.