/ EUROPEAN COMMISSION
DIRECTORATE-GENERAL
INFORMATICS
Information systems Directorate

European Commission

e-Procurement Section, DIGIT B4

e-PRIOR Customer Interface Control Document

Date: / 17/09/2012
Version: / 2.100
Authors: / e-PRIOR project team
Revised by: / Didier Thunus (European Commission, DIGIT B4)
Approved by:
Public:
Reference Number:
Single point of contact for support:

Table of Contents

1. Introduction

1.1. Purpose of the Customer Interface Control Document

1.2. Scope of this Document

1.3. Audience of this Document

1.4. Definitions, Acronyms, and Abbreviations

2. High-Level Architectural Mechanisms

2.1. Architectural Mechanisms of the documents to be exchanged

2.1.1. Reusable Schema Definitions

2.2. Architectural Mechanisms of the e-PRIOR Interface

2.2.1. Message Façade

2.2.1.1. Design by Contract

2.2.2. Content Based Routing

2.3. Architectural Mechanisms of the Communication Model

2.3.1. Asynchronous Mode (Synchronous Write / Synchronous Read)

2.3.2. Synchronous Mode

2.3.3. Notification Mode

3. Service Portfolio

3.1. User Profiles

3.2. Description of User Profiles

3.2.1. Read Services

3.2.2. Write Services

3.3. Communication Mode Detailed Description

3.3.1. Communication Mode Scenarios

3.3.2. Communication Mode Transport Protocol

Asynchronous Mode (Synchronous Write / Synchronous Read)

Synchronous Mode

Notification Mode

4. End-to-end Communication Workflows

4.1. Invoice

4.2. Credit Note

4.3. Attached Document

5. Realization

5.1. XML Schema Definitions

5.1.1. XML encoding

5.2. Boundary Interface Design Model

5.2.1. Message Bus Façade

5.2.1.1. WSDL types part

5.2.1.2. WSDL messages part

5.2.1.3. WSDL ports part

5.2.1.4. WSDL binding part

5.2.1.5. Binary Attachments

5.2.2. Content Based Routing

5.3. Security Considerations

5.3.1. Security Problem Statement

5.3.2. Operand Security Model

5.3.3. Boundary Interface Security Model

5.3.4. Communication Mode Security Model

5.4. Document Processing Considerations

5.4.1. Maximum Message Size

5.4.2. Unique Message ID and Reliable Message Delivery

5.4.3. What is the role of the message ID?

5.4.4. Transactions Atomicity

6. Appendix I: Glossary of Terms

Table of Figures

Figure 1 e-PRIOR multi-sided platform

Figure 2 Billing processes within the e-Procurement domain

Figure 3 Billing documents tree

Figure 4 Read Use Cases of e-PRIOR

Figure 5 Use Cases of the Back-Office following a Retrieve Request

Figure 6 Write Use Cases of e-PRIOR

Figure 7 e-Invoice scenario

Figure 8 Invoice communication workflow

Figure 9 Credit Note communication workflow

Figure 10 Attached Document communication workflow

Figure 11 UBL Documents Architecture

Figure 12 EC UBL subset: The default UBL document namespaces are used in most documents exchanged in e-PRIOR’s Write Services

Figure 13 Snippet of the UBL Payload in the context of a CEN/ISSS WS/BII Billing Profile

Figure 14 EC UBL subset: Custom document namespaces are used in most documents exchanged in e-PRIOR’s Read Services

Figure 15 UBL two-phase document validation

Figure 16 XML encoding

Figure 17 WSDL 1.1 Structure

Figure 18 WSDL types part

Figure 19 WSDL message part submitted from the Customer to e-PRIOR

Figure 20 WSDL message part submitted from e-PRIOR

Figure 21 WSDL fault message

Figure 22 SOAP fault of the Client type

Figure 23 SOAP fault of the Server type

Figure 24 WSDL ports part

Figure 25 WSDL binding part

Figure 26 SOAP Envelope Structure

Figure 27 WSDL binding part input/output

Figure 28 SOAP Body

Figure 29 MIME header at HTTP level

Figure 30 SOAP message with Attachment Part

Figure 31 SOAP Header

Figure 32 User Access Process

Figure 33 Interchange Agreement

Figure 34 Message ID

Document History

