...
- 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.
- 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.
- 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.
- 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. - 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
...
- 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.
- 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.
- När en "durable subscriber" tar emot en notifiering internt anropar den prenumerantens ProcessNotification tjänst via VP mha prenumerantens logiska adress.
- 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.
- Varje prenumerant notifieras helt oberoende av andra prenumeranter.
- 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
...