Page History
XVergabe Whitepaper
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.
...
- 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.
...
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.
...
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.
- 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.
- 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.
- 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.