Prepare for nullability of UserId in Profile API - user contact point lookups #644
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hggutvik
changed the title
src/Altinn.Notifications.Integrations/Profile/Models/UserContactPointsDTO.cs
Outdated
Show resolved
Hide resolved
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
UserIdproperty, the Profile API is currently returninguserId: 0for user contact points lookups.Changes in this PR
Add a DTO / API model
UserContactPointsDTOthat 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)
Verification
Documentation