Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bataller García Eric Create_CancelledWorkflowStepFromInstruction added #3195

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Bataller García Eric Create_CancelledWorkflowStepFromInstruction added #3195

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8e1e786
Create_CancelledWorkflowStepFromInstruction added
ebataller Oct 22, 2024
86372a5
Updated description
ebataller Nov 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions rosetta-source/src/main/rosetta/event-workflow-func.rosetta
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -145,6 +145,38 @@ func Create_AcceptedWorkflowStepFromInstruction: <"Represents the acceptance of
add acceptedWorkflowStep -> account:
acceptedWorkflowStep -> businessEvent -> after -> trade -> account distinct

func Create_CancelledWorkflowStepFromInstruction: <"Represents the cancellation of a proposed instruction that results in a workflow step containing a business event, message details, identifiers, event timestamps, parties and accounts. The previous workflow step input must exist to provide workflow lineage.">
[creation WorkflowStep]
inputs:
proposedWorkflowStep WorkflowStep (1..1)
output:
cancelledWorkflowStep WorkflowStep (1..1)

condition ProposedEventExists: <"The previous step being cancelled must be a proposed step containing an instruction.">
proposedWorkflowStep -> proposedEvent exists

condition CancelledProposedStep: <"The previous step must be a cancel">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really the previous step? If we're checking our input, "proposedWorkflowStep", then its the instruction and not the previous step, is that correct?
Would the comments thus be better if they said something like "Check the instruction has a proposed event..." and "... is set as a Cancel..."?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Chris, sorry for the late response. Your description change looks fine to me, it makes this clearer. I will recontribute the changes.

proposedWorkflowStep -> action = ActionEnum -> Cancel

condition RejectedProposedStep: <"The previous step cannot be rejected.">
proposedWorkflowStep -> rejected <> True

set cancelledWorkflowStep -> action: proposedWorkflowStep -> action
set cancelledWorkflowStep -> messageInformation: proposedWorkflowStep -> messageInformation
add cancelledWorkflowStep -> timestamp: proposedWorkflowStep -> timestamp
add cancelledWorkflowStep -> eventIdentifier: proposedWorkflowStep -> eventIdentifier
set cancelledWorkflowStep -> previousWorkflowStep: proposedWorkflowStep -> previousWorkflowStep as-key

set cancelledWorkflowStep -> businessEvent: <"Assign the business event corresponding to the workflow step.">
Create_BusinessEvent(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're cancelling a WorkflowStep, and the WorkflowStep has a proposedEvent in it, as confirmed in an earlier condition, why are we now creating a BusinessEvent? Isn't a BusinessEvent only created as a result of an accepted WorkflowStep?

Here you're checking for the existence of a proposedEvent which implies that the workflow has not completed successfully and there should be no BusinessEvent at this point?

If there is a businessEvent on the WorkflowStep already then I can see the logic in including it on the cancelledWorkflowStep, but I can't see why we would want to create a new BusinessEvent for a cancelled WorkflowStep.

Can you give a bit more detail please in case I am missing something.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, the proposal is fulfilling the requirement to represent that the previous step was accepted by mistake. We use it as previous state to propose a new instruction, in which the cancellation flag is set and it's executed through the proposed function.

Requirement in DRR was to be able to represent an ERROR on previously submitted states.

proposedWorkflowStep -> proposedEvent -> instruction,
proposedWorkflowStep -> proposedEvent -> intent,
proposedWorkflowStep -> proposedEvent -> eventDate,
proposedWorkflowStep -> proposedEvent -> effectiveDate )

add cancelledWorkflowStep -> party: cancelledWorkflowStep -> businessEvent -> after -> trade -> party distinct
add cancelledWorkflowStep -> account: cancelledWorkflowStep -> businessEvent -> after -> trade -> account distinct

func Create_ProposedWorkflowStep: <"Represents the proposal to create a business event that results in a workflow step containing an instruction, message details, identifiers, event timestamps, parties and accounts. The optional previous workflow step input provides workflow lineage to where there has been a correction or cancellation to the proposed step. The action is constrained so that when a previous workflow step is specified, the valid actions are as follows; New -> Correct and Correct -> Cancel. When a previous workflow is not specified, the action must be New.">
[creation WorkflowStep]
inputs:
Expand Down
Loading