Version / Date / Comment / Modified Pages
0.001 / 11/06/2010 / First draft / All pages
0.002 / 17/06/2010 / Implementation of internal comments / As required
0.003 / 18/03/2011 / Update throughout the document / As required
0.004 / 10/02/2012 / Update throughout the document / As required
0.005 / 12/07/2012 / Update throughout the document / As required
2.000 / 1/08/2012 / Update to services v2.0 / As required
2.001 / 17/09/2012 / Corrected document states in chapter 4 (End-to-end communication workflows) and added implementation notes.
Updated links to FAQs. / Section 4.1, 4.2 and 4.3.
As Required.

1.Introduction

Public procurement accounts for 16% of GDP in OECD member countries. It is a versatile mechanism that can be used to pursue several aims such as process efficiency, innovation or social goals.

Across the EU, the uptake of e-Procurement is variable and the objective of transitioning to 100% e-Procurement is far from complete. In March 2010, the European Commission launched the Europe 2020 Strategy to turn the EU into a smarter, more sustainable and inclusive economy. The Digital Agenda for Europe, successor of the i2010 policy framework, is one of the seven flagship initiatives of Europe's 2020 Strategy. One of these key challenges is precisely the inter-connection of e-procurement communities in the EU. In order to bridge the gap between the costs of creating an e-Procurement infrastructure, the resources which are available, and to ensure its use to all Directorate Generals and Services of the European Commission, e-PRIOR was built by the Director General for Informatics (DIGIT).

DIGIT writes this document to demonstrate how e-PRIOR can be used to e-enable the existing Back-Office systems of the several European Commission and Services. The role of the European Commission, in addition to the creation of e-Procurement policy, is to lead by example.

1.1.Purpose of the Customer Interface Control Document

Customer and Supplier are the two key roles involved in the several e-Procurement processes. To interconnect them, e-PRIOR exposes an interface to the Information Systems used by Suppliers and another one to the information systems used by Customers. Conceptually, e-PRIOR is a multi-sided platform bringing together these two distinct but interdependententities. The value of e-PRIOR is to facilitate interactions between them. In brief, e-PRIOR is an intermediary between the information systems of these business partners. In this context, the Directorate Generals, or Services, of the European Commission play the Customer role.

Figure 1 e-PRIOR multi-sided platform

While [REF1] specifies the interface exposed to Suppliers, this document describes the interface exposed to the internal systems of the European Institutions. Throughout this document they will be called "the Back-Office". In this document, a service should be understood as an abstract resource exposed by e-PRIOR and consumed by aBack-Officeor, vice versa, exposed by aBack-Office and consumed by e-PRIOR.

A service is a mechanism to enable digitisationof one or more e-Procurementprocesses, where the access is provided using e-PRIOR’s interfaceand is executed consistent with the constraints and policies specified in this document. In this context, servicesare provided by DIGIT – the service provider – for use by the Directorate Generals, or Services, of the European Commission. The services of e-PRIOR are opaque since their implementation is hidden from their consumers, except for the information model exposed through the interface itself and the other technical information required to determine whether a given service is accessible by them.Interacting with the services of e-PRIOR involves sending and receiving messages. The information model andthe sequence of exchangesare explained in detail in the next chapters.

The same Back-Office can be used by several Customers. e-PRIOR considers the Back-Office as a User and the Customer as a Business Partner. A Back-Office may serve several Customers. Each Business Partner is identified through a unique identifier. The Back-Office is given a Username and Password. A message sent by the Back-Office can only refer to one Business Partner.

As explained above, each Directorate General or Service of the European Commission connected to e-PRIOR is given a unique identifierto make itself known to the Suppliers submitting documents in electronic format to e-PRIOR.It goes without saying that the Supplier must always indicate, in the electronic message, the ID of the Directorate General or Service responsible for the business verification and approval of the document. As a result, and following a number of pre-emptive checks, e-PRIOR can easily route it to the Back-Office of the final receiver within the European Commission[1].Once a document is received and processed by the Back-Office, the response from the Customeris also delivered to the Supplier via e-PRIOR. In this case, the Customer must indicate, in the electronic message, the ID of the Supplier to which the business response is addressed. The end-to-end communication workflows are included in chapter4.

1.2.Scope of this Document

