View
3
Download
0
Category
Preview:
Citation preview
TOOP use of AS4 in the solution Architecture
tcon, 20.06.2018
TOOPThe Once-Only Principle Project
1This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 737460
Contents
1. Introduction – what is TOOP
2. Concepts and architecture overview
3. The TOOP AS4 interface
2
1. INTRODUCTION – WHAT IS TOOP
Robert Krimmer, TOOP Coordinator
What is the Once-Only Principle?
Collecting & storing data only once
Streamlining processes by:
• Enabling automated data sharing
• Replacing redundant data entry andcollection with information requestsfrom original and authentic source
• Improving data reliability
Aim – apply the OOP to company-related procedures
Explore and demonstrate the
“once-only” principle (OOP)
Cross-border data exchange
Reduce administrative
burden
Focus on businesses and
public administrations
A Large Scale Pilot
• 21 Beneficiaries
from 21 countries
• 50+ Partners
– Public
Administrations
– Universities
– Companies
2. CONCEPTS AND ARCHITECTURE OVERVIEW
Lefteris Leontaridis, TOOP Piloting Manager
The cross-border OOP case (simplified)
8
Country A –OOP Layer
Country B –OOP Layer
TOOP Federation
Country B – Services LayerData Consumption
Country A – Data LayerBase Registers – Data Provision
Data Aggregators
Data Aggregators
How TOOP Pilots fit into the big picture
9
BUSINESS REGISTRIESAS DATA PROVIDERS
GENERAL-PURPOSE DATA SOURCES
DOMAIN-SPECIFICDATA PROVIDERS/AGGREGATORS
BUSINESS REGISTRIESAS DATA CONSUMERS
BRIS,EBR
DOMAIN-SPECIFICDATA CONSUMERS
DOMAINFEDERATION(Maritime,
eProc,etc)
National OOP Layer
National OOP Layer
TOOP Federation
Any eServiceAs Data Consumer
of Federations
National DataAggregators
National DataAggregators
The TOOP Pilot Areas and Use Cases
• Cross-border eServices for Business Mobility– eProcurement: Automatic retrieval of EO
qualification evidences– Business Licenses/Registration in another country– Retrieving Mandates and selected company data
• Connected Company Data– Exchange of Data between Business Registries
• Branch registration, branch lifecycle (e.g. filing accounts and other notifications)
– Providing Business Registry Data to external eGovernment Services in the MS
• Maritime Pilot– Online Ship Certificates– Online Crew Certificates
10
Simple Baseline Scenario: pull of data
11
DATA CONSUMER DATA PROVIDER
TOOP
Identify EO
Determine Data Requirements
Data Provider Capability
Prepare Data Request
Process Data Request
Prepare Data Response
Process Data Response
Translate Data Translate Data
Ensure Consent
Map Semantics
Discover Publish
Data Request
Send Receive
Data Response
Receive Send
VIEW & ACCEPT
VIEW & ACCEPT
Extended Baseline Scenario: Notify and push
12
DATA CONSUMER DATA PROVIDER
Aware of EO
Notification Capability
Process Notification
Prepare Notification
Prepare Data Update
Decision to accept Data
Subscribe Publish
Data Change Notification
Receive Broadcast
Send Receive
Event: EO Data Change
Data Change Acceptance
Process Acceptance
Process Data Update Data Update
Receive Send
Ensure Consent TOOP
Map Semantics
Translate Data
Re-use and enhance existing cross-border EU infrastructure
DATA CONSUMER DATA PROVIDER
Identify EO
Request EO Attributes eIDAS infrastructure
Provide EO Attributes
Request Company Data
Provide Company Data
eDeliveryinfrastructure
Additional Attribute Discovery, Mandates modelling etc.
OO profiling of Message Exchange, Dynamic Discovery etcetc.
Semantic mapping (e.g. eCertis)
CEF, ISATOOP
Ensure Consent
Detailed definition ofComponent Architecture
14
TOOP Message Exchange Date
ModelDP
DP
Where we are and where we are going
• Release of common specs and software components: May 18th, 2018
• Some countries already started implementation
• Expected implementations until September: SE, GR, IT, AT, SK
• More use case variations to be implemented in next versions
• Connecting to BRIS to access Business Registers
• Supporting the implementation of the Single Digitial Gateway implementation – and the Implementing Act.
15
3. THE TOOP AS4 INTERFACE
Jerry Dimitriou, Common Components Task Force Coordinator
TOOP AS4 GW back-end interface specification
TOOP AS4 GW backend interface
TOOP Backend Interface Requirements
• The interface should be based on an existing interface, already implemented by the vendors
• It should provide the information required to dynamically configure the AS4 Gateway (Dynamic Creation of P-Modes)
• It should facilitate the decoupling of the Dynamic Discovery Processes and their use in the AS4 gateways
• It should provide a full interaction between the backend and the AS4 Gateway– Submit, Notify on Error and on Success, Deliver
18
TOOP AS4 GW back-end interface specification
• Based on the CEF Conformance and Interoperability Testing (CIT) backend interface specification – aka the Kerkovi Interface.– Every vendor that wants to be tested for conformance on the CEF
AS4 profile, needs to implement the CIT Interface.
• Available at http://wiki.ds.unipi.gr/display/TOOP/TOOP+AS4+GW+Interface+specification
• The CIT messages are “simple” AS4 message– No security headers used– The messages are SOAP With Attachments (SwA) messages, where
each payload (e.g. business document) is carried as a separate payload in the Attachments part of the SwA and referred to (by their ID) from within the ebMS Messaging Header (//PartInfo)
– The routing information from the backend (e.g. destination party, service and action) are contained in the Message Properties of the User Message (//MessageProperties)
Message Exchange Process
21
1. C1 sends an Submit Message to C22. C2 sends Submission Response Message containing the
outcome of the submit action to C13. C2 sends the AS4 message to C3 using CEF eDelivery AS4
Profile4. C3 receives the message and sends an AS4 Receipt to C2. 5. C3 delivers the message to C4 using the Deliver Action6. C2 receives the AS4 Receipt from C3 and informs C1 using
the Notify action
TOOP AS4 GW back-end interface specification - Submit
• Submit Message: The message being sent from the DC to the AS4 Gateway. – Contains the full routing information for the
actual User message to be sent from the DC AS4 Gateway to DP AS4 Gateway.
– Service: http://www.toop.eu/edelivery/bit– Action: Submit
TOOP AS4 GW back-end interface specification - Submit
Property Name Required?
MessageId N
ConversationId Y
RefToMessageId N
ToPartyId Y
ToPartyIdType N
ToPartyRole Y
ToPartyCertificate Y
TargetURL Y
Service Y
ServiceType N
Action Y
• The message properties inherited from the CIT with three additional properties:• ToPartyIdType:
• Identification of the naming scheme of the used party identifier
• ToPartyCertificate:• The Certificate of the destination
gateway, to be used for encryption• Base64 encoded
• TargetURL• The URL address of the destination
AS4 gateway.
TOOP AS4 GW back-end interface specification – S-Response
• Submission Response Message: The message being sent from the AS4 Gateway to C1 after the submission of the message.
– Used to inform the back-end system on the result of the submit operation
– Service: http://www.toop.eu/edelivery/bit
– Action: SubmissionResult
TOOP AS4 GW back-end interface specification – S-Response
Property name Required Value Notes
RefToMessageId Y
Value of the //eb:MessageIdelement of the received Submit message
The reference could also be included directly in the ebMS message header using the eb:RefToMessageId element, but for alignment with the notification message a property is used.
Result Y Accepted or Error
MessageId C
The value of the //eb:MessageIdelement of the AS4 message resulting from this submission
This property SHALL be included when the SubmitResult property has value Accepted.If this property was already included in the Submit message the values should be the same. If the property was not include in the Submit message this property contains the messageId generated by the gateway.
Description C
Free text describing the reason why the submission was rejected.
This property SHALL be included when the SubmitResult property has value Error. It should describe the reason why the submission was rejected as clearly as possible to provide the
Implementation Guide
• The AS4 Gateways (C2), when receiving a submission message from (C1) shall:
– Create the P-Mode for sending to C3 on the fly, using the message properties found in the submission message in combination with the CEF eDelivery AS4 Profile
– Send the message using the new P-Mode
– Create and send Submission Response message to C1 to inform about submission result
26
TOOP AS4 GW back-end interface specification - Deliver
• Deliver Message: The message being sent from the Target AS4 gateway to the DP (data request) or DC (data response)– Contains the message that was received from
the other side (i.e. the source country).– Service: http://www.toop.eu/edelivery/bit– Action: Deliver
TOOP AS4 GW back-end interface specification - Deliver
Property Name Required?
MessageId N
ConversationId Y
RefToMessageId N
FromPartyId Y
FromPartyIdType N
FromPartyRole Y
ToPartyId Y
ToPartyIdType N
ToPartyRole Y
Service Y
ServiceType N
Action Y
TOOP AS4 GW back-end interface specification - Notify
• Notify Message: The message being sent from the Source AS4 gateway back to the back-end – Informs the back-end that the message was
successfully sent (or failed to be sent) to the target gateway (not the final recipient)
– Service: http://www.toop.eu/edelivery/bit– Action: Notify
TOOP AS4 GW back-end interface specification - NotifyProperty name Required Value Notes
MessageId Y//eb:MessageInfo/eb:
MessageId
RefToMessageId C//eb:MessageInfo/eb:
RefToMessageId
In case the Error message does not include a eb:RefToMessageId element the gateway SHOULD include the MessageId of the message to which the Error Message was a response.If no RefToMessageId is available the gateway SHOULD NOT send a notification to the back-end system.
Result Y Receipt or Error
For Errors only:If the AS4 Error message contains multiple eb:Errorelements, the gateway SHALL use the information from the first element for inclusion in the notification message.
ErrorCode Y//eb:Error/
@errorCode
ShortDescription C//eb:Error/
@shortDescription
The gateway MUST include this property if the attribute is available in the Error message
Severity Y//eb:Error/
@severity
Description N
//eb:Error/
eb:Description or//eb:Error/
eb:ErrorDetail
Thank you!
Questions?
Visit TOOP: toop.eu
TOOPThe Once-Only Principle Project
31This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 737460
BACKUP:SLIDESSOLUTION ARCHITECTURE AND COMMON COMPONENTS
Component Architecture (technical view – March 2018)
33
Component ArchitectureDC-side Integration
34
• TOOP DC Interface – Defined in an
Implementation Guideline
• TOOP Connector– The main CCTF
Component, providing the main functionality
• TOOP AS4 Interface– Based on the CEF CIT
Interface
Component ArchitectureDP-side integration
35
• TOOP DP Interface – Defined in an
Implementation Guideline
• TOOP Connector– The main CCTF
Component, providing the main functionality
• TOOP AS4 Interface– Based on the CEF CIT
Interface
Component ArchitectureTOOP Connector (extended)
36
Module Function Communicates with
Message Processor Main Orchestration Engine MS TOOP Interface
Semantic Mapping Module Communicates with the Semantic Mapping Service to get mappings between different concepts
Semantic MappingService
Dynamic Discovery Module
Extracts the Routing Metadata for the Messages to be submitted
TOOP Directory, BDXL, SMP
Message Exchange Module Creates the AS4 Message and submits it using the CIT Interface
AS4 Gateway
Component ArchitectureMS Infrastructure Components
37
Key Functionality MS Components Consumed by
Dynamic Data Discovery SMP Service TOOP Connector
Data Subject Identification eIDAS Node MS DC System
Component ArchitectureCentral Components
38
Key Functionality Central Component Implemented by Consumed by
Dynamic DataDiscovery
TOOP Directory PEPPOL / TOOP CCTF TOOP Connector
CEF BDMSL (BDXL) CEF TOOP Connector
Semantic Mapping Semantic Mapping Service TOOP CCTF TOOP Connector
Recommended