JanaxLooij
commented
6 years ago [jvgeijlswijk@7-6-2013] Tijdens dag vier (24-05-2013) van de Pressure Cooker (De Digitale Rotonde) is het volgende geconcludeerd: Het issue wordt voor nu geschrapt als blocking issue, omdat de oplossing voor dit issue al in de huidige VISI-standaard besloten ligt (namelijk het invoeren van loops). Aan de technische commissie van VISI wordt doorgegeven dat aan de bestaande wens van de gebruikers van VISI om correcties mogelijk te maken het mogelijk moet zijn om de correcties expliciet aan/uit te zetten.
Achtergrond In de Proof-of-Concept van "De Digitale Rotonde" is naar voren gekomen dat het voorkomen van het versturen van een inhoudelijk onvolledig bericht onmogelijk is, en dat in een inhoudelijke correctie alleen voorzien kan worden in het raamwerk (middels "controle-loops"). Bijvoorbeeld: een persoon kan voor de combinatie van straatnaam en huisnummer een niet bestaande combinatie opgeven, zoals straatnaam=Kalverstraat, huisnummer=999.
Het inbouwen van "controle-loops" in het raamwerk wordt door "De Digitale Rotonde" niet beschouwd als een passende oplossing, want het inbouwen van extra loops zorgt voor een minder lean raamwerk.
"De Digitale Rotonde" heeft behoefte aan het ondersteunen van de volgende scenario’s: een verstuurd bericht intrekken, verwijderen of corrigeren.
In december 2013 en januari 2014 is hier door Niek Pluijmert vanuit de DEMO gemeenschap het volledige transactie patroon, of "Universal transaction pattern" ingebracht. Hierin zitten met name de "cancellation patterns" die slaan op dit issue. In de TC werksessie van 20 juni 2014 kwam Jos Hamilton afzonderlijk ook met dit schema als voorwaarde om een dergelijke uitbreiding als acceptabel te kunnen zien.
Functionele samenvatting Functionele wens is een verzonden bericht A (waarvoor nog geen opvolgend bericht is verstuurd) terug te kunnen draaien op 1) initiatief van verzender (met akkoord van ontvanger) of 2) op initiatief van ontvanger (met akkoord van verzender), waarbij de situatie voor verzending van bericht A bereikt wordt, maar waarbij wel verzonden bericht A alsmede de communicatie over het terugdraaien traceerbaar en eenduidig vastgelegd zijn.
Mogelijke problemen bij een rollback
Volgnummers. Als wijziging 1 t/m 10 zijn verzonden en 5 wordt via een rollback terug geroepen, komt dit nummer dan weer vrij zodat de nieuwste wijziging nummer 5 krijgt?
Doorsturen d.m.v. gekoppelde transacties, zelf subtransacties maken of zelfs koppelingen in sap en andere systemen. Andere systemen kunnen niet altijd berichten intrekken. Als er al gekoppelde transacties verzonden zijn moeten deze eerst ingetrokken worden.
Aandachtspunten 2 vormen van rollback:
het verzoek om het laatste bericht terug te trekken
het verzoek om een hele transacties te cancelen
Vragen bij rollback van een bericht:
wat doe je als na een rollback verzoek er alweer een nieuw bericht is verzonden. Of geen verzending toestaan zolang de rollback pending is.
Geen verzending toestaan is lastig. Als een verzoek intrekken wat vertraging heeft om op de andere server te komen kan op de andere server ondertussen al een bericht verzonden zijn.
als de rollback wordt toegestaan wat doe je met de communicatie over de rollback en het teruggedraaide bericht. Mooiste is als dit toch ergens zichtbaar blijft
In outlook zie je dan een streep door de berichtregel, maar dit zou aan de leverancier zijn om streep of kleur of iets anders te kiezen. Wel moet het terug te vinden zijn omdat dit ook communicatie is.
Vragen bij rollback/cancelation van de transactie
wat doe je met de transactie, blijft deze toch zichtbaar? als gesloten transactie?
Hetzelfde als wanneer je alle berichten afzonderlijk cancelled.
Motivatie voor verdere uitwerking Voor de 1.4 versie van de standaard was besloten dat de technische oplossing voor dit issue besloten ligt in de huidige VISI-standaard , namelijk het invoeren van "loops" in een VISI-raamwerk. Derhalve hoeft de VISI Standaard niet aangepast te worden.
Voor de 1.5 versie wordt dit item toch weer opgepakt, om een onnodige hoeveelheid loops in raamwerken tegen te gaan en om met VISI weer veel dichter bij de DEMO systematiek te komen. Met loops kan bijvoorbeeld niet een "revoke acceptance" geregeld worden, omdat de transactie dan gesloten dient te worden.
De oplossing volgens DEMO In tegenstelling tot de eerdere uitwerking, wordt de definitie van deze oplossing nu, overeenkomstig met de DEMO "cancellation patterns" (zie bijgevoegde powerpoint en afbeeldingen)
De verzender van het laatste bericht in een transactie kan een extra bericht achter dit bericht aansturen, met de vraag om het bericht terug te trekken. In demo terminologie zou dit "revoke message" heten.
De ontvanger van het laatste bericht ontvangt dan het revoke-verzoek en kan antwoorden met een refuse of een allow-bericht. Zijn eerdere eventuele reactie mogelijkheden zijn dan geblokkeerd en worden pas weer aangeboden als hij voor een refuse kiest. Bij allow wordt het bericht door de visi software als vervallen maar wel leesbaar gemarkeerd. De verzender van het teruggetrokken bericht is in dat geval weer aan zet om het zelfde bericht aangepast, of een ander bericht ervoor in de plaats op te sturen.
De volledige "Quit" en "Stop" uit het standaard demo transaction pattern vallen niet verder onder deze oplossing, omdat die reeds ondersteund worden in de huidige visi systematiek. Deze berichten heten bijvoorbeeld "Intrekking" of "Definitieve afkeuring", enz. Deze zijn nu qua bericht volgorde al precies volgens de demo transaction patterns in te bouwen en worden al zo gebruikt.
Regels bij terugtrekken van berichten
Volgnummers: De transactie volgnummers uit de systematiek gelden voor de gehele transactie, terugtrekken van het eerste bericht in de transactie en vervolgens een nieuwe eerste bericht in die transactie leidt dan niet tot een nieuwe volgnummer. Dus in de fase dat er wel een terugtrekking is maar nog geen nieuw bericht blijft het transactie volgnummer dus intact en mag niet voor nieuwe transacties worden uitgegeven.
Risico's en vragen
Adressering van de hierboven genoemde risico's en benoemde vraagstukken:
BESPREKEN WANT GEEN SYSTEMATIEK? Software volgnummers die niet hard in de systematiek zijn opgenomen maar wel door leveranciers worden ondersteunt, staat hier de werkafspraak dat een eenmaal uitgegeven nummer uitgegeven moet blijven. Dus ook al wordt het eerste bericht van een transactie waarin volgnummer 5 staat ingetrokken, dit nummer mag voor de traceerbaarheid niet opnieuw uitgegeven worden. een volgend bericht krijgt dan bijvoorbeeld nummer 6.
Reeds doorgestuurde berichten: Besproken tijdens de werksessie van 20-6-2014 en overeengekomen is, dat eventuele terugkeer vanuit de subtransactie niet meer mogelijk mag zijn nadat het bericht waaruit de subtransacties gestart zijn teruggetrokken is. Het is aan de initiator van de subtransacties of die deze door laat lopen of daar ook met revoke of quit en stop berichten die processen stop zet.
Wat doe je als het reactie/opvolgende bericht op het terug te trekken bericht al onderweg was? Zodra een server die een revoke verzonden heeft en de normale reactie ontvangt, wordt de revoke als "refused" beschouwd. Mocht men dan toch dit bericht willen revoken, zal dan eerst de revoke van het nieuwe bericht uitgevoerd moeten worden.
Wat te doen met de zichtbaarheid van de revoke berichten en het terug getrokken bericht? De weergave ligt bij de verschillende leveranciers, maar de berichten moeten toonbaar en traceerbaar zijn. Dus de revoke berichten moeten als normale visi berichten in de transactie in het archief terecht komen.
cancellation patterns verwerken in metaraamwerk of in het gewone raamwerk?
......verder all vragen hierboven benoemen en uitwerken
Acties:
input van standaard demo patroon ("revoke") verwerken in een aangepast voorstel (actie: Arne); ... word document met voorbeelden opnieuw maken duidelijk de 3 speciale berichten in metaraamwerk verder uitwerken/benoemen
Attachments
Uitwerking rollback.docx volledig transactiepatroon.jpg standard transaction pattern.jpg VISI systematiek versie 1_5 Revocation v0.3.pdf
This work item was migrated from CodePlex
CodePlex work item ID: '955' Vote count: '1'