The Profile API is in the process of phasing out setting actual data in the UserId field when looking up user contact points (i.e. when POSTing to profile/api/v1/users/contactpoint/lookup and profile/api/v1/users/contactpoint/availability)
Notifications uses a domain model (UserContactPoints) with no nullable-declared properties, which also serves as the deserialization model when looking up user contact points in the ProfileClient. This leads to a runtime exception if/when the relevant Profile API endpoints start returning userId: null, as the domain model expects an integer value. The other properties of the (UserContactPoints) domain model are capable of receiving null values from the Profile API, as they are initialized to string.Empty.
To avoid this breaking change in the UserIdproperty, the Profile API is currently returning userId: 0 for user contact points lookups.
Changes in this PR
Add a DTO / API model UserContactPointsDTO that represents/reflects the current/soon-to-be API contract from the Profile API when looking up user contact points. The DTO explicitly declares nullable properties. An explicit mapper (for DTO -> domain model) is defined (currently implemented as an extension method on the DTO class) and used by the ProfileClient when returning the data to the caller (the Core ContactPointsService).
Using this separate API / DTO model, as compared to modifying the domain model UserContactPoints, has the advantage of decoupling the current direct binding between the Profile API interface and our core / domain model in this application.
Related Issue(s)
616
Verification
[x] Your code builds clean without any errors or warnings
[x] Manual testing done (required)
[x] Relevant automated test added (if you find this hard, leave it and we'll help out)
[x] All tests run green
Documentation
[ ] User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)
Description
Current state
The Profile API is in the process of phasing out setting actual data in the UserId field when looking up user contact points (i.e. when POSTing to profile/api/v1/users/contactpoint/lookup and profile/api/v1/users/contactpoint/availability)
Notifications uses a domain model (UserContactPoints) with no nullable-declared properties, which also serves as the deserialization model when looking up user contact points in the ProfileClient. This leads to a runtime exception if/when the relevant Profile API endpoints start returning
userId: null
, as the domain model expects an integer value. The other properties of the (UserContactPoints) domain model are capable of receiving null values from the Profile API, as they are initialized tostring.Empty
.To avoid this breaking change in the
UserId
property, the Profile API is currently returninguserId: 0
for user contact points lookups.Changes in this PR
Add a DTO / API model
UserContactPointsDTO
that represents/reflects the current/soon-to-be API contract from the Profile API when looking up user contact points. The DTO explicitly declares nullable properties. An explicit mapper (for DTO -> domain model) is defined (currently implemented as an extension method on the DTO class) and used by the ProfileClient when returning the data to the caller (the Core ContactPointsService).Using this separate API / DTO model, as compared to modifying the domain model UserContactPoints, has the advantage of decoupling the current direct binding between the Profile API interface and our core / domain model in this application.
Related Issue(s)
616
Verification
Documentation