This document covers the service interface of e-PRIOR. It includes information about the transmissionprotocol, information model and the sequence of exchanges. This specification addresses no more than the service interface of e-PRIOR. All other aspects of its implementation are of no concern to the Back-Office (i.e. the service consumer). The ICD specification provides both the provider (i.e. the implementer) of the services and their consumers with a complete specification of the following aspects:

  • Interface Functional Specification, this specifies the set of services and the operations provided by each service;
  • Interface Behavioural Specification, this specifies the expected sequence of steps to be respected when calling a service or a set of services;
  • Interface Message standards, this specifies the syntax and semantics of the data and metadata;
  • Interface Policy Specification, this specifies constraints and policies regarding the operation of the service.

Although e-PRIOR embraces the full post-award procurement domain; this documentis limited to the service model of the Billing business process. Traditionally, billing is initiated by the Supplier when invoicing the Customer for delivered goods or services. The messages to be exchanged between e-PRIOR and the Back-Office are provided in a separate annex to this document. Several annexes, also present in [REF1], should be used for the understanding of these schemas, in particular, the FAQ and Data Dictionary.

Figure 2 Billing processes within the e-Procurement domain

1.3.Audience of this Document

  • The Directorate Generals and Services of the European Commission wanting to set up a connection between their Back-Office system and e-PRIOR for e-invoice enablement are the target audience of this document. In particular:
  • Business Architects will find it useful for determining how to best exploit e-PRIOR to create a fully fledge e-Procurement solution.
  • Analysts will find it useful to understand the Use-Cases of e-PRIOR.
  • Architects will find it useful as a starting point for connecting a Back-Office system to e-PRIOR.
  • Developers will find it essential as a basis of their development of e-Procurement services.
  • The reader of this document is recommended to read chapter §1, §2 and §3 of[REF1]. Thesechapters contain all the background information required for the proper understanding of the servicesprovided by e-PRIOR.

1.4.Definitions, Acronyms, and Abbreviations

The glossary in section 6provides the reader with the terms used in this document.

Reference Documents

The table below provides the reader with the list of reference documents.

Reference / Document
[REF1] / e-PRIOR Interface Control Document- if clicking this link does not refer you immediately to the correct location on CircaBC, enter the following link directly in your web browser:
[REF2] / OASIS Universal Business Language v2.0
[REF3] / ebXML (Electronic Business using eXtensible Markup Language)
[REF4] / CEN Business Interoperability Interfaces for Public procurement in Europe
[REF5] / W3C Web Services Architecture
[REF6] / European Interoperability Framework v.1.0 (EIF)
European Interoperability Framework v2.0 (Draft EIF)
[REF7] / Rational Unified Process version 7.5
[REF8] / Web Services Description Language (WSDL) 1.1
[REF9] / WS-I Basic ProfileVersion 1.1
[REF10] / Simple Object Access Protocol (SOAP) 1.1
[REF11] / XML Schema 1.1
[REF12] / Extensible Markup Language (XML) 1.0
[REF13] / Hypertext Transfer Protocol 1.1
[REF14] / HTTP Authentication: Basic and Digest Access Authentication
[REF15] / HTTP Over TLS
[REF16] / NES
[REF17] / Schematron
[REF18] / SOAP Messages with Attachments
[REF19] / CEN ISSS WS BII
[REF20] / GLN (Global Location Number) (also know as EAN)
[REF21] / ISO Schematron
[REF22] / RFC2119
[REF23] / Reference Model for Service Oriented Architecture 1.0

2.High-Level Architectural Mechanisms

2.1.Architectural Mechanisms of the documents to be exchanged

2.1.1.Reusable Schema Definitions

Since compliance to legal and business regulations iscrucial in B2G interactions, the several exchanged documents must have a common agreed-upon syntax and semantics. This mechanism allows the Customer to use documents assembled upon standard schemas which conform to a well-defined library of reusable data components.This approach promotes an enterprise-wide semantic model, implemented in standard schemas which decisively contribute to standard messages and therefore a stable interface.

2.2.Architectural Mechanisms of the e-PRIOR Interface

2.2.1.Message Façade

This mechanism allows the Customer, when using the aforementioned services, to dialogue with a unique system (i.e. e-PRIOR) using a unified interface via electronic messaging (i.e. e-PRIOR) instead of connecting to several internal systems of the European Commission. This approach promotes loose coupling and document-driven exchange of information.This approach ensures that high-volume, low latency, services are delivered competitively – in terms of cost, quality and timeliness. By doing so, they enable that Customers receive high quality services which adhere with European standards.

2.2.1.1.Design by Contract

