...
- Integrationslager
Hanterar all extern och intern kommunikation inklusive hantering av transaktioner, loggning fel och omsändning.
Detta lager har beroenden till Mule CE som ESB och 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.
Implementations källkodstruktur följer VGR's referensarkitektur inom ramen för Öppna Program (http://http://vastra-gotalandsregionen.github.io/oppna-program/:
Följande bild återger källkostrukturen ner på Maven modul och därmed Eclipse projekt nivåMavenmodulnivå:
Foldrarna innehåller följande projekt:
applicationsmule-backend-app
Applikation avsedd att driftsättas på en Mule instansskltp-ei-application
Spring Boot-applikation för att köra front- och backend som en kombinerad tjänstskltp-ei-backendSpring Boot-applikation med alla komponenter förutom update-service och notification-service som som ligger i frontend app'enmule-frontend-app
Applikation avsedd att driftsättas på en Mule instansskltp-ei-common
Innehålller kod som delas mellan frontend och backendskltp-ei-data-model
Innehåller källkoden för persistenslagret.skltp-ei-frontendSpring Boot-applikation med komponenterna update-service och notification-service.
Not: Så länge frontend -appen är uppe så kan EI ta emot uppdateringar även om backend -appen och dess databas är nere för t ex underhåll.compositesschemaskltp-ei-schemasInnehåller de tjänstekontrakt som implementationen exponerar och/eller konsumerar.svc
Innehåller källkoden för verksamhetslagret samt persistenslagret.modulesintsvc
Innehåller källkoden för integrationslagret.
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
...
Tabellen ser ut enligt:
engagement_index_table
| Kolumnnamn | Null | Primär- nyckel | Del av logisk- nyckel | Typ och Längd |
|---|---|---|---|---|
| id | Nej | X |
| Varchar(64) | ||
registered_resident_id | Nej |
| X | Varchar(32) | |
service_domain | Nej |
| X | Varchar(255) | |
categorization | Nej |
| X | Varchar(255) | ||
logical_address | Nej |
| X | Varchar(64) | ||
business_object_instance_id | Nej |
| X | Varchar(128) | ||
source_system | Nej |
| X | Varchar(64) | ||
data_controller | Nej |
| X | Varchar(64) | |
owner | Nej |
| X | Varchar(64) | ||
clinical_process_interest_id | Nej |
| X | Varchar(128) | ||
creation_time | Nej |
| Timestamp | ||
update_time | Ja |
| Timestamp | ||
most_recent_content | Ja |
| Timestamp |
Förutom primärnyckeln som är id så finns ett sökindex med namnet engagement_search_index.
...
- 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
...