Huvudflöde

Tjänstens huvudflöde beskrivs nedan i ett aktivitetsdiagram. Detta huvudflöde innefattar användningsfall 1, 3 och 4.

Huvudflödet beskrivs av följande löptext:

1. Ett källsystem skickar en uppdatering till Engagemangsindex, vilket tas emot av Update tjänsten vilken exponeras av update-service flödet. Flödet tar emot anropet, validerar meddelandet och sparar ner detta till en process kö (Användningsfall 1).
2. Process-service flödet hämtar meddelanden från process kön, sparar/uppdaterar/tar bort poster i ei-databasen. Därefter läggs poster som skall ingå i notifiering till en prenumerant till separata notify köer per prenumerant (Användningsfall 3).
3. Varje notify-service flöde hämtar meddelanden från sin notify kö och skickar meddelandet till prenumerantens ProcessNotification tjänst (Användningsfall 4).

Användningsfall

Tjänsten uppfyller följande användningsfall för att möta de arkitekturella kraven:

Källsystem uppdaterar engagemangsindex

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

1. Då ett källsystem anropar Update tjänsten så utför engagemangsindex först basal validering (på xml schema nivå) och lägger därefter uppdateringen på en kö för bearbetning och returnerar därefter ett svar till anropande system.
2. Misslyckas valideringen returneras ett felmeddelande och uppdateringen läggs inte på kö för bearbetning.
3. Meddelandet som läggs på kön är persistent, dvs skrivs till disk, och garanterar därmed att bearbetningen kommer att utföras även om systemfel skulle uppstå, t ex systemkrasch eller omstart av server.

Federerat engagemangsindex uppdaterar engagemangsindex

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

1. Då en annan federerad engagemangsindex instans anropar ProcessNotification tjänsten så utför engagemangsindex först basal validering (på xml schema nivå) och lägger därefter uppdateringen på en kö för bearbetning och returnerar därefter ett svar till anropande system.
2. Misslyckas valideringen returneras ett felmeddelande och uppdateringen läggs inte på kö för bearbetning.
3. Meddelandet som läggs på kön är persistent, dvs skrivs till disk, och garanterar därmed att bearbetningen kommer att utföras även om systemfel skulle uppstå, t ex systemkrasch eller omstart av server.

Engagemangsindex bearbetar inkomna uppdateringar och notifieringar

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

1. Uppdateringar som lagts på kö skrivs till databasen (som nyupplägg eller uppdatering, en så kallad "upsert") samt läggs på en kö för distribution till prenumeranter.
2. Bearbetningen utförs under kontroll av en transaktion och med en retry policy i köhanteraren som vi fel backar ändringen, loggar felet samt startar om bearbetningen efter en tidsperiod.
3. Tidsperioden för nya försök kan man ställa i konfiguration men parametrar activemq.broker.maximum-redeliveries och activemq.broker.redelivery-delay.
4. Då bearbetningen använder sig av såväl en köhanterare samt en databas så använder man normalt sett en global XA transaktion för att garantera transaktionell konsistens i bearbetningen.
   För att dels slippa den prestandamässiga overheaden i en XA transaktion samt dess baksida med en inte helt oproblematisk hantering (recovery) av mer komplicerade felfall så kommer databasuppdateringen skötas av en lokal databastransaktion och köhanteringen (läs från kö och skriv till kö) i en separat kö-transaktion. Databasens transaktion kommer committas först vilket leder till att ett eventuellt fel under den mycket korta tiden mellan databas-committen och kö-committen så kommer databasen vara uppdaterad men meddelandet kommer läggas tillbaka på in-kön och inga prenumeranter kommer notifieras via kön. Vid nästa lyckade omförsök kommer prenumeranter  notifieras och meddelandet tas bort från in-kön. Databas-uppdateringen är idempotent, dvs kan göras om många gånger utan att resultatet av uppdateringen ändras, dvs informationen blir inte felaktig i databasen pga upprepade uppdateringar baserat på samma meddelande på kön.
5. Innan meddelanden läggs på en kö för distribution till prenumeranter finns det två villkor som plockar bort poster ur ett meddelande till en viss prenumerant. Det första villkoret kontrollerar om en post ej har förändrats mot den lagrade informationen i databasen, dvs om ingen förändring skett skall inte posten skickas vidare ut till en prenumerant. Det andra villkoret kontrollerar om en prenumerant har filter satta (anger vilka tjänstedomäner prenumeranten är intresserad av). Om filter finns och posten ej tillhör en tjänstedomän som prenumeranten vill få notifieringar om plockas posten bort.
   
   

Prenumerant tar emot förändringar från ett engagemangsindex

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

1. Engagemangsindex skapar en kö samt ett tillhörande flöde för varje extern prenumerant, dvs system som implementerar ProcessNotification tjänsten och som engagemangsindex har behörighet att anropa. Listan av prenumeranter får ei från TAKen (via vp OCH kat) under EI omstart. Den listan sparas i cache.
2. Meddelandet som läggs på kön är persistent, dvs skrivs till disk, och garanterar därmed att bearbetningen kommer att utföras även om systemfel skulle uppstå, t ex systemkrasch eller omstart av server..
3. När ett meddelande tas från kön av flödet görs ett anrop till prenumerantens ProcessNotification tjänst via VP mha prenumerantens logiska adress.
4. Anropet sker under kontroll av en kö-transaktion, dvs misslyckas anropet till prenumerantens ProcessNotification tjänst så loggas felet och meddelandet läggs tillbaka på kön för omförsök med samma retry policy som beskrivits ovan.
5. Varje prenumerant notifieras helt oberoende av andra prenumeranter.
6. Varje prenumerant notifieras med ett meddelande i taget i den ordning de lagts på kön. Dvs omsändning av ett visst meddelande till en viss prenumerant kommer fortgå tills det lyckas eller tas bort av en administratör. Prenumeranten i fråga kommer inte få några andra uppdateringar under tiden. Andra prenumeranter påverkas inte alls av detta utan kommer få sina uppdatering helt oberoende av att vissa prenumeranter har problem med att få sina uppdateringar.
   
   

Tjänstekonsument begär information från ett engagemangsindex

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

Då en tjänstekonsument anropar FindContent tjänsten så utför engagemangsindex en sökning i databasen via sitt interna persistenslager och returnerar resultatet av sökning i svaret till konsumenten.