Subscription and Notification Pattern
Is used by Doing Business Abroad Pilot in Use Case "Doing Business in Another Member State" (DBA UC2)
Introductory text
Functional Variants of the Subscription and Notification Pattern
There are two distinct business requirements for Subscription and Notification, which both are relevant for teh DE4A Doing Business Abroad Pilot: First, updating a previously shared Evidence and second, being informed about a relevant Business Event or Life-Event that may or may not be represented in a change of Evidence Information.
Technically there are also two different potential approaches to Notification:
- Sending updated data in form of a defined Evidence type (e.g. resending the complete, updated Company Registration)
- Event Notifications that contain only the identification data and the event type (e.g. Merger initiated involving company EUID)
Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches:
[adding the two hybrid approaches?]
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.
Legal Considerations
Differnce between evidence update case (possible in framework SDGR?) and Event Notifications
Existence of consent / Publicly available information
Business vs. Citizen: For Citizen anything that is not based on Consent will be difficult.
Delimitation to BRIS (DBA specific)
As concluded in “DE4A Discussion paper BRIS 20200708 Final.docx” BRIS will not be used in the DBA pilot. This also applies for the subscription and notification pattern. The notifications send resorting under BRIS regulation are out of scope of DE4A. The DE4A pattern has its own subscriptions and notifications that do no relate to BRIS regulation. Note that in some cases this could lead to the situation that a Data Evaluator receives both a BRIS and a DE4A notification for one business event.
Note the BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. Thereby reversing the responsibilities.
Business Process
Event Subscription
Business Process
Activity Table [todo: edit descriptions to reflect the "'change subscription' case, cf. end date]
| Activity / UC | Role | Activity Type* | Description |
| Trigger: Need for a subscription idenfitied | Public Service Procedure | Service | A procedure of a public service provider leads to the registration of a subject. After this registration events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.
The subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests. In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company. 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. |
| Initiate subscription | DE | Service | To initiate the subscription data is collected and the subscription need is formulated:
|
| Trigger cancel subscription | eProcedure / Public service / Notification | Service | Potential triggers to cancel a subscription are:
|
| Change subscription | DE | Service | To cancel a subscription data is collected and the cancel subscription need is formulated:
|
| Lookup event provider routing information | DR | Service | The DR uses the data owner identifier to look up routing information on the competent authority that facilitates subscription service. |
| Inform National Contact point that subscription or change 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 subscription request | DR | Service | The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.
|
| Forward subscription error | DR | Service | The (un)subscription error message received from Data Transferor is forwarded to the Data Evaluator. |
| Investigate reason for subscription error | DE | User | The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design. |
| Forward confirmation | DR | Service | The confirmation on the (un)subscription request (received from the DT) is forwarded to the Data Evaluator. |
| Log subscription information | DE | Service | The confirmation is logged to complete the audit trail.
|
| Validate subscription request | DT | Service | The request is validated on a technical level: xml validation and check on DE authorisation. If the request validates it is forwarded to the Data Owner.
|
| Evaluate subscription request | DO | Service | The (un)subscription request is evaluated to check if the request can be completed:
|
| Prepare subscription error message | DO | Service | Collect the content of the error message and send it to the Data Transferor (if applicable).
|
| Send subscription error message | DT | Service | The error message is forwarded to the Data Requestor from who the request was received. |
| Register subscription | DO | Service | The Data Owner creates, changes or ends the subscription according the (un)subscription request. |
| Confirm subscription | DO | Service | The confirmation of the (un)subscription is created and send to the Data Transferor (if applicable).
|
| Send subscription confirmation | DT | Service | The (un)subscription confirmation is send to the Data Requestor from who the request was received. The (un)subscription confirmation message is added to the log. |
*Activity Type and Task Type in accordance with BPMN 2.0
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.
Subscription period
Including a subscription period with start and end date has several consequences... todo
Design decision: a subscription period with mandatory start and end dates is included in the subscription.
Catalogue of DE4A business events
tbd, see table below
Subscription register requirements
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 sent.
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.
There are two main choices for the subscription criteria, subscribe to changes in:
- business events
- evidences
Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent, see table below.
Business event - evidence mapping
Below example for Doing Business Abroad Pilot. Each pilot (domain) must define their common event list including a clear semantic explanation of each business or life event in order for the Data Evaluator to be able to interpret the event correctly and define an appropriate course of action, e.g. request an updated evidence or discontinue the public service.
| DE4A Business event | Event includes changes in | Related evidence type | Comment |
|---|---|---|---|
| Company info event | EUID, Updated company name/updated address/updated head quarters/changed identifier (EUID)/changed legal form/changed representatives | Company registration | Split this event in: address change, name change, ...? And with a status change, notify the specific status? |
| Annual report event | Annual reports | Annual report | What is the event? New annual report available, annual report changed, ...? Split this event? |
| Directors disqualification event | Disqualifications updated for directors | Directors disqualification | |
| National merger event | Merger initiated/completed/cancelled, transferring company identifier, aquring company identifier | Notifications are only relevant when the transferring company has subscribers. | |
| Cross border merger event | Merger initiated/completed/cancelled, transferrring company identifier, aquaring company identifier | Notifications are relevant when the transferring company has subscribers.
This event is also relevant without a subscription. The business register of a company involved in a merger wants notifications even if there is no prior subscription to the foreign company in the cross border merger. |
Event Notification
Business Process
Activity Table
| Activity / UC | Role | Type | Description |
| Identify cross-border event | DO | Service | The Data Owner evaluates all events identified in the register and identifies events that are portentially relevant for cross-border notifications.
Note that the DO must have a mapping of it's own business events to the list of DE4A business events. |
| Check subscription | DO | Service | The subscription register is queried for subscribers to the subject related to the event:
|
| 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 | Single notifications messages (one for each subscriber) are created from the list of subscribers and the notification payload. The routing information for each notification message is looked up.
The messages contain: subject identifier, secondary subject identifier (in case the identifier changed), subscriber identification, event identification, event timestamp, subscription reference (optional). |
| 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 | The event notification is send to the Data Requestor, a technical acknowledgement that the notification has been received by the DR is received. The audit log is updated with both the event notification and the acknowledgement. |
| Validate event notification | DR | Service | The Data Requestor performs a technical validation of the event notification and forwards it to the Data Evaluator. A technical exception flow is out of scope of this process description. |
| Determine event response | DE | Service | The notified event is analysed and the appropriate response is determined.
The determination result is logged as a part of the audit trail:
|
| Request unsubscription | DE | Service | When the company cannot be identified or the registered company or branch is no longer active the cancellation of the subscription is requested. Afterwards this will be analysed to find the cause of this apparently wrong subscription and to take appropriate measures. |
| Dismiss event | DE | Service | The notified event doesn't have impact on the procedures of the Data Evaluator and is dismissed. No further actions need to be taken. |
| Evidence update event triggered | DE | Service | The lookup pattern is triggered to request a new, current, copy of the relevant evidence.
|
| Identify business responses and notify responsible party | DE | User | The responsible organisational unit is identified and informed in order to take appropriate action. It depends on the specific process if this action can be performed automated or manually. |
Design decisions
Response on event notification
Functional responses from Data Evaluator to Data Owner after receiving an event notification, for example to inform that appropriate actions have been taken, are out of scope of the Subscription and Notification pattern.
Notifications from Subscriber
Notifications from Data Evaluator to Data Owner, for example to inform Data Owner on changes in the branch registration, are out of scope of the Subscription and Notification pattern.
Process Realisation
?All on one Page or do we create sub-pages for Business Process and Process Realisation?
Used by the following use cases
Application collaborations
TBD