Gate: Only External-ID in Generic Business Partner Input is required

[nicoprow]

When upserting generic business partner data input only the externalId is required. All other fields are optional. If the externalId is empty or null it should return an error.

Tasks

• Make city optional
• Make postal address optional
• Make country optional
• Other fields in subobjects like Identifiers, Classifications and so on

[martinfkaeser]

So, as I understand a BusinessPartnerInputRequest doesn't need a postalAddress. But if there is one, physicalPostalAddress is still required inside of it, right?
And PhysicalPostalAddressGateDto doesn't have any required fields?
What about AlternativePostalAddressDto? Going by the original ticket I guess it shouldn't have any required fields either, not even deliveryServiceType and deliveryServiceNumber?

And what about the output version?
Ideally we wouldn't want to change the "required"-ness of fields, but that would mean introducing input and output versions of PhysicalPostalAddressGateDto and AlternativePostalAddressDto.
In my opinion this is not worth the effort!

And AlternativePostalAddressDto, which now is used in the Pool and Gate needs to be split.

[nicoprow]

So, as I understand a BusinessPartnerInputRequest doesn't need a postalAddress. But if there is one, physicalPostalAddress is still required inside of it, right? And PhysicalPostalAddressGateDto doesn't have any required fields? What about AlternativePostalAddressDto? Going by the original ticket I guess it shouldn't have any required fields either, not even deliveryServiceType and deliveryServiceNumber?

And what about the output version? Ideally we wouldn't want to change the "required"-ness of fields, but that would mean introducing input and output versions of PhysicalPostalAddressGateDto and AlternativePostalAddressDto. In my opinion this is not worth the effort!

And AlternativePostalAddressDto, which now is used in the Pool and Gate needs to be split.

1. True, we don't have an overview of which fields are required in case someone actually gives a postal address, physical postal address or alternative postal address. I don't like the idea of having completely empty objects there. We should get into this and see if we can agree on some minimum required fields for these address objects.
2. Validating the integrity of the data is of course a given. We can of course have the same DTO for both, having nullable fields there and just use service logic to validate this. It is important that these fields are validated to not be null where applicable and at the same time the API user needs to understand that these fields are required. In my opinion, whatever we do these are the requirements.
3. I think in the long term we should split the explicit DTOs between all applications anyway to reduce cohesion. Instead, we can rely on interfaces for these DTOs to define common API model structures.

[nicoprow]

We got an update on this. The idea is really to make every single field optional in the generic business partner model except the external-id. This also includes fields like identifier type value. Idea is to accept in the Gate all possible business partners without performing any kind of validation that prevents it from being persisted in the input.

[nicoprow]

These changes should only affect the Gate DTOs used for upserting business partners in the input stage. No changes in the persistence layer needed.

[fabiodmota]

Should we also update the redoc about this endpoints ?
https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/eclipse-tractusx/bpdm/docs/api/generic-input/docs/api/gate-proposal.yaml#tag/Input/paths/~1input~1business-partners/put