Overview of XVergabe

Background

The adoption of electronic tendering within the European Union is with approx. 13% compared to the targeted 50% within the year 2010 still very low. A research paper from the Deutsche Bank beginning 2011 comes to the conclusion that between € 50 bn. and € 70 bn. could be saved within the EU each year if there would be a full transition to eProcurement. Nevertheless a full transition to eTendering without enabling interoperability would not do as there are already more than 330 platforms spread over Europe. While for contracting authorities (CAs) this is not a problem as they use only one platform an economic operator (EO) must learn to use all those 330 platforms to participate all call for tenders.

The project XVergabe

The goal of XVergabe is to create a sustainable basis for electronic interoperability between EOs and CAs. The result of the project makes it possible that from one bid client an EO can access all compatible eTendering platforms. Instead of learning 330 platforms the EO has to learn only one. This will lead not only to a much higher satisfaction on the side of an EO but also on the buyer's side.

Overview

The project hast two main targets to achieve this interoperability. The first one is to provide an interface for exchanging notices and the second one to communicate between a bid client and an eTendering platform. The following figure 1 depicts how the two targets play together.

Figure 1 - Overview of the Interfaces provided by XVergabe

The figure shows that an EO uses only one client to access all the platforms. In order to find all opportunities an XVergabe proxy is important. The proxy translates notices between two formats. In this example it retrieves it in the XVergabe format and translates it to the TED format. It can be accessed by all eTendering platforms. The notice interface has all relevant technical information to identify the procedure on a certain eTendering platform. The bidder interface covers all necessary process steps to enable full electronic communication. From subscription (eSubscription) of a certain procedure, downloading tender documents (eAccess), making question and answers (eEnquiry), submitting bids (eSubmission) up to awarding (eAwarding) are possible (see Figure 2).

Figure 2 - Processes covered

• eNotice: Notice Interface
• eSubscription: Bidder Interface
• eAccess: Bidder Interface
• eEnquiry: Bidder Interface
• eSubmission: Bidder Interface
• eAward: Bidder Interface

XVergabe Bidder Interface

The XVergabe Bidder Interface defines a set of operations for end to end communication that are provided by a tendering platform and invoked by a bid client. Additionally, the interface defines a set of messages that can be exchanged between bidder client and platform with these operations.

Technically, the Bidder Interface is specified as a SOAP web service (see Figure 3). SOAP defines the protocol of the message exchange between bidder client and tendering platform. To define the structure of the exchanged messages, XSD (XML Schema Definition) is used. The exchanged messages themselves are represented in XML that meets the requirements of the XSD schema.

Figure 3 - Technical implementation of the XVergabe Bidder Interface as SOAP web service.

The interface is implemented on both sides by solution providers: the bid client (active) and the tendering platform (passive). Communication between client and platform is always initiated by the client. The client uses one of the provided web service operations to send messages to the platform. The platform processes these messages and creates responses directed at the client. Since the communication is unidirectional, the client has to retrieve the messages directed at it, similar to using a mail client to retrieve mail from mail server.

Webservice Operations

The XVergabe Bidder Interface specifies five web service operations. Table 1 summarizes the function of each operation. The web service operations are specified in the file xvergabe-service.wsdl.

Table 1 - Web service operations provided by the XVergabe Bidder Interface.

Messages

The operations sendMessage and getMessages define a relatively open interface for exchanging messages between bidder client and tendering platform. Table 2 lists the type of messages that can be exchanged. Some messages are to be sent from client to platform, others from platform to client. The structure of the messages is specified in the file xvergabe-messages.xsd

Table 2 - Messages that are exchanged between bidder client and tendering platform via sendMessage and getMessages.

Scenarios

To illustrate the possibilities of the XVergabe Bidder Interface, the following sections describe the exchange between bidder client and platform in some exemplary scenarios.

Subscribing for an open Tendering Procedure

The scenario in Figure 4 shows how a bidder client can subscribe a tendering procedure and download the tendering documents using the XVergabe Bidder Interface.

1. The bidder subscribes to an open tendering procedure he is interested in. The client calls the subscribe operation on the platform to make his interest known. The platform registers his subscription in its database.
2. The bidder synchronizes his local data with the platform’s data to become up to date. The client calls the getMessages operation to retrieve all messages directed at the client’s user. The list of messages returned contains a TenderMetaInformation and an InvitationToTender for the tendering procedure he previously subscribed for. The TenderMetaInformation message contains all the data about the procedure the client needs. The InvitationToTender message contains the IDs of the tendering documents among other information.
3. The client recognizes that the InvitationToTender message contains IDs of tendering documents and calls getDocument with these IDs to download the documents from the platform. After the download, the bidder can review the downloaded tendering documents.

Figure 4 - Subscribing to a tendering procedure and downloading the tendering documents via XVergabe Bidder Interface.

Exchanging Questions & Answers

The scenario in Figure 5 shows how a bidder can send questions concerning a tendering procedure and receive the answers to the questions via the Bidder Interface.

1. The EO composes a set of questions (for example in the form of a PDF document) concerning a tendering procedure he previously subscribed for. These questions are sent to the platform by a call of sendMessage. The message is a ClientInquiry containing the questions document. The platform stores the questions document to be answered by the CA.
2. The contracting authority answers the questions and stores the answers in another document (again, this might be a PDF document) on the platform. Afterwards, the EO synchronizes his client to the platform. The client calls the getMessages operation and receives a ServerInquiry message (potentially among other messages). The ServerInquiry contains the ID of the answers document.
3. The client recognizes that the ServerInquiry contains the ID of a document and calls getDocument to download the document from the platform. The bidder can then review the answers.

Figure 5 - Sending Questions to a tendering procedure and receiving the answers.