Do DEMO with VISI 1.X

[JanaxLooij]

How and what can we do with VISI 1.6 to cover the universal transaction pattern of DEMO 3?

[DEFAULT PATTERN] Solution: A VISI transaction has fixed pattern.

The default pattern has an addition message (MITT) Request because one Request has NO previous (=start message), and the other Request has Decline as previous. N.B. Also sub transactions use the default pattern, and have two MITTs to represent the starting messagetype (1. MITT without previous from other main transaction and property firstMessage=true, 2. MITT with previous DECLINE from sub transaction).

initiator = INITIATOR and does Request and Accept executor = EXECUTOR and does Promise and State

A transaction is never finished (because of RevokeAccept).

For a message is defined if the message is active / inactive (with property state).

[PHASE] The use of TransactionPhase for MITT is mandatory, and has predefined values (REQUESTED, PROMISED, STATED, ACCEPTED, QUITTED, DECLINED, REJECTED, STOPPED).

ACCEPTED DECLINED

[REVOKE] How to add revoke to VISI? Solution 1: Model revoke as separate default revoke transactions (=4 transactions)

use property initiatingmessageID to connect a seperate revoke transaction with a previous transaction set startmessage = false create 4 separate transactions do it according to DEMO 3 revoke transactions always apply to all transactions (no on / off options) a revoke message has always the same properties / fields

6 messagetypes (MT_Revoke_Accept, MT_Revoke_Promise, MT_Revoke_Request, MT_Revoke_State, MT_Allow, MT_Refuse)

Solutions 2: Model revoke as 'normal' sub transactions

use property initiatingmessageID to connect a sub transaction with a previous transaction startmessage = false

initiator is NOT the one to send a message (for example RevokeAccept after an Accept)

RevokePromise goes back to 1) choose Promise / Decline or 2) Decline. UPDATE 11-10-2017: Discussed with Janax, Jeroen and Ge and according to DEMO documentation of default transaction pattern an "Allow" of "Revoke Promise" results is two options: choose Decline / Promise

[State after Promise by executor, how?] a) MITT conditions for STATED b) with TransactionPhase = PROMISED executor stays the actor of the transaction

[SUB TRANSACTIONS] Use MITTConditions for in case of multiple sub transactions to determine the order of execution sub transactions (first sub transaction "Advise", then sub transaction "Approve", not the other way around).

Only jump into sub transaction from main transaction when phase is REQUESTED, PROMISED, STATED, ACCEPTED.

Use one generic empty dummy messagetype to configure in the framework if a step of the default transaction pattern is skipped. Set the property "state" of this dummy messagetype to "passive".

no request passive no promise passive

[DEMO or VISI framework] From the framework it should be recognisable if all transactions are VISI or DEMO. Decided on 2017-09-08 by Jeroen, Janax, Gé: bij adding /DEMO to the 1.6 VISI namespace the framework will be recognisable as a DEMO framework. When there will by a 1.7 (or higher namespace) the DEMO framework will be recognisable by the slash DEMO addition_

[VISI is ASYNCHRONE and DEMO assumes all data is available] Crossing messages: Revoke has a higher priority than other messages to be executed. Priority when two Revokes cross each other: First RevokeAccept, then RevokeState, RevokePromise, RevokeRequest The last Revoke that is replied with Allow determines the phase of the transaction.

[Revokes & sub transactions] How to revoke a main transaction when several sub transactions are started? Solution: If property opensecondarytransactionsallow=false and sub transactions are open, then main transaction is NOT allowed to be revoked. If property opensecondarytranasactionsallow=true and sub transactions are open, then main transaction is allowed to be revoked. Sub transactions stay open, but can optionally be revoked by sending RevokeRequest.

[DEFAULT PATTERN & sub transactions] Going in and out of sub transactions must be conform the default transaction pattern phases For example: from main transaction (=STATED) -> in sub transaction -> out sub transaction to main (=STATED) -> two options: Accept or Reject

[DEMO has mandatory sub transactions] How to do it in VISI? Possible with SendBefore / SendAfter conditions, or by simply continuing into a sub transaction

[In VISI main and sub transactions need to be cascade, in DEMO not] In DEMO cascading is not mandatory (because of Quit and Stop). DEMO transactions can be linked as a chain of transactions. Discuss on 08-09-2017 by Ge, Janax and Jeroen that requirement about cascading can be dropped with the introduction of the rule that after a Quit or Stop of a sub transaction the flow returns to the main transaction. The position in the main transaction can be derived from the transaction phase, because there is a default transaction pattern with default phases.

