SandGrainOne
commented
5 days ago Refinement: Events shouldn't need to support changes to subject formats from a producer. Subscribers can temporarily have 2 subscriptions to catch events using different formats.
Description
In order for a user to access all events from a resource related to the same subject, the user would need to perform multiple get requests with the same subject on different formats. The format of the subject should not be a factor when giving a user access to events.
Existing formats:
/party/{partyId}- used primarily by apps. Apps will also provide alternative subject with human readable values like for example:/org/356548756./organisation/{organisationnumber}- currently used by broker to represent either file sender or recipient of a file transfer.urn:altinn:organization:identifier-no:{organisationnumber}- used in events produced by dialogporten. This is the preferred format. It's adopted by authorization and can be used in policy files. It's human readable and doesn't require knowledge about the Altinn specific party id.After a talk with the authorization team we've agreed that having party id on the events is no longer necessary. It's convenient for authorization to be given the party id, but authorization will be able to simply join in a mapping table once they have their own copy of the party list.
The challenge with this will be subscriptions and existing use of the GET endpoints with subject filters on specific formats. There needs to be a way for Events to be able to identify the correct subject across all known formats. A subscription with a subject filter on format
/party/{partyid}should be pushed events which have a subject on format/organisation/{organisationnumber}.There are similar issues with alternativesubject, but not in the same way. The suggestion here would be to remove alternativesubject as a known event property that Events have built in support for.
Additional Information
The current situation might not be serious enough to be prioritized. It's hard to imagine any system producing events where subject format can vary. The assumption is that an event producer will be consistent and pick one format for all events. This in turn means that no one will need to create more than one subscription with the correct subject filter.
The only time where this issue might be an actual concern is when we wants to standardize on a format and introduce changes to formats.
Introducing consolidation logic will cause a performance hit, especially if Events in some cases need to perform lookup calls to register to find correct value.
Tasks
No response
Acceptance Criterias
No response