Sidjämförelse

Mule flödena är implementerade mha Mule Studio och återges nedan som skärmdumpar från verktyget.

Tillgång till källkoden

Se Instruktioner för utvecklare.

aggregating-service

aggregating-service är en generisk mönster-implementation av en aggregerande tjänst i aggregeringsplattformen. Den kan anpassas för specifika aggregerande tjänsters behovs på tre ställen:

...

Implementationen är uppdelad i följande Mule flöden:

• cache-flow
• main-flow
• request-reply-flow
• splitter-flow
• worker-flow
• aggregation-flow

cache-flow

• Exponerar HTTP endpunkt för den aggregerande tjänsten.
• Sätter kommunikationsheadrar enligt krav från RIV-TA och VP.
• Anropar tjänstespecifik "Create Query Object" implementation för att läsa ut information från inkommande request. 
• Delegerar till bearbetningen till main-flow.

Note: Anledningen till såväl namnsättning på detta flöde samt delegeringen till ett main-flow är att det är i detta flöde tidigare innehöll en numer borttagen cachningsfunktion. 

Image Removed

main-flow

• Preparerar ett anrop till EI's FindContent tjänst inklusive properagering av kommunikationsheadrar.
• Anropar EI EI's FindContent tjänst mah en Message Enhancer.
• Anropar tjänstespecifik "Request List Transformation" implementation för att skapa en lista med de anrop som skall göras till underliggande tjänsteproducenter. 
• Delegerar bearbetningen till request-reply-flow.
• I hanteringen av svaret, dvs i ett response-element, anropas en tjänstespecifik "Response List Transformation" implementation för att skapa det slutgiltiga aggregerade svaret baserat på de olika svar som kommit från de underliggande tjänsteproducenterna. 
•  

Image Removed

request-reply-flow

• Ansvarar för att brygga mellan den ytter synkrona bearbetningen i cache-flow och main-flow till den asynkrona och parallella bearbetningen i splitter-flow, worker-flow och aggregation-flow
• Skickar listan på request till vm-kön "splitter" och väntar synkront på ett asynkront aggregerat svar på vm-kön "reply".
• Timeout på väntan på svar styrs av parametern AGGREGATED_SERVICE_TIMEOUT_MS.

Image Removed

splitter-flow

• Använder en collection-splitter för att dela upp listan med request till separata request.
• Märker meddelanden med ett korrelerings-id.
• Lägger på en reply-to header som anger vm-kön "aggregate" dit svaren skickas för aggregering.

Image Removed

worker-flow

• Sätter upp kommunikationsheadrar enligt RIV-TA och anropar de utpekade tjänsteproducenterna via VP.
• Svar skickas mha reply-to-headern satt ovan till vm-kön "aggregate"
• Kommunikationsfel och timeout fångas upp per anrop av exception-handlern "Catch Exception Strategy" och fel-information skickas till vm-kön "aggregate" så att felet kan rapporteras enligt RIV-TA i processingStatus headern.

• Timeout på väntan på svar från tjänsteproducenten styrs av parametern SERVICE_TIMEOUT_MS

Image Removed

aggregation-flow

• Använder en collection-aggregator för att samla in de parallellt framställda svaren till en aggregerat svar.
• När alla svaren kommit eller timeout som styrs av parametern AGGREGATE_TIMEOUT_MS inträffar så skickas det sammansatta svar som samlats in så långt till vm-kön "reply", dvs till request-reply-flodet beskrivet ovan.

Image Removed

reset-tak-cache-http-flow

• Ingår i en separat xml-konfig-fil, TakCache-services.xml, för att kunna aktiveras vid behov
• Definierar också spring-bönan takCacheBean  som används för att läsa information från TAK.

Image Removed

reset-tak-cache-http-flow

Konfiguration av följande mekanismer är av central betydelse för att en aggregerande tjänst skall fungera bra i en produktionsmiljö med både hög last och där fel inträffar pga kommunikationsproblem och/eller långa

Konfiguration