This specification addresses no more than the service interface of e-PRIOR. All other aspects of its implementation (e.g. specific information on the software or hardware technology, physical location, etc…) are behind the scenes and are of no concern to the requester entity (i.e. the service consumer). This concept is also known as loose coupling.The use of Service-oriented architecture (SOA), promotes the use of a simple yet powerful technique, Design by Contract, that focuses on the agreement to the rights and responsibilities of each system based on the description of a service i.e. the Use-Case.

2.2.2.Content Based Routing

This mechanism allows the Supplier to send its documents to the relevant endpoint of e-PRIOR and have this document accurately routed, based on the message content, within the several European Institutions. The same happens when the Customer submits a document to a Supplier via e-PRIOR. This approach promotes orthogonality; things that are not related conceptually are not dependent of each other once implemented by a system.

2.3.Architectural Mechanisms of the Communication Model

2.3.1.Asynchronous Mode (Synchronous Write / Synchronous Read)

This mode allows the Back-Office to periodically check whether e-PRIOR has messages addressed to its Customers, fetch and process them. Each successful Write Request from the Supplier (e.g. Invoice. submission) leads e-PRIOR to store the message until the Back-Office retrieves it. During this period the Supplier benefits from read requests to follow-up on the business result of the write request and ultimately pull the content of its result.

2.3.2.Synchronous Mode

A number of read services are available to allow the Supplier to quickly know whether there are messages to be retrieved. Thus, e-PRIOR uses its business logic and without delay passes the result to the requester. This mode of communication is aimed at services of informational nature.

2.3.3.Notification Mode

This mode allows the Supplier to be notified about certain events; e.g. when an outbound message is made available to the Supplier by e-PRIOR.

3.Service Portfolio

3.1.User Profiles

“Profile” is a fundamental concept of this specification. The CEN/BII workshop [REF4]has defined a profile as “A specification of how one or more Business Processes are executed by specifying the business rules governing its business collaborations and the information content (data model) of the electronic business transactions exchanged.”

A profile has three key aspects:

  • Choreography, sequence of message exchanges foreseen in the profile;
  • Data content, transaction data model nominated by the profile;
  • Business rules, rules required by each transaction.

Within the Billing business process, two profiles are commonly used: the Invoice Only and the Billing Profiles.

Profile ID / Profile Name / Purpose of the Profile
BII04 / Invoice Only / This profile only includesthe sending of electronic Invoices by Suppliers. In the context of the European Institutions, the Customer responds to an Invoice with an Application Response.
BII05 / Billing / This profile describes a process comprising the sending of electronic Invoices and, eventually, Credit Notes by Suppliers. In the context of the European Institutions, the Customer responds to these documentswith an Application Response.
Attachment / The Supplier may also send Attached Documents to the Invoice or Credit Note. In the context of the European Institutions, the Customer responds to it with an Application Response.

The full set of business documents in the context of the billing process,isshown below.

Figure 3Billing documents tree

Regarding the Dispute document

The following documents are not included in the Profiles described in the table above. These documents will continue to be sent to the Supplier on paper via the postal service:

Dispute Notice: Following the dispute of an Invoice, the official dispute notice will be sent to the Supplier on paper via the postal service. The Supplier is informed electronically that the Invoice is disputed once it retrieves, from its Inbox, the Application Response linked to the disputed Invoice. This Application Response will not contain the details about the dispute itself. The Application Response will simply state that the Invoice is disputed. Once the paper dispute is received, the Supplier may resolve the dispute via electronic means using the services exposed by e-PRIOR (e.g. Credit-Note Service).

Debit Note: If total payments made exceed the amount actually due under the Specific Contract or if recovery is justified in accordance with the terms of the Contract, the Contractor shall reimburse the appropriate amount in euro on receipt of the debit note on paper via the postal service, in the manner and within the time limits set by the Commission.

For implementing the above Profiles two kinds of services must be implemented.

  • Read Services:this is the set of services to be consumed by the Back-Office when consulting messages sent by the Suppliers to them. The Back-Office must implement the read services to be able to receive the business documents shown above. This is a two-step process:
  • The Back-Office calls the Inbox Service to know the list of messages addressed to its Customer or Customers. The Query Service may be used for the same purpose.
  • The Back-Office retrieves, one-by-one, the messages listed above through the Retrieve Service:
  • A Back-Office that supports BII5 must be able to retrieve and understand:
  • Invoices;
  • Credit Notes and
  • Attached Documents.
  • A Back-Office supporting BII04 does not support Credit Notes.

Independently of the Profiles shown above, the Back-Office must implement both of these services.