BusinessEvent choice condition update

[lagarciath]

Issue Summary

In the current CDM model, the representation of a WorkflowStep (cdm.workflow.event.WorkflowStep) includes a condition that is not fully aligned with the approach used for other objects. Specifically, the condition in question is CounterPartyPositionBusinessEventOrBusinessEventChoice.

This condition appears to be designed to ensure that counterpartyPositionBusinessEvent and businessEvent are not both present simultaneously. However, its current structure - as a required choice - needs selecting one of these elements each time WorkflowStep is used.

It has been observed that proposedEvent, which specifies the required inputs for a transition before a business event is fully formed, does not include either counterpartyPositionBusinessEvent or businessEvent. While these fields are not necessary at this stage, their mandatory status results in a validation issue when neither is provided.

Steps to Reproduce

Validation of a workflowStep containing a proposedEvent.

Actual Behaviour

The existance of a proposedEvent without a businessEvent or a counterpartyPositionBusinessEvent is a validation error.

Expected Behaviour

The proposal is to change the choice from required choice between businessEvent and counterpartyPositionBusinessEvent to a required choice between proposedEvent, businessEvent and counterpartyPositionBusinessEvent.

This would require a change in the definition of the elements contained in the workflowStep, as it is assumed that a proposedEvent can be present at the same time as a businessEvent.

Compatibility

This change is not fully backward compatible. While it doesn't invalidate previously correct data instances, it introduces a new required state that consuming systems must be updated to accommodate.

Impact on Valid States:

• Instances containing only businessEvent remain valid
• Instances containing only counterpartyPositionBusinessEvent remain valid
• A new valid state is introduced: instances containing only proposedEvent
• Instances containing none of these three elements remain invalid (as it's still a required choice)
• New invalid state is introduced: Instances containing more than one of these three elements are invalid

Backward Compatibility:

• Previously valid WorkflowStep instances (containing either businessEvent or counterpartyPositionBusinessEvent) remain structurally valid under the new definition
• Systems generating WorkflowStep data are not immediately broken, as they can continue creating instances with only businessEvent or counterpartyPositionBusinessEvent. However, they now have the option to generate instances with proposedEvent
• Systems that read or process WorkflowStep data will be impacted. They must be updated to recognize and correctly handle the new possibility of proposedEvent being present instead of businessEvent or counterpartyPositionBusinessEvent. Existing systems expecting only the original two options will likely fail or misinterpret data if they encounter a WorkflowStep containing only proposedEvent

[minesh-s-patel]

👍 @lagarciath