Prio-999: Volgordelijkheid van te versturen berichten

[JanaxLooij]

Achtergrond In de Proof-of-Concept van "De Digitale Rotonde" is een processchema "Raamwerk swimming lanes 20130504.vsd" vertaald naar een VISI-raamwerk. Met het raamwerk is het proces nagebootst, en hierbij zijn discrepanties tussen raamwerk en processchema geconstateerd.

Functionele samenvatting Functionele wens is om bij het uitvoeren van een aanvraag het processchema "Raamwerk swimming lanes 20130504.vsd" exact te volgen. In bijgevoegd document zijn zes plekken uit het processchema aangegeven die met het raamwerk uit de Proof-of-Concept niet afgedekt zijn.

Vervolgens is de scope teruggebracht tot de volgordelijkheid van te versturen berichten kunnen afdwingen. M.a.w. punten 2, 3* en 4, uit bijlage "functionele-samenvattiing-pressure-cooker-thema-workflow.pdf".

Oplossing Nadrukkelijk wordt hier niet de term “workflow” gebruikt. Een workflow of werkstroom is de logische volgorde van activiteiten die moeten worden uitgevoerd om een van te voren gedefinieerde uitkomst te verkrijgen. Deze logische volgorde wordt maar zeer beperkt vastgelegd in een VISI raamwerk. De meeste business logic ligt buiten de scope van VISI vast in de hoofden van degenen die de raamwerkrollen vervullen of in backend systemen die op een VISI node zijn aangesloten.

Doel is het inperken van mogelijke voorzettingen uitgaande van een bepaalde toestand in de berichtenflow. Er kunnen twee oorzaken worden geformuleerd waarom bepaalde voortzettingen niet aangeboden mogen worden:

Een bericht mag pas verzonden worden nadat één of meerdere specifieke berichten aanwezig zijn (reeds ontvangen of verzonden) in de transactie of zijn subtransacties, er is dus een afhankelijkheid tussen twee (of meer) al aanwezige berichten.

Een bericht dat maar één keer verzonden mag worden is reeds verzonden, er is dus een restrictie op het aantal keren dat een bericht verzonden kan worden.

Voorgestelde aanpassingen:

De bestaande klasse ”MessageInTransactionType” wordt uitgebreid met een extra relatie “conditions” van het type “OPTIONAL SET1:? OF MittCondition”; Een nieuwe klasse “MittCondition” wordt gecreëerd. Deze bepaalt het type van de set-relatie die in de hierboven genoemde “conditions” is gespecificeerd. Als er een “conditions” relatie is gespecificeerd dan moet deze set minimaal één element bevatten. Als de “conditions” set meer dan één element bevat dan worden de betrokken elementen geëvalueerd volgens tussenliggende logische EN-operatoren; Aan de klasse “MittCondition” wordt een relatie "sendAfter" toegevoegd van het type “OPTIONAL SET 1:? MessageInTransactionType”. Deze relatie is optioneel, indien aanwezig dient de set minimaal één MITT te bevatten. Indien de “sendAfter” set meer dan één MITT bevat worden de betrokken MITT's geëvalueerd volgens tussenliggende logische OF-operatoren; Aan de klasse “MittCondition” wordt een relatie "sendBefore" toegevoegd van het type “OPTIONAL SET 1:? MessageInTransactionType”. Deze relatie is optioneel, indien aanwezig dient de set minimaal één MITT te bevatten. Indien de “sendAfter” set meer dan één MITT bevat worden de betrokken MITT's geëvalueerd volgens tussenliggende logische OF-operatoren; Toegestane verwijzingen bij "sendAfter" en "sendBefore "zijn “MessageInTransactionType’s” die ontvangen kunnen worden in de actuele transactie of van een van zijn subtransacties. Indien de "MittCondition" zowel één of meerdere "sendBefore" als één of meerdere "sendAfter" bevat worden deze sets geëvalueerd volgens een logische OF-operator.

Het effect om een bericht slechts één keer te mogen versturen wordt bereikt door de MiTT van het betreffende bericht in de sendBefore lijst van diezelfde MITT te plaatsen. In dit specifieke geval mag een bericht dus niet naar meerdere executors worden verzonden.

