Difference between revisions of "Subscription and Notification Pattern"

From DE4A
Jump to navigation Jump to search
(Align with new schemeversion on business events)
(Add figure Event Not and moved DBA specific text to DBA Use case page)
Line 22: Line 22:
 
=== Event Subscription ===
 
=== Event Subscription ===
  
Business Process (picture)
+
==== Business Process ====
 +
[[File:DE4A D2.5 PSA 0.8 evt.jpg|none|thumb]]
  
Activity Table  
+
==== Activity Table ====
 
{| class="wikitable"
 
{| class="wikitable"
 
|'''Activity / UC'''
 
|'''Activity / UC'''
|'''Role'''  
+
|'''Role'''
 
|'''Type*'''
 
|'''Type*'''
 
|'''Description'''
 
|'''Description'''
Line 34: Line 35:
 
|Public Service Procedure
 
|Public Service Procedure
 
|User
 
|User
|The Procedure 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 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.
  
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 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.
The  subscription process can also be triggered for technical reasons: for instance to resend subscription requests because an error occurred at DO-side.
 
  
 
|-
 
|-
Line 46: Line 47:
 
|DE
 
|DE
 
|Service
 
|Service
|Initiate subscription:
+
|To initiate the subscription data is collected and the subscription need is formulated:
 +
 
 +
* subject identifier
 +
* data owner identifier
 +
* subscriber identifier
 +
 
 +
* event catalogue
 +
 
 +
* action 'subscribe'
 +
* subscription start and end date
  
* Collect data and formulate subscription need:
 
** subject identifier
 
** all events of a common event catalogue
 
** type of action: subscribe
 
** period of subscription
 
* 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.
+
The subscription need is forwarded to the Data Requestor (if applicable).
  
 
|-
 
|-
Line 63: Line 67:
 
|Potential triggers to cancel a subscription are:
 
|Potential triggers to cancel a subscription are:
  
* 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).
+
* Public service: public service delivery 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?
+
* 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).
 
* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).
Line 74: Line 78:
 
|DE
 
|DE
 
|Service
 
|Service
|Cancel subscription:
+
|To cancel a subscription data is collected and the cancel subscription need is formulated:
 +
* subject identifier
 +
* data owner identifier
 +
* subscriber identifier
 +
* event catalogue
 +
* action 'cancel subscription'
 +
* subscription end date
 +
 
  
* Collect data and formulate cancel subscription need:
+
The cancel subscription need is forward to the Data Requestor (if applicable).
** company identifier
 
** 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'''
 
|'''Lookup event provider routing information'''
 
|DR
 
|DR
 
|Service
 
|Service
|Lookup information on competent authority that facilitates subscription service (dynamic lookup, metadata tbd)
+
|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 un-subscription was not successful'''
 
|'''Inform National Contact point that un-subscription was not successful'''
Line 96: Line 102:
 
|DR
 
|DR
 
|Service
 
|Service
|Send the request to subscribe or unsubscribe to the DT.
+
|The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.
  
  
Subscription / cancel subscription request contains: participant id of subscriber, subject identifier, set of common events, period of subscription, action (subscribe/cancel subscription).
+
The subscription / cancel subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).
  
 
|-
 
|-
Line 105: Line 111:
 
|DR
 
|DR
 
|Service
 
|Service
|Forward (un)subscription error message received from DT to DE.
+
|The (un)subscription error message received from Data Transferor is forwarded to the Data Evaluator.
 
|-
 
|-
 
|'''Investigate reason for (un)subscription error'''
 
|'''Investigate reason for (un)subscription error'''
 
|DE
 
|DE
 
|User
 
|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)
+
|The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
 
|-
 
|-
 
|'''Forward confirmation'''
 
|'''Forward confirmation'''
 
|DR
 
|DR
 
|Service
 
|Service
|Forward the confirmation on the (un)subscription request (received from the DT) to the DE.
+
|The confirmation on the (un)subscription request (received from the DT) is forwarded to the Data Evaluator.
 
|-
 
|-
 
|'''Log (un)subscription information'''
 
|'''Log (un)subscription information'''
Line 121: Line 127:
 
|Service
 
|Service
 
