Användningsfall

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

1. Källsystem uppdaterar engagemangsindex

2. Engagemangsindex hämtar uppdateringar från ett källsystem
   (som alternativ till att källsystemet initierar uppdateringar)

3. Federerat engagemangsindex uppdaterar engagemangsindex

4. Engagemangsindex bearbetar inkomna uppdateringar och notifieringar
5. Prenumerant tar emot förändringar från ett engagemangsindex
6. Tjänstekonsument begär information från ett engagemangsindex

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.

Engagemangsindex hämtar uppdateringar från ett källsystem

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

1. Som ett alternativ till att källsystem själva skickar in uppdateringar till engagemangsindex så kan engagemangsindex istället periodiskt anropa en tjänst, GetUpdates, som källsystemet tillhandahåller.
2. Svar från GetUpdate tjänsten kommer först genomgå basal validering (på xml schema nivå) och därefter lägger engagemangsindex uppdateringen på en kö för bearbetning.
3. Misslyckas valideringen loggas ett felmeddelande och uppdateringen läggs inte på kö för bearbetning.
4. 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 publiceras på en topic 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 ökar med antalet omförsök för ett visst meddelande så att ett tillfälligt fel inte fördröjer en uppdatering onödigt länge men ett varigt fel å andra sidan inte medför en hög belastning på systemet drivet av täta omförsök som kontinuerligt misslyckas.
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 topic) 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 topicen. 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.

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

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

1. Engagemangsindex registerar en så kallad "durable subscriber" på den interna topicen för varje extern prenumerant, dvs system som implementerar ProcessNotification tjänsten och som engagemangsindex har behörighet att anropa.
2. En "durable subscriber" garanterar att ingen informationsspridning tappas bort internt i engagemangsindex vid en ev. systemkrasch eller tillfälligt fel i en eller flera subscribers.
3. När en "durable subscriber" tar emot en notifiering internt anropar den 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å topicen 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 publicerats på topicen. 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.