FINXIS.

WorkflowStep

Type CDM 7.2.0

A workflow step represents the state of a business event. The workflow step contains a reference to a previous WorkflowStep in order to preserve lineage. A workflow step is accepted if it contains a business event, proposed if proposedEvent is present and is rejected if the rejected flag is set.

Extends —
Extended by —
Attributes 15
Namespace cdm.event.workflow

Attributes

All 15 declared on WorkflowStep. Cardinality in amber is required.

NameTypeCard.Description
businessEvent BusinessEvent 0..1 Life cycle event for the step.
counterpartyPositionBusinessEvent CounterpartyPositionBusinessEvent 0..1 Documents the life cycle event for a position.
proposedEvent EventInstruction 0..1 The proposed event for a workflow step.
rejected boolean 0..1 Flags this step as rejected.
approval WorkflowStepApproval 0..* Optional party approvals for the current workflow step. A workflow step can have any number of parties associated to it, thus this object is represented as a list. All parties that are expected to provide approval should have an item in this list that references them.
previousWorkflowStep WorkflowStep 0..1 Optional previous workflow step that provides lineage to workflow steps that precedes it.
nextEvent EventInstruction 0..1 The intended next event can be specified, even if the instructions are not known yet.
messageInformation MessageInformation 0..1 Contains all information pertaining the FpML messaging header
timestamp EventTimestamp 1..* The set of timestamp(s) associated with the event as a collection of [dateTime, qualifier].
eventIdentifier Identifier 1..* The identifier(s) that uniquely identify a lifecycle event. The unbounded cardinality is meant to provide the ability to associate identifiers that are issued by distinct parties. As an example, each of the parties to the event may choose to associate their own identifiers to the event.
action ActionEnum 0..1 Specifies whether the event is a new, a correction or a cancellation.
party Party 0..* The specification of the event parties. This attribute is optional, as not applicable to certain events (e.g. most of the observations).
account Account 0..* Optional account information that could be associated to the event.
creditLimitInformation CreditLimitInformation 0..1 —
workflowState WorkflowState 0..1 The event workflow information, i.e. the workflow status, the associated comment and the partyCustomisedWorkflow which purpose is to provide the ability to associate custom workflow information to the CDM.

Conditions

Validation rules the model enforces on this type, in Rune. An instance that breaks one of these is invalid CDM, whatever produced it.

WorkflowStepStatus Condition
(businessEvent exists and nextEvent -> instruction is absent and rejected is absent)
    or (nextEvent -> instruction exists and businessEvent is absent and rejected is absent)
    or (rejected exists and businessEvent is absent and nextEvent is absent)
    or (proposedEvent exists and nextEvent is absent and rejected is absent)
    or (previousWorkflowStep exists and action = ActionEnum -> Cancel)
CounterpartyPositionBusinessEventOrBusinessEventOrProposedEventChoice Condition
Choice rule to control that either positionBusinessEvent is present, businessEvent is present or proposedEvent is present, but not more than one at the same time.
required choice counterpartyPositionBusinessEvent, businessEvent, proposedEvent

Referenced by

3 types hold a WorkflowStep as an attribute.

Functions

Model functions that produce or consume this type. These are the CDM's own behaviour — the logic a correct implementation has to match.

FunctionRoleDescription
Create_WorkflowStep returns Function to create a workflow step with a business event and associated details about the message, identifiers, event timestamps, parties and accounts involved in the step. The function should be used when there is already a fully formed business event with the action set to signify that the step is new, or a correction/cancellation of a previous step. The action is constrained so that when a previous workflow step is specified, the valid actions are as follows; New -> New, New -> Correct, New -> Cancel, Correct -> Correct and Correct -> Cancel. When a previous workflow is not specified, the action must be New.
Create_AcceptedWorkflowStep returns Represents the acceptance 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. The instruction from the previous workflow step should be used with a [creation BusinessEvent] function to create the input business event passed into this function e.g. PartyChangeInstruction from the previous step is used with Create_PartyChange to produce the business event which should used as an input to this step.
Create_AcceptedWorkflowStepFromInstruction returns Represents the acceptance 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. The instruction from the previous workflow step should be used with a [creation BusinessEvent] function to create the input business event passed into this function e.g. PartyChangeInstruction from the previous step is used with Create_PartyChange to produce the business event which should used as an input to this step.
Create_ProposedWorkflowStep returns 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.
Create_RejectedWorkflowStep returns Represents the rejection of a proposed instruction that results in a workflow step containing the rejection flag, message details, identifiers, event timestamps, parties and accounts involved in the step. The previous workflow step input must exist to provide workflow lineage. This function will be further developed to provide the reasons for rejection.
Ingest_FpmlConfirmationToWorkflowStep returns —
MapClearingConfirmedToWorkflowStep returns —
MapExecutionAdviceToWorkflowStep returns —
MapExecutionAdviceRetractedToWorkflowStep returns —
MapExecutionNotificationToWorkflowStep returns —
MapRequestClearingToWorkflowStep returns —
MapTradeChangeAdviceToWorkflowStep returns —
Create_WorkflowStep takes Function to create a workflow step with a business event and associated details about the message, identifiers, event timestamps, parties and accounts involved in the step. The function should be used when there is already a fully formed business event with the action set to signify that the step is new, or a correction/cancellation of a previous step. The action is constrained so that when a previous workflow step is specified, the valid actions are as follows; New -> New, New -> Correct, New -> Cancel, Correct -> Correct and Correct -> Cancel. When a previous workflow is not specified, the action must be New.
Create_AcceptedWorkflowStep takes Represents the acceptance 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. The instruction from the previous workflow step should be used with a [creation BusinessEvent] function to create the input business event passed into this function e.g. PartyChangeInstruction from the previous step is used with Create_PartyChange to produce the business event which should used as an input to this step.
Create_AcceptedWorkflowStepFromInstruction takes Represents the acceptance 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. The instruction from the previous workflow step should be used with a [creation BusinessEvent] function to create the input business event passed into this function e.g. PartyChangeInstruction from the previous step is used with Create_PartyChange to produce the business event which should used as an input to this step.
Create_ProposedWorkflowStep takes 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.
Create_RejectedWorkflowStep takes Represents the rejection of a proposed instruction that results in a workflow step containing the rejection flag, message details, identifiers, event timestamps, parties and accounts involved in the step. The previous workflow step input must exist to provide workflow lineage. This function will be further developed to provide the reasons for rejection.
Create_Workflow takes Function to create a Workflow from a list of WorkflowStep.

Showing 12 of each. All 1286 functions →

Open WorkflowStep in the Model Browser

Walk the tree and the reference graph interactively, and switch releases to see how the type has changed. Free, no signup.

Model Browser All 200+ releases
Parsed from CDM 7.2.0 · event-workflow-type.rosetta cdm.event.workflow