EventTimestamp
Type CDM 7.2.0A class to represent the various set of timestamps that can be associated with lifecycle events, as a collection of [dateTime, qualifier].
Extends —
Extended by —
Attributes 2
Namespace cdm.event.workflow
Attributes
All 2 declared on EventTimestamp. Cardinality in amber is required.
| Name | Type | Card. | Description |
|---|---|---|---|
| dateTime | zonedDateTime | 1..1 | The CDM specifies that the zoned date time is to be expressed in accordance with ISO 8601, either as UTC as an offset to UTC. |
| qualification | EventTimestampQualificationEnum | 1..1 | The timestamp qualifier is specified through an enumeration because the experience of integrating the DTCC and CME data representations suggests that a wide set of timestamps are currently utilized among service providers, while there is not at present an objective set of criteria that could help suggest a defined set of timestamps as part of the CDM. At some future point, one possible baseline could be developed from the review of the set of timestamps specified across regulatory regimes and regulations (incl. regulations such as high frequency trading). Also, the integration with a further set of implementations and the specification of business workflows such as clearing as part of the CDM development should help confirm the implementation approach in this respect. |
Referenced by
2 types hold an EventTimestamp 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 |
|---|---|---|
| MapEventTimestamp | 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_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. |
Open EventTimestamp 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.