|The confirmation is logged to complete the audit trail.
 
|The confirmation is logged to complete the audit trail.
 +
  
 
Note: register in a way that it is easily readable (optional: include subscription id).
 
Note: register in a way that it is easily readable (optional: include subscription id).
Line 127: Line 134:
 
|DT
 
|DT
 
|Service
 
|Service
|Technical validation (xml validation and check on DE authorisation).including forwarding to data owner. Technical exception out of scope
+
|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.
 +
 
 +
 
 +
Technical exceptions are out of scope.
 
|-
 
|-
 
|'''Evaluate (un)subscription request'''
 
|'''Evaluate (un)subscription request'''
 
|DO
 
|DO
 
|Service
 
|Service
|Functional check of request to subscribe: does company exists, are type of events/subscription supported.
+
|The (un)subscription request is evaluated to check if the request can be completed:
 +
 
 +
* Subscription functional checks: does subject exists, is event catalogue supported.
  
Functional check of request to unsubscribe: does subscription exists.
+
* Cancel subscription functional checks: does subscription exists.
  
If the request does not pass the functional check, the request is rejected.
+
 
 +
If the request does not pass the functional checks, the request is rejected and an error message will be send.
 
|-
 
|-
 
|'''Prepare (un)subscription error message'''
 
|'''Prepare (un)subscription error message'''
 
|DO
 
|DO
 
|Service
 
|Service
|Collect the content (mainly the link to the request and the error message) and send it to DT
+
|Collect the content of the error message and send it to the Data Transferor (if applicable).
 +
 
 +
 
 +
The (un)subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the errorcode.
 
|-
 
|-
 
|'''Send (un)subscription error message'''
 
|'''Send (un)subscription error message'''
 
|DT
 
|DT
 
|Service
 
|Service
|Forward to DR.
+
|The error message is forwarded to the Data Requestor from who the request was received.
 
 
 
 
Message contains: participant id of subscriber, subject identifier, request type, reference to the request message, full request message, error
 
 
|-
 
|-
 
|'''Register (un)subscription'''
 
|'''Register (un)subscription'''
 
|DO
 
|DO
 
|Service
 
|Service
|Data owner creates/ends the DE’s subscription on the company’s events.
+
|The Data Owner creates, changes or ends the subscription according the (un)subscription request.
 
 
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 events needed.
 
 
|-
 
|-
 
|'''Confirm (un)subscription'''
 
|'''Confirm (un)subscription'''
 
|DO
 
|DO
 
|Service
 
|Service
|Create a confirmation: (un)subscription result (success), timestamp, link to (un)subscription request and send to DT (if applicable)
+
|The confirmation of the (un)subscription is created and send to the Data Transferor (if applicable).
 +
 
 +
 
 +
The confirmation message contains: (un)subscription result (success), timestamp of (un)subscription, (un)subscription request reference, original (un)subscription request message.
 
|-
 
|-
 
|'''Send (un)subscription confirmation'''
 
|'''Send (un)subscription confirmation'''
 
|DT
 
|DT
 
|Service
 
|Service
|Send confirmation to DR
+
|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.
 
 
 
 
Log confirmation
 
|}
 
 
 
==== Subscription messages ====
 
 
 
===== Message ‘Subscription request’ =====
 
{| class="wikitable"
 
|'''Element'''
 
|'''Description'''
 
|'''M/O'''
 
|'''Example value'''
 
|-
 
|Legal Person Identifier
 
|Identification of the company following the eIDAS regulation:  country code / country code / company identifier
 
|O
 
|RO/AT/90000471
 
|-
 
|Requested action
 
|Indicates whether a subscription or the cancellation of a subscription  is requested by the sender: ‘subscribe’ or ‘unsubscribe’
 
|M
 
|subscribe
 
|-
 
|Participant ID
 
|The OOP TS participant identifier that identifies the organisation that is the subscriber (and thus will receive business event notifications)
 
|O
 
|SE000000013
 
|-
 
|Business event type
 
|The business event to subscribe to. If omitted, subscribe to all business events
 
|O
 
|
 
|-
 
|Legal person identifier
 
|Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register.
 
|M
 
|
 
|-
 
|Subscription period
 
|The period for which the subscription is valid. If omitted subscription is valid until a unsubcribe request.
 
|O
 
|
 
|-
 
|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
 
|
 
|
 
|-
 
|Subscriber identification
 
|
 
|
 
|-
 
|Error message
 
|Subscribe: company unknown, (participant not authorized)
 
 
 
Unsubscribe: company unknown, company not active, subscription unknown,  subscription not active
 
 
 
>move this text to subpage DBA
 
|
 
|-
 
|Subscription request reference
 
|
 
|
 
 
|}
 
