ESPD Architecture and Procurement Procedure Steps

ESPD Architecture Overview

The purpose of the ESPD Exchange data model (ESPD-EDM) is to assist developers in the creation of an ESPD Service by providing a model. This ensures that the ESPD Request and the ESPD Response files produced across all ESPD Services are consistent, and comply with the relevant legislation.

Key components and standards were adopted in alignment with related projects in European public procurement such as EU Vocabularies and eCertis:

  • UBL

  • UML

  • A data structure

  • XSL(T)

  • XML

Below is a high level overview of the ESPD Architecture.

ESPD Architecture Overview

Figure 1. ESPD Architecture Overview

The ESPD Architecture components interact with each other to produce the final ESPD UBL XML Request and Response.

This describes the UBL language that is used to define the ESPD Request and Response XML elements, and attributes of XML elements.

  • The UML component

This describes the Request and the Response model elements and their attributes, relationships between elements, and relationship cardinalities. There is a BOV (Business Oriented View) model and a TOV (Technical Oriented View) model. The TOV describes the UBL layer.

  • The ESPD Criterion Data Structure component

This describes each Request and Response criterion and its hierarchical tree structure of descriptive elements. It is maintained in MS Excel format file then transformed (saved) into an ODS (Open Document) file, from which an initial XML file is extracted. From the XML file an ESPD UBL XML file is generated using XSLT transformation rules. This is an internal process that provides standard xml documents for developers to refer to (provided on GetHub). Developers also have the possibility to generate their own xml files using the The ESPD Demo tools which enables them to create custom xml files based on their own scenarios.

  • The ESPD UBL XML component

This describes the resulting ESPD UBL XML files for the Request (generated by the Buyer or CA -contracting authority-) and for the Response (generated by the EO -economic operator-). These are generated by XSLT transformations applied to the related Criterion ODS XML file.

  • The ESPD Codelists Data Structure component

This describes, in MS Excel format, the attribute-value structure of the codes for each code list used in the ESPD project. The MS Excel file is transformed (saved) as an XML Spreadsheet file, from which the ESPD Codelist Generic Code files are generated using XSL transformation rules.

  • The ESPD Codelists generic code component

This describes the resulting ESPD Codelists generic code files produced by the XSL transformations applied to the related Codelists XML file.

  • The ESPD Validation component.

This validates the generated files produced (ESPD Request UBL XML, ESPD Response UBL XML, ESPD Codelists Generic Code) against a UBL schema and a set of ESPD specific rules. This allows the high level validation of ESPD documents produced by the various ESPD Services implemented by different member states. The validation tool (testbed) can be found here online.

ESPD Procurement Procedure Steps

The set of tasks for the whole procurement procedure are summarised in the following figures.

The Buyer or the Contracting Authority (CA) initiates a procurement procedure.

Buyer Planning

Figure 1_a. Buyer Planning

The Buyer launches a Request.

Buyer Request

Figure 1_b. Buyer Request

Economic Operators (EO) respond to the (officially published) Request.

EO Response

Figure 1_c. Economic Operator (EO) Response

Finally, the Buyer and the EO interact to conclude the procurement procedure.

Buyer and EO

Figure 1_d. Buyer and EO

Example XML Request and Response files

Example XML files can be generated using the ESPD Demo Development Tools. This is a useful facility that allows developers to generate different request and response XML files based on individual/ specific scenarios. These can then be used to facilitate understanding of their development task and to test their code.