Implementatie: Afsluiten van transactie

[edelater]

Dit issue is onderdeel van een serie issues waar Future Insight tegenaan liep tijdens implementatie van VISI.

afsluiten van een transactie:

• wanneer is een transactie klaar/afgesloten?

• met name onduidelijk als een partij in een subtransactie zit, maar geen weet heeft van de hoofdtransactie.

  Een voorbeeld:

• RolB, RolC en RolD zitten in systeemX
• RolA zit in systeemY

• T1 kan onstaan als subtransactie uit diverse transacties; bijv. T0, T2 en T3.

  1. T0 RolD stuurt Bericht0 naar RolB                               - OG ==> OG: vraag
  2.   T1 RolB stuurt Bericht1 (op basis van Bericht0) naar RolA     - OG ==> ON: vraag
  3.   T1 RolA stuurt Bericht2 naar RolB                             - ON ==> OG: antwoord
  4.     T2 RolB stuurt Bericht3 (op basis van Bericht2) naar RolC   - OG ==> OG: vraag om advies
  5.     T2 RolC stuurt Bericht4 naar RolB                           - OG ==> OG: advies
  6.   T1 RolB stuurt Bericht5 (n.a.v. Bericht4) naar RolA           - OG ==> ON: acceptatie antwoord
  7.   T1 RolA stuurt Bericht6 naar RolB                             - ON ==> OG: acceptatie antwoord akkoord
  8. T0 RolB stuurt Bericht7 (n.a.v. Bericht6) naar RolD             - OG ==> OG: antwoord

De vraag is: waarom zou RolA transactie T1 niet als afgesloten beschouwen na stap 3, maar wel als afgesloten beschouwen na stap 7. In beide gevallen is er namelijk alleen nog een volgend bericht in een andere transactie?

RolA heeft geen weet van T0 of T2. Het enige dat RolA weet is dat hij in een subtransactie zit (hij heeft namelijk weet van het initiatingTransactionMessageID), maar niet welke transactie/welk type transactie.

[ArneBruinse]

@edelater ik heb vrijdagmiddag afgesproken vandaag antwoord te geven op jouw vraag.

Een transactie is afgesloten, zodra het laatste bericht geen vervolg antwoorden meer mogelijk heeft, ook niet midddels de terugkeer uit de mogelijk uit te zetten subtransacties op basis van het laatste bericht.

Want je hebt gelijk: wat er op een andere server gebeurt weet die transactie niet en kan dus nooit van invloed zijn op de transactie zelf. Het is daarmee dus wel een raamwerk fout als je een subtransactie hebt, waarmee je zowel terug kunt keren als niet terug kunt keren in de transactie, want bij een uitkomst zonder terug keren zal de transactie oneindig open blijven staan.

In jouw voorbeeld weet de software dus middels het raamwerk dat er via T2 een route terug naar T1 gaat (Bericht 5/stap6 van T1 dat geen firstmessage is, heeft namelijk bericht 4/stap5 uit T2 als previous staan in het raamwerk). Dus de transactie moet open blijven staan na verzenden van bericht 2/stap3.

Is dit helder genoeg om deze vraag af te kunnen sluiten @edelater of denk je dat deze uitleg ergens in de documentatie nog mist? Want dan moeten we deze de volgende keer verder oppakken, om te identificeren waar en hoe we dit in de documentatie moeten krijgen. NB: @ElisabethKloren is het eigenlijk nog de bedoeling dat de huidige documentatie nog gecorrigeerd wordt, of zit dat in die kostenpost van 35k dit jaar om de documentatie helemaal opnieuw te schrijven? in dat geval dient deze US missschien alleen ter controle van die nieuwe documentatie?