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:
- Create Query Object
Omvandlar inkommande tjänstespecifika anrop och skapar ett generiskt Query Object som resten av tjänsten använder sig av. - Request List Transformer
Filtrerar och omvandlar svar från sökning i Engagemangs Index (via tjänsten findContent()) till anrop till underliggande källsystem via för tjänsten specifika tjänstekontrakt - Response List Transformer
Sätter samman ett tjänstespecifikt aggregerat svar baserat på delsvaren som returnerats från källsystemen.
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.
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.
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.
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.
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
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.
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.