|}
  
Line 309: Line 205:
  
 
''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.
 
''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
 +
 +
==== Subscription register requirements ====
  
 
===== Evidence exchange and subscription request =====
 
===== Evidence exchange and subscription request =====

Revision as of 14:16, 12 May 2021

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

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

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. That is reversing the responsibilities.

DBA investigated the situations covered by the DBA and in contrast to what is covered by BRIS. For example: DBA covering more than branches, and more types of companies.

Delimitation to BRIS

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. That is reversing the responsibilities.

Business Process

Event Subscription

Business Process

DE4A D2.5 PSA 0.8 evt.jpg

Activity Table

Activity / UC Role Type* Description
Trigger initiate subscription Public Service Procedure User 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:
  • subject identifier
  • data owner identifier
  • subscriber identifier
  • event catalogue
  • action 'subscribe'
  • subscription start and end date


The subscription need is forwarded to the Data Requestor (if applicable).

Trigger cancel subscription eProcedure / Public service / Notification Service Potential triggers to cancel a subscription are:
  • Public service: public service delivery 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 Service To cancel a subscription data is collected and the cancel subscription need is formulated:
  • subject identifier
  • data owner identifier
  • subscriber identifier
  • event catalogue
  • action 'cancel subscription'
  • subscription end date


The cancel subscription need is forward to the Data Requestor (if applicable).

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 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 The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.


The subscription / cancel subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).

Forward (un)subscription error DR Service The (un)subscription error message received from Data Transferor is forwarded to the Data Evaluator.
Investigate reason for (un)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 (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 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.


Technical exceptions are out of scope.

Evaluate (un)subscription request DO Service The (un)subscription request is evaluated to check if the request can be completed:
  • Subscription functional checks: does subject exists, is event catalogue supported.
  • Cancel subscription functional checks: does subscription exists.


If the request does not pass the functional checks, the request is rejected and an error message will be send.

Prepare (un)subscription error message DO Service Collect the content of the error message and send it to the Data Transferor (if applicable).


The (un)subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the errorcode.

Send (un)subscription error message DT Service The error message is forwarded to the Data Requestor from who the request was received.
Register (un)subscription DO Service The Data Owner creates, changes or ends the subscription according the (un)subscription request.
Confirm (un)subscription DO Service The confirmation of the (un)subscription is created and send to the Data Transferor (if applicable).


The confirmation message contains: (un)subscription result (success), timestamp of (un)subscription, (un)subscription request reference, original (un)subscription request message.

Send (un)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.

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

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 subscrition 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 tehir common event list includign a clear semantic explanation of each business of 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
Annual report event Annual reports Annual report
Directors disqulification event Disqualifications updated for directors Directors disqulification
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, aquring 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 (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:
  • 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 User Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event.
Identify event DO Service The DO determines the DE4A Business event name.


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 Check the subscription register 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
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.


Log received message as part of audit trail?

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:

  • Company identifier
  • Notified event
  • Request id
  • Determined response
  • Timestamp of determination
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.
Evidence update event triggered 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 M/O Example value
Legal Person Identifier Identification of the company following the eIDAS regulation: country code / country code / company identifier O
Business event identification The identification of the business event (list of value: OOP TS business event catalogue) O
Business event timestamp Date and time of business event M 2021-05-01 15:01:27
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 O
Legal person identifier Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register. M SEBOLREG.5560802
Second legal person identifier Identification of a second company or a second EUID, used for example if the original EUID is changed O SEBOLREG.5594521
Business event type The business event that triggered the notification, see Event - evidence mapping table above. M National merger
Business sub event type The subtype of the business event. O Initiated

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