-- toevoeging op bestaande klasse ENTITY MessageInTransactionType; …. conditions : OPTIONAL SET[1:?] OF MessageInTransactionTypeCondition; -- AND END_ENTITY;

-- nieuwe klasse ENTITY MessageInTransactionTypeCondition; sendAfter : OPTIONAL SET [1:?] MessageInTransactionType; -- OR sendBefore : OPTIONAL SET [1:?] MessageInTransactionType; -- OR END_ENTITY;

Backwards compatibiliteit Voor backward comptabiliteit is de “conditions” relatie optioneel: zonder deze relatie is de afhandeling van het VISI berichtenverkeer gelijk aan die van de vigerende VISI systematiek 1.3.

Acties

Tekst hierboven reviseren aan de hand van bijgevoegde e-mail (GS - gedaan) Express files uitbreiden 2.exp en 3.xsd (JvdB - gedaan) Leidraad aanpassen: (GS - gedaan) Richtlijn bijlage "Volgordelijkheid" op wiki in codeplex aanmaken en kijken hoe dit te exporteren is voor publicatie (GS - gedaan); Testraamwerk oberkok uitbreiden plus testscenario (AB - gedaan) Afbeelding van raamwerk in testscenario. groene T4 uitbreiden met extra blokje Keukenhulp, met 4 lijntjes voor de nieuwe berichten. Met wolkjes de verschillende Messageintransactiontypeconditions benoemen. (JvG - gedaan)

Attachments

Raamwerk swimming lanes 20130504.pdf Digitale Rotonde model_V3.1.xml functionele-samenvattiing-pressure-cooker-thema-workflow.pdf 2013-06-04-1708-e-mail-Arne.pdf _7_metvolgordelijkheid.zip

This work item was migrated from CodePlex

CodePlex work item ID: '1025' Assigned to: 'Arne_Bruinse' Vote count: '1'

[JanaxLooij]

[jvgeijlswijk@7-6-2013] Arne Bruinse schreef op di 04-06-2013 17:08 bijgevoegde e-mail.

[JanaxLooij]

[UnknownUser@7-6-2013]

[JanaxLooij]

