Difference between revisions of "DBA 2nd iteration Solution Architecture"
Line 73: | Line 73: | ||
The OOP TS domain (WP5) shall provide the data requestor and data transferor with the components needed for cross-border subscription and notification messages. | The OOP TS domain (WP5) shall provide the data requestor and data transferor with the components needed for cross-border subscription and notification messages. | ||
− | In the MVP the DBA pilot uses one type of subscription message and one type on notification message that all DC’s and DP’s involved will use. This implies an update of the IEM (WP3). There will be just one data provider per Member state: the business register, where the subscription will be recored and where the cross border events are generated, which is the authentic source of company information. | + | In the MVP the DBA pilot uses one type of subscription message and one type on notification message that all DC’s and DP’s involved will use. This implies an update of the <span style="background:#FFFF00">IEM</span> (WP3). There will be just one data provider per Member state: the business register, where the subscription will be recored and where the cross border events are generated, which is the authentic source of company information. |
The DC will subscribe in one Member state at a time. | The DC will subscribe in one Member state at a time. |
Revision as of 10:50, 27 July 2021
Introduction
Approach: we follow the SA as was done for Intermediation (1st iteration)
Scope and focus
- Within scope
- Modify DO/DE Mocks for S&N en Lookup patterns
- Common component voor Cross-border subscriptions (optional for MS to use, i.e. not mandatory)
- Event Notification + Evidence Lookup flavour, in line with PSA 2nd iteration
- Outside scope
- Resend a subscription request in case of an error (instead the possibility to inspect the logs and manually resend a request is deemed sufficient (MVP))
- Include the Evidence in the notification (instead pure notification + lookup)
- Attribute Lookup
DE4A preconditions
Design choices
Describe what WON'T be implemented for the pilot as well as design choices (see also scope section)
eIDAS and OOP TS
DBA eIDAS solution
Process realisation
Mapping processes/activities to application services and components (PSA --> tables).
Component description
Classify components: DE/DO/Common component.
Requirements
Describe the requirements for application services.
Component Implementation
Describe the implementation of the components.
Expected logical interfaces
Describe the (logical) interfaces between the components.
DC specific solution
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DP specific solution
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DBA OOP TS solution
Maybe this is the place to insert explanation of the subscription application collaboration (and notification?), i.e. front-end/back-end w.r.t. notifications.
The shared solution for the OOP TS consists of all common functionality of the OOP technical system. Most of the common OOP TS components need to be implemented by the data requestor and data transferor, although the OOP TS uses central components as well.
Image might need an update
The OOP TS domain (WP5) shall provide the data requestor and data transferor with the components needed for cross-border subscription and notification messages.
In the MVP the DBA pilot uses one type of subscription message and one type on notification message that all DC’s and DP’s involved will use. This implies an update of the IEM (WP3). There will be just one data provider per Member state: the business register, where the subscription will be recored and where the cross border events are generated, which is the authentic source of company information.
The DC will subscribe in one Member state at a time.
Although the explicit request and the preview functions will be implemented by the DC in its eProcedure portal, DBA expects guidelines for doing so (MVP) and reference software to ease the implementation (second pilot run). That’s why the requirements for these functionalities have been included in this section.
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DC-specific solution
Probably makes sense to split (two images) in notification and subscription