New model: IdBasedRequestForUpdate

[TobiasHamacherDLR]

Description

requested model for DcmUuidBasedRfu

Closes #
#137

MS2 Criteria

(to be filled out by PR reviewer)

• the model validates with the BAMM SDS SDK in the version specified in the Readme.md of this repository by the time of the MS2 check (e.g., 'java -jar bamm-cli.jar -i <path-to-aspect-model> -v ). The BAMM CLI is available here and in GitHub
• use Camel-Case (e.g., "MyModelElement" or "TimeDifferenceGmtId", when in doubt follow https://google.github.io/styleguide/javaguide.html#s5.3-camel-case)
• the identifiers for all model elements start with a capital letter except for properties
• the identifier for properties starts with a small letter
• all model elements at least contain the fields "name" and "description" in English language.
• no duplicate names or preferredNames within an Aspect (e.g. a Property and the referenced Characteristic should not have the same name)
• the versioning in the URN follows semantic versioning, where minor version bumps are backwards compatible and major version bumps are not backwards compatible.
• use abbreviations only when necessary and if these are sufficiently common
• avoid redundant prefixes in property names (consider adding properties to an enclosing Entity or even adapt the namespace of the model elements, e.g., instead of having two properties DismantlerId and DismantlerName use an Entity Dismantler with the properties name and id or use a URN like io.catenax.dismantler:0.0.1)
• fields preferredName and description are not the same
• preferredName should be human readable and follow normal orthography (e.g., no camel case but normal word separation)
• name of aspect is singular except if it only has one property which is a Collection, List or Set. In theses cases, the aspect name is plural.
• units are referenced from the BAMM unit catalog whenever possible
• use constraints to make known constraints from the use case explicit in the aspect model
• when relying on external standards, they are referenced through a "see" element
• all properties with an simple type have an example value
• metadata.json exists with status "release"
• file RELEASE_NOTES.md exists and contains entries for proposed model changes
• all contributors to this model are mentioned in copyright header of model file

MS3 Criteria

(to be filled out by semantic modeling team before merge to main-branch)

• All required reviewers have approved this PR (see reviewers section)
• The new aspect (version) will be implemented by at least one data provider
• The new aspect (version) will be consumed by at least one data consumer
• There exists valid test data
• In case of a new (incompatible) major version to an existing version, a migration strategy has been developed
• The model has at least version '1.0.0'

[nhaenis]

@bs-jokri takes care that the MS2 review is done.

[bs-jokri]

LGTM

[bs-jokri]

@TobiasHamacherDLR MS3 required? Will you present next time?

[nhaenis]

@bs-jokri We need the MS3 but we decided in our UseCase to wait for the release of the Notificarion Header Model so that we don't have to make any adjustments in case there are changes until the release - unless you can show me in our call how we can reference the header and don't have to copy it into our data model :)

[LukasHeimann]

Hi everyone, here are some comments from SAP.

[github-actions]

Validation Report for io.catenax.id_based_request_for_update/1.0.0/IdBasedRequestForUpdate.ttl

Validation failed:

[bs-jokri]

@nhaenis @TobiasHamacherDLR is anyone picking things up in this PR? Is this model still relevant?

[nhaenis]

@nhaenis @TobiasHamacherDLR is anyone picking things up in this PR? Is this model still relevant?

Yes, since the Message Header is now released i distributed this model for the review in our use case

[github-actions]

Validation Report for io.catenax.id_based_request_for_update/1.0.0/IdBasedRequestForUpdate.ttl

Input model is valid

[TobiasHamacherDLR]

modeling_team

[bs-jokri]

Conditional approval for MS3 under the condition that it is check if the materialDemandId, changedAt and capacityGroupId should really be optional (could lead to incomplete entries in the list.) Will be checked by @nhaenis with use case

[nhaenis]

clarification with Tom has taken place - all properties are marked correctly as optional. PR can be merged @bs-jokri

[LukasHeimann]

IMHO capacityGroupId and materialDemandId should not be optional, and there is no sample payloads where the Sets have elements but the entries don't have the IDs that were discussed within the use case.

It was discussed to have empty sets with a "send all Capacity Group / Material Demands" semantic (as it also says in the descriptions), but empty sets are not the same as sets with entries without IDs. It is unclear (and semantically undefined) to me what the use case of a message (schema-wise correct) as follows would be:

{
    "WeekBasedCapacityGroup": [
        {},
        {
            "changedAt": "2023-03-08T11:44:27.701+01:00"
        },
        {
            "changedAt": "2022-05-015T10:34:47.015+01:00"
        }
    ]
}

[nhaenis]

@LukasHeimann here's the text which will be standardized in the API standard and was reviewed with all DCM use case participants multiple times and in our workshop last week containing all possible payloads:
https://confluence.catena-x.net/pages/viewpage.action?pageId=81703605

[LukasHeimann]

Hi @nhaenis, that is the document with the sample payloads I'm referring to. Note that there is no sample payload, where materialDemandId or capacityGroupId are missing from objects within the sets.

It is true that the sets may be empty and have no elements, but that is not the same as them having elements without a certain property, as shown above.

[nhaenis]

@LukasHeimann Can you please make a suggestion for the wording in the standard and give it to Anton so that we can change the text accordingly. From my point of view, this is not something that is possible via modeling, but we can describe it in the API document

[LukasHeimann]

What you want is that the set can be empty (which is the default in SAMM, so that is the case currently), but if the set contains objects, those must contain materialDemandId or capacityGroupId respectively. Thus, you only need to change those two properties to be mandatory instead of optional.

[LukasHeimann]

I.e., if the materialDemandId is non-optional, the following payload would still be valid:

{
  "weekBasedMaterialDemand": []
}

If you don't believe me, try it out with the aspect model editor yourself. Export to JSON Schema and put it e.g. into https://www.jsonschemavalidator.net/

[nhaenis]

@LukasHeimann and if both materialDemandID and changedAt are non-optional - would this payload then be valid without a changedAt?

{
    "weekBasedMaterialDemand": [
        {
            "materialDemandID":"278e333d-f06b-4b59-8e95-22862f69807f"},
        {
            "materialDemandID":"46adfa5d-36b7-4a9b-9ac6-508dac500dd2"}
    ]
}

[LukasHeimann]

@nhaenis No, changedAt should still be optional -- you obviously want to allow having it missing. I was only talking about the two ID properties needing to be mandatory.

[github-actions]

Validation Report for io.catenax.id_based_request_for_update/1.0.0/IdBasedRequestForUpdate.ttl

Input model is valid

[nhaenis]

@LukasHeimann ID properties are non-optional in entity now - thanks for your hint! PR can be merged after your review

[LukasHeimann]

Looks good! Thank you for adapting the model

[github-actions]

Validation Report for io.catenax.id_based_request_for_update/1.0.0/IdBasedRequestForUpdate.ttl

Input model is valid