[Fact Bank] VISI doesn't have a Fact Bank. Reasons:

Every instance of a TransactionType can be initiated by a different organisation; Coordination and Production Facts between organisations can only be transferred digitally; Organisations cannot access each others Fact Banks;

Dependant (sub-) transactions can be initiated by other organisations.

Solution: Every transaction contains the Coordination and Production Facts that are necessary for that particular transaction; Coordination and Production Fact can only be transferred in a VISI transaction / message;

Facts from main transaction need to be transferred to dependant (sub) transactions if those particular sub transactions need that information

GS: TOT HIER ALLES VERWERKT IN DOCUMENTATIE

[Translation of VISI framework to DEMO framework] N.B. in DEMO only one message state is possible, in VISI several messages state are possible and needed, because the content of the message differs (for instance state paying with cash, state paying with plastic).

example from framework UAV One (1) MMW transaction in VISI results... solution A:

Four (4) DEMO transactions about "afwijking" (T1a Gemeld, T1b Geoffreerd, T1c Uitgevoerd, T1d Betaalbaargesteld, T1e Betaald) connected as sub transactions solution B: Four (4) times the DEMO pattern in one (1) VISI transaction solution C:

completely separate transactions in framework but use initiationMessageInTransaction to connect then when sending messages :-(

[Questions]

Is according to DEMO jumping into a sub transaction also viable from the states DECLINED, QUITTED, REJECTED, STOPPED? Or is this only viable for the main states REQUESTED, PROMISED, STATED, ACCEPTED? UPDATE 13-10-2017:

Is it necessary to send implicit messages?

[Actions]

add mapping from VISI to DEMO messages for framework OBER-KOK and mark implicit messages (state=passive), and make flowcharts for example by show them grayed out (owner: Janax) map a VISI main and sub transaction to get a mandaat to DEMO (because sub transaction will not be mapped as request-state, but as ...-accept/reject) (owner: Janax). map a VISI transaction to give information ("melding") to DEMO (because it's only a state) (owner: Janax). document (in English) the translation of main VISI transaction "wijziging" (UAV) from ON to OG (with sub transactions) to a several DEMO transactions (owner: Janax, Jeroen, Ge) make functional documentation in Dutch (on top of VISI 1.6 documentation) which explains to stakeholders (product owner, end users, consultants, etc.) how to use VISI 1.6 to make DEMO-like frameworks (owner: Ge) upgrade the above short technical description to full blown technical document (in English) (owner: Jeroen). translate functional documentation and add it to technical documentation. include to the documentation as an appendix the transformation of a VISI transaction "wijziging" to DEMO transactions

Attachments

20170802-flipover-1.jpg 20170802-flipover-2.jpg 20170802-flipover-3.jpg 20170802-flipover-4.jpg 20170802-flipover-5.jpg DEMO_patroon_in_VISI.jpg DEMO_patroon_in_VISI_kort.jpg DEMO_voorbeeld_met_revoke_subtransacties_v1.xml OCD_OberKok_v1.jpg PSD_OberKok_v1.jpg OCD_Pizzeria_v1.jpg PSD_Pizzeria_v1.jpg DEMO_voorbeeld_met_revoke_subtransacties_v2.xml DEMO VISI Pizzeria_1.xml Ober Kok 1.6_2.xml DEMO_met_VISI_16_werksessie_2017-10-11.rar

This work item was migrated from CodePlex

CodePlex work item ID: '4789' Vote count: '1'

[JanaxLooij]

[JanaxLooij@23-8-2017] Voorbeeld van het DEMO standaard transactiepatroon in VISI 1.6 (zonder revokes)

[JanaxLooij]

[gspees@8-9-2017] Raamwerk Ober Kok vertaalt naar DEMO-VISI transacties

[ArneBruinse]

EC 3 nov 23: ops knop / fout herstellen geeft een te lichtvoetig karakter. Met VISI zul je nu eenmaal altijd formeel je bericht terug moeten vragen, dus zal er een formele revoke pattern doorlopen moeten worden.

[ArneBruinse]

voorstel is voor een 1.x versie om de officieuze "1.6 DEMO oplegger" definitef in de systematiek op te nemen.

[tessaderoos]

EC/GC 05-02-2024: "Implementatie DEMO op VISI software. DEMO oplegger is al verwerkt in 1.7 oplegger als documentatie. Er moet nog uitgezocht worden wat dit betekent voor de VISI systemen. --> Promise en Revoke mogelijk maken binnen VISI"