JobResponseRecord multiplicity

ERDi-TestLab / ERDiTestlab-ProcessEvents

The repo holds the master version of the ETP designed ProcessEvents.xsd

MIT License

0 stars 1 forks source link

JobResponseRecord multiplicity #1

Closed gerardmoloneyetpartners closed 3 years ago

gerardmoloneyetpartners commented 3 years ago

The WorkExecutedEvent schema currently allows a single AddedJobResponseRecord.

It should allow for multiple AddedJobResponseRecords.

Proposed Fix is to insert the min/max occurs as per screenshot.

Other schemas may be affected and should be checked.

WorkCommenced
WorkExecuted
WorkCompleted
WorkRedirected
WorkAborted

gerardmoloneyetpartners commented 3 years ago

WorkCommenced is already set as [1..*] which is correct. at least 1 JobResponseRecord is required in this message type.
WorkCompleted is already set as [1..*] which is correct. at least 1 JobResponseRecord is required in this message type.
WorkRedirected is already set as [0..*] which is correct. JobResponseRecord is optional for this message type.
WorkAborted is already set as [1..*] which is correct. at least 1 JobResponseRecord is required in this message type.
WorkReconciled. Though not mentioned on original issue, WorkReconciled also has JobResponse and is looked at on the next comment.

gerardmoloneyetpartners commented 3 years ago

WorkReconciledEvent\JobResponseRecord

Looking further, things seem to be handled differently here. Added/Changed/Deleted JobResponseRecord are all allowed, but as mandatory once only entry (that can be null) by the omission of a minOccurs/maxOccurs statement, thought there are 0..* JobResponses allowed per Record.

Current coding.

Proposed coding

In light of looking also at the WorkReconciledEvent\JobResponseRecord\JobResponse multiplicity [0..] I would also propose the initial fix for WorkExecutedEvent\JobResponseRecord [0..] also be updated to allow mutliple WorkExecutedEvent\JobResponseRecord\JobResponse [0..*] as per below.

Current coding

Proposed Coding

alexmarginet-mi commented 3 years ago

No objections to the WorkExecutedEvent section of this issue.

Regarding the WorkExecutedEvent and JobResponseRecord part, does it make sense to have a both the AddedJobResponseRecord and the JobResponse objects as optional? That is, providing an AddedJobResponseRecord without a JobResponse?

The question is if, for example, this WorkExcecuteEventType would make sense?

<WorkExcecuteEventType>
   <AddedJobResponseRecord recordTypestamp="..." effectiveTimestamp="..." />
</WorkExcecuteEventType>

This is a valid xml that validates against the proposed xsd.

gerardmoloneyetpartners commented 3 years ago

@alexmarginet-mi Agreed, it would be better sense for JobResponseRecords to be 0 .. JobResponseRecords\JobResponse to be 1 ..

I will update the proposed commit with this proposed coding for the WorkExecutedEventType

gerardmoloneyetpartners commented 3 years ago

I propose the same adjustment to the WorkReconciledEventType where by, JobResponseRecord become 0 .. JobResponseRecord\JobResponse becomes 1 ..

h28669 commented 3 years ago

We agree with changes to WorkReconciledEventType. Can you commit asap, so that in next sprint we can do the adaptions required by schema file changes. Thanks. Gianni

gerardmoloneyetpartners commented 3 years ago

Hi Gianni, I am working on it locally. The other pull reqeust is done, but I am testing this one locally, and it's not working on the workreconciled change.

gerardmoloneyetpartners commented 3 years ago

I have rolled back WorkReconciled changes. this Issue and pull request now only deals with the WorkExecuted structure, and will be fixed as below.