Konfiguration av följande mekanismer är av central betydelse för att en aggregerande tjänst skall fungera bra i en produktionsmiljö med både hög last och där fel inträffar pga kommunikationsproblem och/eller långa svarstider.

Timeouter

För att den timeout-hanteringen skall fungera och den aggregerande tjänsten skall kunna ge så meningsfull felinformation som möjlig tillbaka till anropande tjänsteproducent vid timeout-relaterade fel så är det viktigt att: 

AGGREGATED_SERVICE_TIMEOUT_MS > AGGREGATE_TIMEOUT_MS > SERVICE_TIMEOUT_MS

<default-threading-profile poolExhaustedAction="ABORT" maxThreadsActive="${AGP_DEFAULT_MAX_THREADS_ACTIVE}" maxThreadsIdle="${AGP_DEFAULT_MAX_THREADS_IDLE}" threadTTL="${AGP_DEFAULT_MAX_THREADS_TTL}"/>

Tjänstespecifika implementationer

De tjänstespecifika implementationerna konfigerars enligt nedanstående exempel:

...

Produktval

Som ramverk för aggregeringsplattformen har Spring Boot + Apache-Camel valts.
Apache-Camel är ett moget ramverk med stöd för de funktioner som krävs för att realisera en aggregeringsplattform.

Apache-Camel är öppen källkod som distribueras under Apache 2.0 license.

Struktur

Implementationen är uppdelad i:

• Aggregeringsplattformen - Körbar applikation som innehåller huvud funktionalitet samt laddar in tjänsteimplementationer.
• Tjänsteimplementationer - Pluginer till aggregeringplattformen som innehåller tjänstespecifika konfigureringar och funktionalitet.

Aggregeringsplattformen laddar in alla tjänsteimplementationer som den hittar i sin classpath.

Struktur aggregeringsplattformen

Aggregeringsplattformen är uppdelad i ett antal java moduler:

• agp-application - Implementation av den körbara aggregeringsplattformen. 
• agp-core - Innehåller de inteface som tjänsteimplementationerna måste implementera samt hjälpfunktioner.
• agp-schemas - Innehåller de scheman aggregeringsplattformen behöver för att anropa EI och TAK.
• agp-test-core - Gemmensam testfunktionalitet
• agp-test-service - En test implementation av en tjänst för integrationtester.
• agp-test-stub - En bas för stubbning av EI, TAK samt för tjänster.

Struktur tjänsteimplementation

En tjänsteimplementation behöver:

• Innehålla wsdl:er för den specifika tjänsten
• Implementera interfacet AgpServiceConfiguration för den tjänstespecifika konfigureringen
• Implementera interfacet AgpServiceFactory för den tjänstespecifika funktionaliteten.

Källkod

Se AgP - Instruktioner för utvecklare

Exceptions

Fel från producenter rapporteras i  SOAP headern "ProcessingStatus" men skapar inga interna exceptions eller SoapFaults. 

Interna fel som kastar exceptions eller fel mot EI/FindContent genererar ett SoapFualt tillbaka till anropande konsument.

Monitorering

Statustjänst 

AGP exponerar en status-tjänst som returnerar information om plattformen. Genom anrop av denna tjänst kan man på ett enkelt sätt kontrollera att aggregeringsplattformen är igång och vilka tjänster den laddat in.
Se: AGP - Status tjänst

Hawtio

Hawtio använd för monitorering och som "manager" verktyg.

Det finns möjlighet att ändra loggnivåer under drift, få systeminformation som processorutnyttjande, minne, diskutrymme, javaversion, java classpath, threads etc.

Loggning

För loggning används log4j2. Meddelanden genom plattformen loggas i ett format som gör det enkelt att ta in och monitorera med Kibana.
Se: AGP - Loggning

TAK cache

VP har sin egen kopia av TAK data i en cache implementerad i en fristående komponent https://github.com/skltp/takcache som innehåller vägval och anropsbehörigeter.

Denna används för:

• Kontrollera att det finns ett vägval till producenten och att konsumenten har behörighet för denna. Se Arkitektuella krav #8. 

Man kan göra en uppdatering av TAK cache komponenten via ett REST anrop.