WorkflowStep
Type CDM 7.2.0A 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.
Attributes
All 15 declared on WorkflowStep. Cardinality in amber is required.
| Name | Type | Card. | 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.
(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) 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.
| Function | Role | Description |
|---|---|---|
| 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.