Difference between revisions of "Subscription and Notification Pattern"
Line 167: | Line 167: | ||
* A / M = Automated or Manual | * A / M = Automated or Manual | ||
+ | |||
+ | ==== Messages ==== | ||
+ | |||
+ | ===== Message ‘Subscription request’ ===== | ||
+ | {| class="wikitable" | ||
+ | |'''Element''' | ||
+ | |'''Description''' | ||
+ | |'''Example value''' | ||
+ | |- | ||
+ | |Legal Person Identifier | ||
+ | |Identification of the company following the eIDAS regulation: country code / country code / company identifier | ||
+ | |RO/AT/90000471 | ||
+ | |- | ||
+ | |Requested action | ||
+ | |Indicates whether a subscription or the cancellation of a subscription is requested by the sender: ‘subscribe’ or ‘unsubscribe’ | ||
+ | |subscribe | ||
+ | |- | ||
+ | |Participant ID | ||
+ | |The OOP TS participant identifier that identifies the organisation that is the subscriber (and thus will receive business event notifications) | ||
+ | |SE000000013 | ||
+ | |- | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |TBD: event catalogue | ||
+ | |The domain of events the subscription is | ||
+ | | | ||
+ | |- | ||
+ | |TBD: subscription period | ||
+ | |The date of beginning and ending (optional) of the subscription | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | ===== Message ‘Subscription confirmation’ ===== | ||
+ | {| class="wikitable" | ||
+ | |'''Element''' | ||
+ | |'''Description''' | ||
+ | |'''Example value''' | ||
+ | |- | ||
+ | |Legal Person Identifier | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Subscription timestamp | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Subscription result | ||
+ | |Subscription successful ; subscription cancellation successful | ||
+ | | | ||
+ | |- | ||
+ | |Subscription request reference | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Subscription reference | ||
+ | |Local identifier of the subscription. Not needed but can be useful in exception flows | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | ===== Message ‘Subscription error’ ===== | ||
+ | {| class="wikitable" | ||
+ | |'''Element''' | ||
+ | |'''Description''' | ||
+ | |'''Example value''' | ||
+ | |- | ||
+ | |Legal Person Identifier | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Request type | ||
+ | |Subscribe / unsubscribe | ||
+ | | | ||
+ | |- | ||
+ | |Error timestamp | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Error message | ||
+ | |Subscribe: company unknown, (participant not authorized) | ||
+ | |||
+ | Unsubscribe: company unknown, company not active, subscription unknown, subscription not active | ||
+ | | | ||
+ | |- | ||
+ | |Subscription request reference | ||
+ | | | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | ==== Design decisions ==== | ||
+ | |||
+ | ===== Explicit request and preview ===== | ||
+ | The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation: | ||
+ | |||
+ | * Notification is performed without a user transaction, making real-time explicit request and preview impossible. | ||
+ | * Fraud prevention outweighs user centricity, making explicit request and preview less opportune. | ||
+ | * The public nature of company data relaxes the need of explicit request and preview. | ||
+ | |||
+ | Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request | ||
+ | |||
+ | ''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable. | ||
+ | |||
+ | ===== Positioning of subscription registration ===== | ||
+ | For the location of the subscription registration certain options can be considered: | ||
+ | |||
+ | * Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription). | ||
+ | |||
+ | * Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE. | ||
+ | * At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component. | ||
+ | |||
+ | ''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO. | ||
+ | |||
+ | ===== Evidence exchange and subscription request ===== | ||
+ | The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways: | ||
+ | |||
+ | * As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n. | ||
+ | |||
+ | * In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is send. | ||
+ | |||
+ | ''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch. | ||
+ | |||
+ | Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails. | ||
=== Event Notification === | === Event Notification === | ||
Line 283: | Line 406: | ||
Depends on process, case by case, if this can be automated or manually. | Depends on process, case by case, if this can be automated or manually. | ||
|} | |} | ||
− | |||
Note: | Note: | ||
Line 289: | Line 411: | ||
* A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check. | * A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check. | ||
* Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS. | * Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS. | ||
+ | |||
+ | ==== Messages ==== | ||
+ | |||
+ | ===== Message ‘Business event notification’ ===== | ||
+ | {| class="wikitable" | ||
+ | |'''Element''' | ||
+ | |'''Description''' | ||
+ | |'''Example value''' | ||
+ | |- | ||
+ | |Legal Person Identifier | ||
+ | |Identification of the company following the eIDAS regulation: country code / country code / company identifier | ||
+ | | | ||
+ | |- | ||
+ | |Business event identification | ||
+ | |The identification of the business event (list of value: OOP TS business event catalogue) | ||
+ | | | ||
+ | |- | ||
+ | |Business event timestamp | ||
+ | |Date and time of business event | ||
+ | | | ||
+ | |- | ||
+ | |Subscription reference | ||
+ | |Identification of the subscription as registered at DO (local id) which can be used in communication between DO and DE. Not essential but can be useful in exception flows | ||
+ | | | ||
+ | |} | ||
== Process Realization == | == Process Realization == |
Revision as of 14:26, 10 May 2021
Introductory text
Functional Variants of the Subscription and Notification Pattern
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event
Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.
Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the Lookup Pattern to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]
Working Hypotheses
Business Process
Event Subscription
Business Process (picture)
Activity Table
Activity / UC | Role | Type* | Description |
Trigger initiate subscription | eProcedure | User | The eProcedure leads at the side of the data-evaluator to either the registration of the represented company or the registration of a branch of the represented company (the parent-company of the branch).
A successful registration of the company or the branch of the company leads to a subscription to business events of the represented company. This is needed to assess impact of these business events on service delivery to the company or the branch.
The subscription process can also be triggered for technical reasons: for instance to resend subscription requests because an error occurred at DO-side. |
Initiate subscription | DE | Service | Initiate subscription:
Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE. |
Trigger cancel subscription | eProcedure / Public service / Notification | Service | Potential triggers to cancel a subscription are:
|
Cancel subscription | DE | Service | Cancel subscription:
|
Lookup event provider routing information | DR | Service | Lookup information on competent authority that facilitates subscription service (metadata tbd)
|
Inform National Coordinator that un-subscription was not successful | DR | User | In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow. |
Send (un)subscription request | DR | Service | Send the request to subscribe or unsubscribe to the DT. |
Forward (un)subscription error | DR | Service | Forward (un)subscription error message received from DT to DE |
Investigate reason for (un)subscription error | DE | User | Analyse error and take appropriate actions (error could be on side of DE of DO) (exception so no need to model this in detail) |
Forward confirmation | DR | Service | Forward the confirmation on the (un)subscription request (received from the DT) to the DE. |
Log (un)subscription information | DE | Service | The confirmation is logged to complete the audit trail.
Note: register in a way that it is easily readable (optional: include subscription id). |
Validate (un)subscription request | DT | Service | Technical validation including forwarding to data owner. Technical exception out of scope |
Evaluate (un)subscription request | DO | Service | Functional check of request to subscribe: does company exists, are type of events/subscription supported, is DE authorized.
Functional check of request to unsubscribe: does subscription exists. If the request does not pass the functional check, the request is rejected. |
Prepare (un)subscription error message | DO | Service | Collect the content (mainly the link to the request and the error message) and send it to DT |
Send (un)subscription error message | DT | Service | Forward to DR |
Register (un)subscription | DO | Service | Data owner creates/ends the DE’s subscription on the company’s events.
Remarks:
|
Confirm (un)subscription | DO | Service | Create a confirmation: (un)subscription result (success), timestamp, link to (un)subscription request and send to DT (if applicable) |
Send (un)subscription confirmation | DT | Service | Send confirmation to DR
|
- A / M = Automated or Manual
Messages
Message ‘Subscription request’
Element | Description | Example value |
Legal Person Identifier | Identification of the company following the eIDAS regulation: country code / country code / company identifier | RO/AT/90000471 |
Requested action | Indicates whether a subscription or the cancellation of a subscription is requested by the sender: ‘subscribe’ or ‘unsubscribe’ | subscribe |
Participant ID | The OOP TS participant identifier that identifies the organisation that is the subscriber (and thus will receive business event notifications) | SE000000013 |
TBD: event catalogue | The domain of events the subscription is | |
TBD: subscription period | The date of beginning and ending (optional) of the subscription |
Message ‘Subscription confirmation’
Element | Description | Example value |
Legal Person Identifier | ||
Subscription timestamp | ||
Subscription result | Subscription successful ; subscription cancellation successful | |
Subscription request reference | ||
Subscription reference | Local identifier of the subscription. Not needed but can be useful in exception flows |
Message ‘Subscription error’
Element | Description | Example value |
Legal Person Identifier | ||
Request type | Subscribe / unsubscribe | |
Error timestamp | ||
Error message | Subscribe: company unknown, (participant not authorized)
Unsubscribe: company unknown, company not active, subscription unknown, subscription not active |
|
Subscription request reference |
Design decisions
Explicit request and preview
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:
- Notification is performed without a user transaction, making real-time explicit request and preview impossible.
- Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
- The public nature of company data relaxes the need of explicit request and preview.
Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request
Design decision: for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.
Positioning of subscription registration
For the location of the subscription registration certain options can be considered:
- Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).
- Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
- At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.
Design decision: The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.
Evidence exchange and subscription request
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:
- As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.
- In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is send.
Design decision: the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.
Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.
Event Notification
Business Process (picture)
Activity / UC | Role | Type | Description |
Trigger Change in registered company | Company representative / SP | User | An event regarding the company triggers the notification process. This event can be initiated by:
|
Change company registration | DO | User | Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event. |
Identify DE4A event | DO | Service | The DO determines the DE4A Business event name.
|
Check subscription | DO | Service | Check the subscription register for subscribers to the company that is the subject of the business event:
|
Extract evidence | DO | Service | Delete this step. (sending evidence or changed data is another type of notification process) |
Prepare notification message and subscriber list | DO | Service | Make a list of the subscribers to notify and create the payload of the notification, mainly the DE4A business event name and the timestamp the event took place. |
Resolve service metadata | DT | Service | Move from a list of subscribers to single notifications (one for each subscriber) and lookup the routing information for each notification. |
Resolve subscriber participant ID and inform National Coordinator | DT | User | If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures. |
Request from DE to resend event notifications | DE | User | Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested. |
Resend past event notifications | DT | User | The resending of previously sent notifications requires a manual action at the DT. |
Send event notification | DT | Service | Send notification, receive the acknowledgement that the notification has been received by the DR and update the audit log with both the event notification and the acknowledgement. |
Validate event notification | DR | Service | DR performs a technical validation of the event notification and forward it to the DE. A technical exception flow is out of scope of this process description.
|
Determine event response | DE | Service | Check the notified business event and determine the action to be taken.
Note that every determination result is logged as a part of the audit trail or for internal reasons:
|
Request unsubscription | DE | Service | When the company cannot be identified or is no longer active. Afterwards this will have to be analysed this to find the cause of this apparently wrong subscription and to take appropriate measures. |
Dismiss event | DE | Service | The business event is not relevant for the DE and is dismissed. No further actions need to be taken. |
Update company information | DE | Service | THe lookup pattern is triggered to request a new copy of the Company Registration Evidence. |
Identify business responses and notify responsible party | DE | User | Notify responsible party or organizational unit (that then contacts the company if needed).
Depends on process, case by case, if this can be automated or manually. |
Note:
- A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check.
- Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS.
Messages
Message ‘Business event notification’
Element | Description | Example value |
Legal Person Identifier | Identification of the company following the eIDAS regulation: country code / country code / company identifier | |
Business event identification | The identification of the business event (list of value: OOP TS business event catalogue) | |
Business event timestamp | Date and time of business event | |
Subscription reference | Identification of the subscription as registered at DO (local id) which can be used in communication between DO and DE. Not essential but can be useful in exception flows |
Process Realization
?All on one Page or do we create sub-pages for Business Process and Process Realization?
Used by the following use cases
Application collaborations
TBD