[UnknownUser@11-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[gspees@19-9-2013] Dit issue is verwerkt als bijlage bij de leidraad. Daarbij zijn tekstuele aanpassingen gedaan ten opzichte van dit issue. Inhoudelijk zijn er geen aanpassingen

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[UnknownUser@19-9-2013]

[JanaxLooij]

[gspees@20-9-2013] Link naar Leidraad

[JanaxLooij]

[Arne_Bruinse@24-10-2013] Bij het uitwerken van het testscript, zie ik nog wel een gebrek aan de huidige uitwerking: De regel: "Toegestane verwijzingen bij "sendAfter" en "sendBefore "zijn “MessageInTransactionType’s” die ontvangen kunnen worden in de actuele transactie of van een van zijn subtransacties."

geeft problemen, want de bovenliggende transactie waaruit de actuele transactie gestart is, moet ook meegenomen worden, zeker omdat sommige berichten juist weer terugkeren naar deze transactie en er dus naar verwezen moet kunnen worden. Mijn voorstel is om deze tekst aan te passen naar:

"Toegestane verwijzingen bij "sendAfter" en "sendBefore "zijn “MessageInTransactionType’s” die ontvangen of verzonden kunnen worden in de actuele transactie, in een van zijn subtransacties of in de transactie waaruit de actuele transactie geïnitieerd is."

Graag 25-10 bespreken en de tekst aanpassen als iedereen akkoord is.

[JanaxLooij]

[Arne_Bruinse@24-10-2013] Andere vraag: Moet hieronder niet MessageInTransactionTypeRef gebruikt worden?

ENTITY MittCondition; sendAfter : OPTIONAL SET [1:?] MessageInTransactionType; -- OR sendBefore : OPTIONAL SET [1:?] MessageInTransactionType; -- OR END_ENTITY;

[JanaxLooij]

[Arne_Bruinse@24-10-2013] In dezelfde lijn: Moet het hier niet MittConditionRef zijn?

ENTITY MessageInTransactionType; …. conditions : OPTIONAL SET[1:?] OF MittCondition; -- AND END_ENTITY;

[JanaxLooij]

[Arne_Bruinse@24-10-2013] Voor de testcase is _7 uitgebreid, 25-10 nog doorspreken en dan officieel opnemen in 1.4 als testraamwerk. Bovenstaande "ref" vragen al zo verwerkt in raamwerk, en ook verwezen naar MItt's uit transactie waaruit de actuele transactie geïnitieerd is, dus op dat punt moet nog de beschrijving aangepast worden.

Testcase: De vraagtransactie T4 tussen kok en keukenhulp bevatte nog een probleem, wat ik hier meteen mee opgelost heb. Het probleem van deze transactie was, dat er geen eindbericht bestond. Deze transactie kon dus nooit afgesloten worden, waardoor dit impliceerde voor VISI ontwikkelaars, dat deze afgesloten moet worden zodra de ober het antwoord doorzette naar de kok. Dit mag alleen niet, want op de server van de kok is de transactie dan afgesloten , maar op de server van de keukenhulp staat de transactie nog steeds open. Voor de testcase heb ik dus eindberichten voor T4 gemaakt. Op het moment dat de keukenhulp een antwoord geeft, kan de kok kiezen uit het doorsturen naar de kok, maar nu ook uit een bericht dat het antwoord van de keukenhulp niet gebruikt wordt. De kok kan daarna bijvoorbeeld een andere keukenhulp aanschrijven zonder dat de transactie met de eerst aangeschreven keukenhulp open blijft staan. Zodra de kok een antwoord naar de ober stuurt, kan de kok opeens niet meer melden dat het antwoord niet is overgenomen, maar staat er een bericht klaar, waar in de bericht naam al staat wat er gedaan is met het antwoord.

In testcase vorm kun je dit bijvoorbeeld als volgt noteren:

• keukenhulp stuurt een antwoord. De kok moet nu kunnen kiezen uit de volgende opties:
  • als het op basis van een vraag van de ober was kan hij kiezen uit:
  • het antwoord doorsturen naar de ober
  • melden dat het antwoord niet gebruikt wordt
  • Als het op basis van een bestelling van de ober was, kan hij kiezen uit:
  • Een Akkoord of niet akkoord bericht naar de ober
  • melden dat het antwoord niet gebruikt wordt
• zodra de kok een antwoord naar de ober verzonden heeft, kan hij iedere keer nog maar 1 afsluitend bericht naar de keukenhulp sturen. Dit bericht correspondeert met het bericht dat naar de ober ging.

[JanaxLooij]

[Arne_Bruinse@24-10-2013] Aanvulling op testscenario: Om naast het voorwaardelijk aanbieden van antwoorden in een lopende transactie, ook het starten van een nieuwe subtransactie te testen in combinatie met het bijzondere voorbeeld dat een transactie maar een keer gestart mag worden, is er ook een beperking gesteld dat het bericht "Bestelling" maar een keer naar de kok gestuurd mag worden.

Testcase: De ober stuurt de bestelling naar de kok. Controleer dat de ober niet nog een nieuwe bestellingssubtransactie mag starten.

[JanaxLooij]

[UnknownUser@24-10-2013]

[JanaxLooij]

[Arne_Bruinse@24-10-2013] Zie bijgevoegde zip met aangepast testraamwerk en xsd. op 25-10 gezamenlijk de inhoud doorlopen en controleren. Daarna projecttype en dergelijke goedzetten en opnemen in codeplex als nieuwe versie voor 1.4

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[jvgeijlswijk@25-9-2014] Uit overleg met Arne Bruinse is het voorstel gekomen om de tekst op pagina "https://visi.codeplex.com/wikipage?title=Volgordelijkheid%20van%20berichten&referringTitle=Leidraad%20VISI-systematiek" aan te passen tot: “Toegestane verwijzingen bij "sendAfter" en "sendBefore "zijn “MessageInTransactionType’s” die ontvangen kunnen worden in de actuele transactie of van de aangesloten transacties, waarbij de persoon die het actuele bericht behandelt initiator of executor is. Met aangesloten transacties worden de transactie waaruit een transactie geïnitieerd is en de directe subtransacties bedoeld. Met directe subtransacties worden transacties bedoeld die vanuit de actuele transactie geïnitieerd zijn, dus niet subtransacties van subtransacties.“

[JanaxLooij]

[UnknownUser@10-7-2015]

[JanaxLooij]

[UnknownUser@10-7-2015]