Subscription and Notification Pattern

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]

Business Process

Event Subscription

Business Process (picture)

Activity Table

Activity / UC	Role	Type*	Description
Trigger initiate subscription	eProcedure	A / M	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	A	Initiate subscription: Collect data and formulate subscription need: company EUID (includes country and business register identification) all events of subset/type of events (specific event catalogue)? tbd type of action: subscribe/ unsubscribe period of subscription? tbd Forward to Data requestor (if applicable) 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	A / M	Public service: the delivery of an public service can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the  branch-office registration). eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription? Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow). Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
Cancel subscription	DE	A	Cancel subscription: Collect data and formulate cancel subscription need: company EUID all events of subset/type of events (specific event catalogue)? tbd type of action: cancel subscription specific end-date of the subscription? tbd Forward to Data requestor (if applicable)
Lookup event provider routing information	DR	A	Lookup information on competent authority that facilitates subscription service (metadata tbd) (should data requestor resolve participant id dynamically? Not needed, participant id is stable enough)
Inform National Coordinator that un-subscription was not successful	DR	M	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	A	Send the request to subscribe or unsubscribe to the DT.
Forward (un)subscription error	DR	A	Forward (un)subscription error message received from DT to DE
Investigate reason for (un)subscription error	DE	M	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	A	Forward the confirmation on the (un)subscription request (received from the DT) to the DE.
Log (un)subscription information	DE	A	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	A	Technical validation including forwarding to data owner. Technical exception out of scope
Evaluate (un)subscription request	DO	A	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	A	Collect the content (mainly the link to the request and the error message) and send it to DT
Send (un)subscription error message	DT	A	Forward to DR
Register (un)subscription	DO	A	Data owner creates/ends the DE’s subscription on the company’s events. Remarks: If messages resemble BRIS messages that would avoid extra work to be done; because this mechanism is in already in place Harmonised set of business event needed. Register on evidence type?
Confirm (un)subscription	DO	A	Create a confirmation: (un)subscription result (success), timestamp, link to (un)subscription request and send to DT (if applicable)
Send (un)subscription confirmation	DT	A	Send confirmation to DR Log confirmation

• A / M = Automated or Manual

Notes:

• A user centric perspective is that the user can cancel the subscription and prefers to provide the changes in company registration manually. This is out of scope.
• Separation of domains:
• BRIS domain: if a branch of a certain company type (limited company) is registered in the Business Register of MS the consequences are:
• The subscription is already covered by BRIS and legally necessary as long as branch is registered.
• User has no influence on subscription process
• SDG domain, if company is registered at DE:
• subscription and explicit request as long as eProcedure runs? tbd
• BRIS: covers some cases; check at DE if subscription is already covered by BRIS?

Event Notification

Business Process (picture)

Activity / UC	Role	Type	Description
Trigger Change in registered company	Company representative / SP	A / M	A change in the company registration triggers the notification process. The change in company registration can be initiated by: a representative of the company itself, e.g.: merger, change of owner. a public service, e.g.: change of postal code, death of representative, court of law ruling.
Change company registration	DO	A / M	Standard process of the Data Owner - Business Register - to process changes in company registration.
Identify event	DO	A	The DO matches the changes in company registration to the business event catalogue (event monitoring), identifies the business event that has taken place and determines which processes are related to the business event. The DO triggers all process(es) related to the identified event: if the change matches with OOP TS event catalogue: continue OOP TS notification process if the change matches with other event catalogue(s) (e.g. BRIS): trigger relevant process(es) Note that changes of the company can be out of scope of the DE4A/DBA-pilot and therefore not lead to a notification. Note that an event could resort under BRIS and under OOP TS regulation; e.g. a cross-border merger of a company and Bolagsverket and RVO have a subscription on this company: this leads to a BRIS notification to Bolagsverket and an OOP TS notification to RVO.
Check subscription	DO	A	Check the subscription registration for subscribers to the company that is the subject of the business event: No active subscriptions: end of process Active subscriptions found: continue notification process
Extract evidence	DO	A	Extraction of changed data to include in notification (could be part of prepare notification step).
Prepare notification message and subscriber list	DO	A	Make a list of the subscribers to notify and create the payload of the notification. The payload includes the changed data, so changed data is not missed when different notifications follow shortly after each other. The original value and new value of the changed elements are included and not the whole Company Registration evidence (sometimes the original value is needed (e.g. EUID).
Resolve service metadata	DT	A	Move from a list to single notifications (one for each subscriber) and lookup the routing information for each notification.
Resolve subscriber participant ID and inform National Coordinator	DT	M	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	M	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	M	The resending of previously sent notifications requires a manual action at the DT.
Send event notification	DT	A	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	A	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. Log received message as part of audit trail?
Determine event response	DE	A	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: EUID Notified event Request id Determined response Timestamp of determination
Request unsubscription	DE	A	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	A	The business event is not relevant for the DE and is dismissed. No further actions need to be taken.
Update company information	DE	A	The company data that is registered by the DE is updated, using the information in the notification.
Identify business responses and notify responsible party	DE	A/M	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.

Process Realization

?All on one Page or do we create sub-pages for Business Process and Process Realization?

Used by the following use cases

DBA (UC2)

Application collaborations

TBD