SKLTP EI SAD - Implementationsvy

Innehåll:

Tillgång till källkoden

Se Instruktioner för utvecklare.

Översikt

Implementationen av engagemangsindex följer en traditionell lagerindelning:

• Integrationslager
  Hanterar all extern och intern kommunikation inklusive hantering av transaktioner, loggning fel och omsändning.
  Detta lager använder Apache Camel, och ansluter till Apache ActiveMQ som JMS provider.
  
  
• Verksamhetslager
  Innehåller regelverk som följer regler i tjänstekontraktet för engagemangsindex.
  Detta lager är implementerat som rena Java klasser (POJO's) och använder Spring Framework för att hantering av beroenden i runtime (DI).
  
  
• Persistenslager
  Hanterar lagring och sökning av engagemangsindex-information i databasen.
  Detta lager är beroende av JPA 2.0 samt Spring Data. För lokala tester används en HSQL in-memory databas och för externa tester används MySQL.
  Persistenslagret kan konfigureras för att använda andra databaser som MS SQL Server, IBM D2 eller Oracle.

Följande bild återger källkostrukturen ner på Mavenmodulnivå:

Foldrarna innehåller följande projekt:

• skltp-ei-application
  Spring Boot-applikation för att köra front- och backend som en kombinerad tjänst
• skltp-ei-backend
Spring Boot-applikation med alla komponenter förutom update-service och notification-service som som ligger i frontend
• skltp-ei-common
  Innehålller kod som delas mellan frontend och backend
• skltp-ei-data-model
  Innehåller källkoden för persistenslagret.
• skltp-ei-frontend
Spring Boot-applikation med komponenterna update-service och notification-service.
  Not: Så länge frontend är uppe så kan EI ta emot uppdateringar även om backend och dess databas är nere för t ex underhåll.
• skltp-ei-schemas
Innehåller de tjänstekontrakt som implementationen exponerar och/eller konsumerar.

• skltp-ei-teststub
  Stubbar för att underlätta testning

Följande modell beskriver de mest centrala källkodsartefakterna samt var de finns placerade i källkodsträdet:

Persistenslager

Detta lager är baserat på JPA 2.0 samt Spring Data och Hibernate. För lokala tester används en HSQL in-memory databas och för externa tester används MySQL.
Persistenslagret kan konfigureras för att använda andra databaser som MS SQL Server, IBM D2 eller Oracle, men har endast verifierats med MySQL.

Mappning till tabell

Databasstrukturen är enkel med en enda huvudtabell där nästan hela posten är en primärnyckel och den information som uppdateras är endast två datumfält.

Tabellen ser ut enligt:

engagement_index_table

Förutom primärnyckeln som är id så finns ett sökindex med namnet engagement_search_index.

Primärnyckel

I enlighet med specifikationen är den unika verksamhetsnyckeln ganska komplex och är just nu (RC8) baserad på nio fält, och för att underlätta databashanteringen har en teknisk primärnyckel valts där den denna härleds utifrån verksamhetsnyckeln. Den valda algoritmen för att skapa denna unika nyckel är SHA-2 eller mer exakt SHA-256, och resultatet är en 32 bytes array som sedan konverteras till en 64 teckens sträng på hexadecimalt format. I teorin kan duplikat uppstå, men i praktiken har ingen funnit några duplikat vid användning av denna algoritm, se även http://en.wikipedia.org/wiki/SHA-2.

Observera att användningen av en teknisk primärnyckel inte förändrar det faktum att man inte under några omständigheter kan ändra på någon del av verksamhetsnyckeln, dvs. utifrån detta perspektiv är det exakt samma hantering som om verksamhetsnyckeln hade används som primärnyckel. Därför har varje fält som ingår i verksamhetsnyckeln markerats med en JPA indikator om att fältet ifråga inte ska uppdateras.

Tidstämpel

Det finns 3 fält av typen tidstämpel, och två av dessa creation_time och update_time hanteras till fullo av persistenslagret. För att update_time ska ändras måste posten ändras och detta görs endast när värdet på most_recent_content ändras.

Sökningar

För sökningar används springs JPA repository interface, där sökningar definieras antingen med namnkonvention eller med SQL (JPQL) satser. För närvarande krävs fälten registered_resident_id och service_domain för sökningar i enlighet med findContent meddelandet, och detta skiljer sig från den nuvarande specifikationen (RC10).

Om tidstämpel är angiven (most_recent_content) så returneras alla poster som har ett värde som är större eller lika med detta. För samtliga övriga fält måste värdena vara exakt lika.

Transaktioner

Precis som förespråkas i tjänstekontraktsbeskrivningen så krävs ingen särskild transaktionskonsistens när man läser data, dvs. man tillåter så kallade "dirty reads" om nu den underliggande databasen tillåter detta. Självfallet måste alla skrivningar hanteras på ett atomärt och konsistent sätt, även om man tillåter sk. "dirty reads".

Portering av databas

Nuvarande implementation har endast verifierats med MySQL 5 databas och då med InnoDB som transaktionsmotor (engine). Det finns ett antal punkter som man bör reflektera över när det gäller portering till andra databaser:

• Vid sökning av flera poster med hjälp av primärnyckeln används en "IN" sats och vissa databaser kan kan ha begränsningar med avseende på batch-storleken för denna typ av anrop
• Längden på några av kolumnerna kan möjligen överskrida någon begränsning
• Det kan finnas effektivare sätt att lagra informationen på, dvs. sökindex och tabelldata kan mycket väl slås ihop för denna typ av data. I MySQL fallet lagras tabell och index var för sig.
• Det kan finnas effektivare sätt att indexera på då den primära nyckeln passar utmärkt för ett "hash" index. MySQL och InnoDB är begränsat till B-Tree