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