Page History
...
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 depicts how the two targets play together.
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 to 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.
- eNotice: Notice Interface
- eAccess: Bidder Interface
- eEnquiry: Bidder Interface
- eSubmission: Bidder Interface
- eAward: Bidder Interface
...
Technically, the Bidder Interface is specified as a SOAP web service (see Figure 1). 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 1 - Technical implementation of the XVergabe Bidder Interface as SOAP web service.
The interface is implemented on both sides: the bidder 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.
Operation |
| Description |
|---|---|---|
subscribe | By calling this operation, a bidder can subscribe a tendering procedure. After subscription, he is able to retrieve messages concerning the procedure by calling getMessages. | |
sendMessage | By calling this operation, a bidder can send messages to the platform. Such messages include offers and inquiries (see Table 2). | |
getMessages | By calling this operation, a bidder can retrieve all messages from the platform directed at him concerning a specified tendering procedure. A message may contain a reference to a document file that the bidder can download via getDocument. | |
getDocument | By calling this operation, a bidder can download binary documents from the platform (tendering documents, answers to inquiries, ...). | |
getTenderIDs | Returns a list of the IDs of all tendering procedures the bidder has subscribed for. These IDs are needed to call the other operations. |
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
...