Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Die Spezifikation der Schnittstelle kann als ZIP-Datei heruntergeladen werden. Die Inhalte werden im Rahmen dieser Dokumentation abgefasst und beschrieben. |
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Nachfolgend wird die XVergabe-Kommunikationsschnittstelle in der Version 4.6 beschrieben. Diese Version basiert auf dem Stand der Schnittstelle mit der Versionsbezeichnung „15.01“, die dem IT-Planungsrat bekanntgemacht wurde und auf der der IT-Planungsrat im Juni 2015 anlässlich seiner 17. Sitzung die Entscheidung 2015/18 über die Einführung der XVergabe als nationalen Standard getroffen hat. Die damalige Version 15.01 musste fortgeschrieben werden, um die Produktionssetzung des Standards sicherstellen zu können. Diese Fortschreibung wurde im Rahmen der Betriebsorganisation XVergabe durchgeführt und ist hier beschrieben. Der Versionsübergang beinhaltet ebenso eine Anpassung des Versionierungsschemas. Somit folgt auf Version 15.01 (Schema: „Jahr.Monat“) nun Version 4.0 (Schema: „Hauptversionsnummer.Unterversionsnummer“). Weiterhin erfolgten geringfügige Anpassungen nach erster Veröffentlichung der Version 4.0 im Dezember 2015 in einer neuen Version 4.1 im Juli 2016. Im Zuge der Implementierung der Versionen 4.1, 4.2, 4.3, 4.4 und 4.6 wurden Fehlerbehebungen notwendig, die in der hier vorliegenden Version mündeten. |
Ziel der XVergabe-Kommunikationsschnittstelle ist die Schaffung eines einheitlichen und standardisierten Zugangs zu den unterschiedlichen elektronischen Bekanntmachungs- und Vergabeplattformen der öffentlichen Hand aus Sicht der Bieter(werkzeuge). Hierfür wurde ein plattformübergreifender Standard für den zuverlässigen und sicheren Austausch von Daten und Dokumenten zwischen Wirtschaftsteilnehmern (Unternehmen) und den elektronischen Vergabeplattformen definiert, die die Teilnahme der Wirtschaftsteilnehmer an elektronischen Vergabeprozessen der öffentlichen Verwaltung erleichtert und auf diese Weise dazu beiträgt, Prozesskosten einzusparen.
Die XVergabe-Kommunikationsschnittstelle definiert somit eine Schnittstelle zwischen Vergabeplattformen und Bieteranwendungen. Die Bieteranwendung wird somit in die Lage versetzt, verschiedene Vergabeplattformen anzusprechen und die definierten Anwendungsfälle im Vergabe- und Beschaffungswesen gleichförmig abzubilden. Die XVergabe-Kommunikationsschnittstelle fördert hierdurch die Erstellung von so genannten „Multi Plattform Bieter Anwendungen bzw. Clients“ (kurz auch: MPBC), die mittelbar eine Vereinfachung für die Wirtschaftsteilnehmer bei der Beteiligung an der elektronischen Vergabe darstellen.
Die XVergabe-Kommunikationsschnittstelle definiert hierbei (noch) nicht:
Mit der Ausarbeitung der beiden erst genannten Themen sind jedoch XVergabe-Arbeitsgruppen befasst.
Die XVergabe-Kommunikationsschnittstelle umfasst die Spezifikation eines Web-Services zum Austausch von Nachrichten und Dokumenten. In diesen Nachrichten werden die zwischen einem Bieter und einer Vergabestelle auszutauschenden Daten und Dokumente um zusätzliche Metainformationen zur Einordnung in den jeweiligen Prozessschritt des Vergabeverfahrens angereichert.
Die XVergabe-Kommunikationsschnittstelle definiert weiterhin keine über die Schnittstelle hinausgehenden Anforderungen an eine Bieteranwendung oder Plattform.
Beim Entwurf der XVergabe-Kommunikationsschnittstelle wurde eine Reihe von Annahmen basierend auf Erfahrungen aus der Praxis getroffen, die das Design der Schnittstelle und deren Verhalten beeinflussten.
So geht die XVergabe-Schnittstelle davon aus, dass ein Client eines Teilnehmers nicht permanent online erreichbar oder gar technisch adressierbar ist. Somit basiert das Kommunikationsverhalten der Schnittstelle im Wesentlichen auf Aktionen, die die Bieteranwendung auslöst. Um Kommunikationsnachrichten mit einem Teilnehmer austauschen zu können, MUSS eine Plattform der Bieteranwendung diese zum Abruf bereitstellen. Hierfür muss der Teilnehmer innerhalb der Plattform authentifiziert und einem Nutzer zugeordnet werden. Eine ggf. hierfür notwendige Registrierung des Nutzers an der Plattform ist (noch) nicht Teil der XVergabe-Kommunikationsschnittstelle. Derzeit wird von vorregistrierten Nutzern ausgegangen, die sich authentifizieren können. Sofern die Authentifizierung fehl schlägt (oder schlicht aus Sicht des Teilnehmers nicht möglich ist) SOLL eine Plattform den Teilnehmer auf eine Webseite zur Registrierung hinweisen, die die Plattform anbietet.
Ebenso wird davon ausgegangen, dass Nachrichten zur Prozesssteuerung von der Vergabestelle (bzw. –plattform) an die Bieteranwendung keine Anlagen als Binärdaten (bspw. die Auftragsunterlagen im PDF-Format) enthalten. Diese werden seitens einer Plattform lediglich referenziert. Eine Bieteranwendung MUSS diese Dokumente explizit von der Plattform über die XVergabe-Kommunikationsschnittstelle anfordern. Somit werden auch leichtgewichtige Clients unterstützt, die ggf. keinen Zugriff auf die Unterlagen benötigen (bspw. um lediglich Statusinformationen über das Verfahren mitzuteilen).
Umgedreht enthalten Nachrichten vom Bieter aber immer die ggf. referenzierten Anlagen direkt innerhalb der Kommunikationsnachricht.
Da einige Vergabestellen und Betreiber von Vergabeplattformen Anforderungen an die Transport-Infrastruktur stellen, berücksichtigt die XVergabe-Kommunikationsschnittstelle für die „Geschäfts-kritischen“ Anwendungsfälle „Abgabe von Angeboten“, „Abgabe von Teilnahmeanträgen“ sowie deren Rückzüge neben den hierfür der Schnittstelle definierten Möglichkeiten auch die Möglichkeit zur Abbildung dieser Anwendungsfälle über eine OSCI-Transport-Infrastruktur (derzeit in Version 1.2). Sofern eine Vergabeplattform oder Vergabestelle entsprechende Anforderungen umsetzen muss, MUSS sie die Bieteranwendung hierüber in Kenntnis setzen. Dies geschieht technisch in der XVergabe-Kommunikationsschnittstelle durch Mitteilung der technischen Verbindungsparameter für OSCI-Transport innerhalb der Aufforderung zur Angebotsabgabe bzw. Aufforderung zur Abgabe eines Teilnahmeantrags. Die jeweiligen Rückzüge MÜSSEN durch eine solche Plattform dann auch über OSCI-Transport angenommen und verarbeitet werden. Die Plattformen SOLLEN sich auf eine Form der Einreichung von Angeboten (XVergabe-Kommunikationsschnittstelle oder OSCI-Transport) festlegen. D.h. eine Plattform SOLL eine Angebotsabgabe über die XVergabe-Kommunikationsschnittstelle ablehnen, wenn sie die technischen Parameter zur Angebotsabgabe via OSCI-Transport mitgeteilt hat. Der Ablauf der Kommunikation (Choreographie) in einem Szenario, in dem für die Angebotsabgabe und –rückzug OSCI-Transport eingesetzt wird, wird im Kapitel „Abgabe von Angeboten, TNAs und Rückzügen via OSCI-Transport“ nochmals detailliert beschrieben. Eine Bieteranwendung MUSS im Gegensatz zu einer Plattform OSCI-Transport immer unterstützen.
Darüber hinaus setzen verschiedene Vergabestellen und deren Plattformen unterschiedliche Anforderungen hinsichtlich dem Einsatz von Signaturen und Verschlüsselungen sowie der Strukturierung von Angeboten und Teilnahmeanträgen (TNA) um. Die XVergabe-Kommunikationsschnittstelle unterstützt diese Vielfalt derart, dass die Vergabestelle bzw. die –plattform ebenfalls in den Nachrichten zur Angebotsaufforderung („InvitationToTender“, kurz: ITT) bzw. Aufforderung zur Abgabe eins Teilnahmeantrages („InvitationToParticipation“, kurz: ITP) ihre jeweiligen Anforderungen definiert und der Bieteranwendung und somit auch dem Teilnehmer mitteilt. Sie legt in den genannten Nachrichten fest:
ob ein entsprechendes Dokument signiert werden SOLL und welches Signaturniveau der Bieter bzw. Teilnehmer für die Signatur der Dokumente mindestens erbringen SOLL (die Prüfung auf Einhaltung und der Umgang mit dem Prüfergebnis obliegt der Vergabestelle),
Die XVergabe-Kommunikationsschnittstelle sieht keine Möglichkeit zur Einschränkung der zu nutzenden Zertifikate bzw. Signaturkarten auf bestimmte Zertifizierungsdiensteanbieter oder Hersteller vor. Sofern eine Plattform dies erfordert, muss sie dies in den Allgemeinen Geschäftsbedingungen regeln, denen der Teilnehmer im Rahmen der Registrierung zugestimmt hat.
Für die Erbringung von Signaturen definiert die XVergabe jedoch den folgenden technischen Rahmen, der umgesetzt werden MUSS:
Die XVergabe-Kommunikationsschnittstelle sieht Signaturen ausschließlich im Rahmen der Geschäfts-kritischen Anwendungsfälle „Abgabe von Angeboten“, „Abgabe von Teilnahmeanträgen“ sowie deren Rückzügen vor. Weitere Nachrichten KÖNNEN jedoch signierte Anlagen zur Nachricht beinhalten.
Für Angebots- und TNA-Container ist eine Verschlüsselung vorgesehen. Hierfür MUSS die Vergabeplattform bzw. –stelle der Bieteranwendung den für die Verschlüsselung zu verwendenden Schlüssel (Public Key) in Form eines DER-codierten X.509-Zertifikats zur Verfügung stellen (in der ITT- bzw. ITP-Nachricht). Die XVergabe-Kommunikationsschnittstelle legt für die Verschlüsselung folgenden technischen Rahmen, der unterstützt werden MUSS:
Die XVergabe-Kommunikationsschnittstelle führt nicht aus, ob das Sicherheitskonzept der Vergabeplattform Verfahrens- oder Teilnehmer-spezifische Schlüssel bereitstellen muss. Ebenso werden keine Anforderungen an das Schlüsselmanagement der Vergabeplattform gestellt.
Die XVergabe-Kommunikationsschnittstelle sieht für die Nutzung von OSCI-Transport vor, dass der Payload (also bspw. die Angebotsabgabenachricht inkl. verschlüsseltem Angebotscontainer, der ggf. signierte Dokumente enthält) identisch zum Transportweg der XVergabe-Kommunikationsschnittstelle gebildet wird. Lediglich die genutzte Transportinfrastruktur ändert sich. Somit bilden XVergabe-Nachrichten den Payload (dort auch Fachdaten genannt) von OSCI-Transport-Nachrichten.
Die XVergabe-Kommunikationsschnittstelle geht weiterhin davon aus, dass ein Vergabeverfahren einem Lebenszyklus (auch Verfahrensstatusmodell) unterliegt. Dies ist im Kapitel „Verfahrensstatusmodell“ näher beschrieben. Das Verfahrensstatusmodell regelt hierbei auch in welchem Status des Verfahrens welche Nachrichten der XVergabe-Kommunikationsschnittstelle unterstützt werden MÜSSEN bzw. nicht unterstützt werden DÜRFEN. Dieses Verfahrensstatusmodell MUSS durch die die Schnittstelle implementierenden Anwendungen (Plattformen und Bieteranwendungen) gleichermaßen umgesetzt werden, da es die steuernde Basis der Kommunikation darstellt.
Die XVergabe-Kommunikationsschnittstelle MUSS https-gesichert in den Plattformen umgesetzt werden. Für die Zertifikate der Plattformen die hierfür eingesetzt sind, werden seitens XVergabe keine weiteren Anforderungen definiert. Zusätzlich zu dieser Absicherung bzgl. Vertraulichkeit und Integrität der Kommunikation MÜSSEN Bieteranwendungen eine https-Clientauthentifizierung durchführen. Diese dient dem Nachweis der Konformität der Bieteranwendung. XVergabe-Konformitätsbestätige Clientanwendungen erhalten vom Beschaffungsamt ein Zertifikat, welches die Bieteranwendung im Rahmen der https-Clientauthentifizierung einer XVergabe-konformen Plattform präsentieren MUSS.
Es kann nicht ausgeschlossen werden, dass die in den Anlagen (bspw. Auftragsunterlagen) enthaltenen Informationen abweichen von den Informationen, die bspw. in der ITT aufgeführt werden. Daher gilt grundsätzlich: Die Informationen der ausgetauschten Dokumente sind führend! Die XVergabe-Kommunikationsschnittstelle dient dem einheitlichen Austausch dieser Dokumente.
Für die Kommunikation SOLL eine Plattform Begrenzungen für die Größe der durch die Bieteranwendung in den Nachrichten eingebundenen Anlagen festlegen können. Diese Größenbeschränkung SOLLEN sowohl pro Anlage als auch über alle Anlagen einer Nachricht zusammen aufführbar sein. Die XVergabe-Kommunikationsschnittstelle ermöglicht diese beschränkenden Angaben in der TenderMetaInformation-Nachricht (TMI). Eine Bieteranwendung SOLL diesen darin aufgeführten Größenbeschränkungen Folge leisten, um eine zuverlässige Kommunikation sicherzustellen. Ein Überschreiten der Größenbeschränkungen kann zur technischen Nicht-Verarbeitbarkeit der Nachricht führen. Bei den Angaben ist zu beachten, dass es sich um Brutto-Angaben handelt, d.h. der durch die notwendige base64-Transformation der Daten entstehende Overhead von ca. 33% ist in der Angabe mit eingerechnet.
Innerhalb von XVergabe-Nachrichten und Dokumenten werden eindeutige Identifier vergeben. Diese dienen dazu das entsprechende Objekt an anderer Stelle zu referenzieren (bspw. die ITT-Nachrichten-ID bei der Angebotsabgabe um Plattform-seitig prüfen zu können, ob sich das Angebot auf die letzte Version der Auftragsunterlagen bezieht) bzw. um Objekte innerhalb einer Nachricht miteinander zu verknüpfen (bspw. Anlagen). Sämtliche Identifier sind im Format einer UUID aufgebaut und sind hierdurch global (Plattform-übergreifend) eindeutig. Sofern nicht anders angegeben, gilt ein übertragenes Verursacherprinzip: Derjenige Kommunikationsteilnehmer MUSS eine ID für das relevante Objekt vergeben, wenn er es erzeugt, d.h. die Nachrichten-ID MUSS jeweils von der Bieteranwendung und der Plattform erzeugt werden (in Abhängigkeit davon, wer die Nachricht erzeugt).
Eine Nachricht verfügt neben einer eindeutigen und über ihre Lebensdauer unveränderlichen NachrichtenID auch über einen unveränderlichen Ausstellungszeitpunkt.
Vergabeplattformen KÖNNEN für die Angebots- und TNA-Abgabe die zugehörigen Dokumente auf logische Container (Angebots- bzw. TNA-Container) durch die Bieteranwendung verteilen lassen. Hierdurch wird der Prozess der Angebots- bzw. TNA-Öffnung Plattformseitig von der Größe des Angebots entkoppelt. Die Plattform legt daher für die Bieteranwendung fest, ob sie diese Aufteilung unterstützt und welche Angebots- bzw. TNA-Bestandteile in den primären Angebotscontainer (primary Container) eingebracht werden SOLLEN und welche nicht – die übrigen Angebotsbestandteile SOLLEN dann durch die Bieteranwendung zusammen mit den durch den Bieter selbständig (ohne Aufforderung) beigebrachten Dokumenten in den sekundären Angebotscontainer eingebracht werden. Legt eine Plattform fest, dass sie nur den primären Container unterstützt, MÜSSEN alle Dokumente im primary Container zusammengefasst werden.
Die Vollständigkeit der Offer- bzw. Participation-Container MÜSSEN Clientseitig geprüft werden, da dies Plattformseitig erst zur Angebotsöffnung (bzw. TNA-Öffnung) geschehen kann und somit keine korrigierenden Maßnahmen durch den Bieter bzw. Teilnehmer mehr erfolgen können.
Innerhalb der XVergabe-Kommunikationsschnittstelle wird eine inhaltlich orientierte Fehlersignalisierung definiert. D.h. sofern bei Erhalt oder Verarbeitung einer XVergabe-Nachricht Fehler auftreten so MÜSSEN diese dem Absender der Nachricht innerhalb der XVergabe-Antwort-Nachricht zurück übermittelt. Hierbei wird unterschieden zwischen Fehlerfällen, die die weitere Verarbeitung der Nachricht verhindern (bspw. Authentifzierungsfehler) – so genannte ERRORs – und solchen, die die weitere Verarbeitung der Nachricht nicht verhindern, jedoch nicht den Vorgaben der Vergabeplattform entsprechen – so genannte WARNINGs. Somit stellt ein ERROR aus Sicht des Clients eine Situation dar, in der der Bieter handeln MUSS, da seine Nachricht fachlich nicht weiter behandelt wird (werden kann).
Für ausgesuchte Fehlersituationen ist die Vergabestelle bzw. –plattform in der Lage festzulegen, ob diese Situation eine Warning oder Error darstellt (bspw. Eingang des Angebots nach Angebotsfrist).
Sofern plattformspezifische bzw. plattform-interne Fehler auftreten (bspw. Fehler in der Anwendungslogik) so MÜSSEN diese in Form von SOAP-Faults an den Client zurückgegeben werden.
Die Ankündigung von Informationen zu zukünftigen Wartungsfenstern ggü. der Vergabestelle ist NICHT Bestandteil der XVergabe, da davon ausgegangen wird, dass hierfür Prozesse zwischen Plattformbetreiber und Vergabestelle existieren. Die Ankündigung von Informationen zu zukünftigen Wartungsfenstern ggü. dem Bieter KANN über die in XVergabe vorgesehene Bieterkommunikation (inquiry) erfolgen, sie wird inhaltlich jedoch nicht weiter spezifiziert. Ein akut auftretendes Wartungsfenster KANN via SOAP-Fault kommuniziert werden, sofern dies die Architektur der Plattform zulässt – auf die Standardisierung eines XVergabe-spezifischen Fehlerwert wurde verzichtet.
Anchor | ||||
---|---|---|---|---|
|
Das elektronische Vergabe- und Beschaffungswesen kann anhand der nachfolgend dargestellten Prozesskette zusammenfassend beschrieben werden:
Die Unterteilung der eBeschaffungsprozesskette in „Pre-Awarding“ und „Post-Awarding“ Phase wurde der Vollständigkeit halber mit aufgeführt. Sämtliche Prozesse nach Zuschlag an den Auftragnehmer sind nicht Teil der XVergabe-Kommunikationsschnittstelle und werden im Rahmen anderer Standardisierungsaktivitäten beschreiben (bspw. Steuerungsprojekt „E-Rechnung“ des IT-Planungsrats).
Mit XVergabe sind somit die Prozesse und Anwendungsfälle bis inkl. Zuschlag an den Auftragnehmer abbildbar. Eine Besonderheit bildet die Prozessgruppe „eNotice“, die den elektronischen Austausch von Bekanntmachungen beschreibt. Diese wird zwar durch eine XVergabe-Arbeitsgruppe technisch ausgeprägt, jedoch ist dies NICHT Teil der hier beschriebenen XVergabe-Kommunikationsschnittstelle.
Die XVergabe-Kommunikationsschnittstelle unterstützt somit die folgenden Prozessgruppen:
Mit der XVergabe-Kommunikationsschnittstelle sind derzeit die folgenden Verfahrensarten abbildbar:
Verfahrensart | Bezeichnung in der XVergabe-Kommunikationsschnittstelle |
---|---|
Unterschwellige Verfahrensarten | |
Freihändige Vergabe | SINGLE_TENDER_ACTION |
Freihändige Vergabe mit Teilnahmewettbewerb | SINGLE_TENDER_ACTION_WITH_PARTICIPATION_CONTEST |
Öffentliche Ausschreibung | PUBLIC_TENDER |
Beschränkte Ausschreibung | RESTRICTED_TENDER |
Beschränkte Ausschreibung mit Teilnahmewettbewerb | RESTRICTED_TENDER_WITH_PARTICIPATION_CONTEST |
Verhandlungsvergabe bzw. unterschwelliges Verhandlungsverfahren | NEGOTIATED_TENDER |
Verhandlungsvergabe bzw. unterschwelliges Verhandlungsverfahren mit Teilnahmewettbewerb | NEGOTIATED_TENDER_WITH_PARTICIPATION_CONTEST |
Oberschwellige Verfahrensarten | |
Offenes Verfahren | OPEN_PROCEDURE |
Nicht-Offenes Verfahren mit Teilnahmewettbewerb | RESTRICTED_PROCEDURE |
Verhandlungsverfahren | NEGOTIATED_PROCEDURE |
Verhandlungsverfahren mit Teilnahmewettbewerb | NEGOTIATED_PROCEDURE_WITH_PARTICIPATION_REQUEST |
Verhandlungsverfahren können lt. VOF und VOB auch unterschwellig angewandt werden, lt. UVgO wird die Verfahrensart dort "Verhandlungsvergabe" genannt.
Preisanfragen werden nicht explizit aufgeführt, da diese in der Regel wie Freihändige Vergaben durchgeführt werden.
Auch Verfahren nach VSVgV werden nicht explizit aufgeführt. Die Klarstellung, dass es sich um Verfahren nach VSVgV handelt, erfolgt in der Regel in den Auftragsunterlagen direkt. Eine Auswirkung auf die Umsetzbarkeit innerhalb der XVergabe-Kommunikationsschnittstelle ist nicht gegeben.
Weitere Verfahrensarten (insb. Wettbewerblicher Dialog, Interessensbekundungsverfahren mit Interessensbestätigung, Innovationspartnerschaften, Dynamisches Beschaffungssystem sowie Auktionen) werden im Rahmen der Weiterentwicklung der XVergabe-Kommunikationsschnittstelle hinsichtlich ihrer Umsetzung mit XVergabe geprüft.
Die nachfolgende Abbildung verdeutlicht den logischen Aufbau der Schnittstelle:
Wie bereits ausgeführt, beschreibt die XVergabe-Kommunikationsschnittstelle eine SOAP Web-Service-Schnittstelle einer Vergabeplattform. Hierfür wird eine technische Beschreibung in Form einer WSDL-Datei als Teil der XVergabe-Kommunikationsschnittstelle bereitgestellt. Dieser Web-Service bildet die Transport-Ebene.
Die über die darin definierten Operationen auszutauschenden fachlichen Nachrichten bilden die nächste Ebene der XVergabe-Kommunikationsschnittstelle. Diese fachlichen Nachrichten werden im Datenmodell „Messages“ genannt. Sie unterscheiden sich von den Web-Service-Messages, weil sie vom Transportprotokoll (hier SOAP) abstrahieren und auch über andere Transportwege übermittelt werden können (bspw. OSCI-Transport).
Die Nachrichten selbst enthalten wiederum die fachlichen Informationen, die die innerste Ebene „Documents“ darstellen. Diese fachlichen Informationen sind vorerst soweit strukturiert, wie sie für eine Prozesssteuerung notwendig sind. Die eigentlichen Daten bleiben vorerst in binären Anlagen (bspw. PDF-Dokumenten) ausgelagert.
Anchor | ||||
---|---|---|---|---|
|
Die XVergabe-Kommunikationsschnittstelle umfasst die Zusammenstellung der folgenden Artefakte:
Folgende WSDL-Dateien sind Bestandteil der XVergabe-Kommunikationsschnittstelle und MÜSSEN von einer XVergabe-konformen Plattform implementiert werden:
Datei | Namespace | Beschreibung |
build/wsdl/xvergabe-service.wsdl | Definition der Operationen der XVergabe-Kommunikationsschnittstelle. Eine Plattform MUSS den darin definierten XVergabeService bzw. dessen Port „XVergabePort“ mit einer konkreten Adresse parametrisieren, unter der die Plattform den Dienst anbietet. Um Probleme aufgrund von Firewallrestriktionen bieterseitig zu minimieren, SOLL der Port auf einem HTTP- bzw. HTTPS-Standardport (also 80 oder 443) oder einem jeweiligen Alternativport (also 8080 oder 8443) erreichbar gemacht werden. | |
build/wsdl/service_policy.wsdl | Ausgelagerte Security Policies des Web-Services (bspw. bzgl. HTTPS-Binding oder Authentifizierung mittels UserName-Token). Diese Policies MÜSSEN unverändert implementiert werden. |
Folgende XML Schema Dateien sind Bestandteil der XVergabe-Kommunikationsschnittstelle und MÜSSEN von einer XVergabe-konformen Plattform implementiert werden:
Datei | Namespace | Beschreibung |
build/xsd/xvergabe-codelists.xsd | definierte Codelisten (Wertelisten, Aufzählungswerte) die in den übrigen Schnittstellen-Komponenten genutzt werden (bspw. Code.ProcedureType für Verfahrensarten) | |
build/xsd/xvergabe-datatypes.xsd | eigens definierte Basisdatentypen, die in den übrigen Schnittstellen-Komponenten genutzt werden (bspw. GUID). | |
build/xsd/xvergabe-documents.xsd | fachliche Dokumente, die über in den Nachrichten über die Schnittstelle ausgetauscht werden | |
build/xsd/xvergabe-messages.xsd | Transport-unabhängige Definition der Nachrichten, die die fachlichen Dokumente über die Schnittstelle austauschen. | |
build/xsd/xvergabe-service.xsd | Definition der Datentypen, die von der WSDL-Beschreibung zur Transport-spezifischen Definition der WebService-Nachrichten genutzt werden. | |
build/ext/xvergabe-mtom.xsd | Definition eines MTOM-fähigen Attachment-Datentyps. Wird vom technischen Datenmodell referenziert und eingebunden (XÖV-Adapter). |
Die technische Dokumentation wird aus den XML Schema Dateien in Form einer HTML-Datei (doc/html/xvergabe-service.html) automatisch generiert. Sie enthält einen Großteil der Dokumentation und Spezifikation der XVergabe-Kommunikationsschnittstelle. Sie beschreibt die Datentypen, Dokumente, Nachrichten und deren Attribute im Detail.
Das technische Datenmodell wird als MagicDraw-Projektdatei (derzeit: MagicDraw Version 16.8) bereitgestellt (magicdrawsource/xvergabe_2015.mdzip). Die Projektdatei enthält XÖV-profilierte UML-Klassendiagramme, aus denen die oben aufgeführten XML Schema Dateien automatisiert generiert werden (können) – mit Ausnahme der unter „build/ext“ extern eingebundenen XML Schema Dateien. Für die Projektdatei sowie die automatische Generierung von XML Schema Dateien enthält das Verzeichnis zusätzlich notwendige Dateien, die entweder von MagicDraw oder von der XÖV-Werkzeugkette benutzt werden.
Zusätzlich zu der Programmiersprachen-neutralen Beschreibung der Schnittstelle wird die Schnittstelle als JAVA Binding in Form einer JAR-Datei bereitgestellt (im Verzeichnis build/jar). Diese enthält die Klassen, die automatisiert aus der WSDL und XSDs erzeugt werden. Diese kann in eigenen JAVA Projekten zur Ausgestaltung der Schnittstelle nachgenutzt werden.
Nachfolgend wird der in der XVergabe-Kommunikationsschnittstelle definierte Web-Service kurz beschrieben. Der Web-Service wird technisch durch zwei WSDL 1.1 Dateien (siehe oben) beschreiben und sieht als Kommunikationsprotokoll SOAP 1.2 vor. Zur Beschreibung wird die WSDL 1.1 Binding Extension for SOAP 1.2 verwendet.
Fachliche Fehler werden nicht auf Ebene von SOAP als SOAP-Faults definiert, sondern Transport-Unabhängig auf Nachrichten- bzw. Dokumentenebene (ResponseDocument), die Responses auf SOAP-Ebene nutzen jedoch das ResponseDocument. Somit werden ggf. auftretende Fehler innerhalb des SOAP-Bodys transportiert.
Technische Fehler in der Schnittstelle werden als SOAP-Faults transportiert. Ebenso KÖNNEN derzeit aktive Wartungsfenster der Plattform über SOAP-Faults transportiert werden, sofern dies die Architektur der Plattform zulässt.
Die Kommunikation mit dem Webservice wird immer durch die Bieteranwendung ausgelöst. Er bietet die folgenden Operationen, die immer aus einer jeweiligen Request- (Anfrage) und Response- (Antwort) Nachricht bestehen. Die nähere Definition der Requests und Responses ist der technischen Dokumentation zu entnehmen.
Generell gilt für alle Operationen:
Operation | Request | Response | Beschreibung |
---|---|---|---|
subscribe | msgSubscriptionRequest | msgSubscriptionResponse | Durch Aufruf dieser Operation kann ein Wirtschaftsteilnehmer am Verfahren teilnehmen bzw. seinen Teilnahmewunsch anzeigen. Siehe auch eSubscription oben. Der subscribe-Request MUSS sich immer auf ein konkretes Verfahren beziehen. Das Verfahren wird wahlweise über die global eindeutige Verfahrens-ID (UUID) oder über eine Plattform-spezifische ID (String) gekennzeichnet. Dies in Abhängigkeit, welche Information der Nutzer hat. Die subscribe-Response MUSS im Falle einer positiven Anmeldung als Response-Code ein „OK“ enthalten sowie nähere Angaben zum Verfahren enthalten (Verfahrens-ID (UUID), Verfahrenskurzbezeichnung, letzte NachrichtenID der Nachricht an den Nutzer im Verfahren). Die letzte NachrichtenID einer Nachricht, die die Plattform dem Nutzer in diesem Verfahren zugestellt hat MUSS die NachrichtenID der ITT- bzw. ITP-Nachricht sein, die mit Anmeldung des Nutzers am Verfahren für diesen bereitgestellt wurde. Die subscribe-Response KANN ein „Pending OK“ als Rückgabewert enthalten – dieser wird in Form eines Warnungs-Codes zurückgegeben. Er sagt aus, dass der Nutzer noch durch die Vergabestelle selbst im Verfahren freigeschalten werden muss. Die Plattform SOLL in diesem Fall die weiteren Verfahrensinformationen ebenso in der Response mitteilen (um sicherzustellen, dass der Bieter über die korrekte Verfahrens-ID verfügt) – die Angabe der letzt-bekannten NachrichtenID ist hierbei mit aufgefüllten Nullen in der Syntax einer UUID anzugeben. Sofern ein Fehler bei der Verarbeitung der Anfrage auftritt MUSS die Plattform einen Errorcode in der Response übermitteln. Mit erfolgreichen Subscribe MUSS die Plattform für den im Verfahren nun angemeldeten Nutzer eine TMI-Nachricht sowie in Abhängigkeit davon ob ein Teilnahmewettbewerb durchgeführt wird oder nicht eine ITP- oder ITT-Nachricht zum Abruf via getMessages bereitstellen. Diese Operation transportiert keine der unten aufgeführten Nachrichten – die ausgetauschten Inhalte werden rein auf Ebene des Webservices beschrieben. |
getTenderIDs | msgGetTenderIDsRequest | msgGetTenderIDsResponse | Die Operation dient einer Bieteranwendung dazu festzustellen, an welchen Verfahren ein Nutzer auf der Plattform teilnimmt bzw. welche Verfahren, in denen der Nutzer angemeldet ist, dort noch aktiv sind (also auf die zugegriffen werden kann). Ebenso dient die Operation dazu, dem Nutzer die Nachrichten-ID der letzten für ihn in dem jeweiligen Verfahren bereitgestellten Nachricht zur Kenntnis zu bringen. Somit kann der Nachrichtenabruf seitens der Bieteranwendung zielgerichteter in bestimmten Verfahren erfolgen. Eine Plattform MUSS einem Nutzer die notwendigen Verfahrensinformationen derjenigen Verfahren in der Response mitteilen, in denen der Nutzer angemeldet (subscribed) ist und die sich noch nicht im Verfahrensstatus ARCHIVED befinden. Die Response MUSS somit eine Liste von Verfahrensinformationen enthalten. Die Liste kann leer sein. Sofern ein Fehler bei der Verarbeitung der Anfrage auftritt MUSS die Plattform einen Errorcode in der Response übermitteln. Diese Operation transportiert keine der unten aufgeführten Nachrichten – die ausgetauschten Inhalte werden rein auf Ebene des Webservices beschrieben. |
getMessages | msgGetMessagesRequest | msgGetMessagesResponse | Diese Operation dient der Bieteranwendung zum Abruf von Nachrichten von der Vergabeplattform innerhalb eines Verfahrens. Die Bieteranwendung kann wahlweise eine spezifische Nachricht anhand ihrer Nachrichten-ID zum Abruf selektieren oder das Verfahren angeben, deren Nachrichten sie abzurufen wünscht. In letzterem Fall MUSS die Plattform ALLE Nachrichten in der Response zurückliefern, die für den Nutzer in dem Verfahren bereitgestellt worden sind. Die Anfrage ist in diesem Szenario weiterhin durch die Angabe einer Nachrichten-ID der der Bieteranwendung letzt-bekannten Nachricht in einem Verfahren einschränkbar. In diesem Fall MUSS die Plattform nur diejenigen Nachrichten in der Response an die Bieteranwendung ausliefern, die neuer sind als die Nachricht, die durch die Nachrichten-ID in der Anfrage referenziert wurde. Die Liste in der Response MUSS durch die Angabe einer Ordnungszahl der Nachrichten innerhalb der Response geordnet werden. Hierdurch wird die zeitliche Reihenfolge abgebildet. Die Ordnungszahl MUSS bei der ältesten Nachricht mit 1 beginnen und mit jeder Nachricht um 1 inkrementiert werden. Sofern ein Fehler bei der Verarbeitung der Anfrage auftritt MUSS die Plattform einen Errorcode in der Response übermitteln. Diese Operation transportiert lediglich in der Response eine, keine oder mehrere der unten aufgeführten Nachrichten – der Request wird rein auf Ebene des Webservices beschrieben. |
getDocument | msgGetDocumentRequest | msgGetDocumentResponse | Diese Operation dient dem Bieterwerkzug zum Abruf von Dokumenten, die in ihr bereitgestellten Nachrichten referenziert worden sind. Der Request MUSS immer genau eine Dokumentenreferenz enthalten. Die Response MUSS im Positivfall (Nutzer positiv authentifiziert und autorisiert) das angefragte Dokument als Anlage enthalten. Sofern ein Fehler bei der Verarbeitung der Anfrage auftritt MUSS die Plattform einen Errorcode in der Response übermitteln. Diese Operation transportiert lediglich in der Response max. eine der unten aufgeführten Nachrichten (Attachments) – der Request wird rein auf Ebene des Webservices beschrieben. |
sendMessage | msgSendMessageRequest | msgSendMessageResponse | Diese Operation dient dem Bieterwerkzeug zur Übermittlung einer Nachricht an die Plattform. Es wird keine fachlich-inhaltliche Antwort zurückgegeben, lediglich die Information über Erfolg und Nicht-Erfolg der Zustellung. Die Operation stellt somit eine asynchrone Kommunikationsbeziehung aus fachlich-inhaltlicher Sicht dar. Derzeit ist es lediglich möglich hierin Inquiry-Nachrichten zur Abwicklung von Bieterfragen von der Bieteranwendung an die Plattform zu übermitteln – bei den übrigen Bieter-seitigen Nachrichten werden direkt (synchron) fachlich-inhaltliche Antworten (Zustellquittungen) zurück übermittelt. Die Response MUSS lediglich einen entsprechenden Responsecode enthalten, der über Erfolg oder Nicht-Erfolg der Zustellung Auskunft gibt. Diese Operation transportiert lediglich im Request eine der unten aufgeführten Nachrichten (derzeit: Inquiry) – die Response wird rein auf Ebene des Webservices beschrieben. |
sendSynchronousMessage | msgSendSynchronousMessageRequest | msgSendSynchronousMessageResponse | Diese Operation dient dem Bieterwerkzeug zur Übermittlung von Nachrichten an die Plattform, auf die direkte inhaltlich-fachliche Antworten erfolgen. Derzeit wird diese Operation ausschließlich für die Geschäfts-kritischen Nachrichten zur Angebotsabgabe, TNA-Abgabe, Angebots-Rückzug und TNA-Rückzug genutzt. Die Plattform MUSS diese Nachrichten verarbeiten können und in Abhängigkeit des Requests den zugehörigen Nachrichtentyp als Response übermitteln: entweder Angebotseingangsquittung, TNA-Eingangsquittung, Angebotsrückzugseingangsquittung oder TNA-Rückzugseingangsquittung. Sofern ein Fehler bei der Verarbeitung der Anfrage auftritt MUSS die Plattform einen Errorcode in der Response übermitteln. Die Plattform SOLL weiterhin den Bieter auf mögliche Fehlerquellen durch das Ausstellen von Warningcodes aufmerksam machen (bspw. Angebotsabgabe bezieht sich auf veraltete Auftragsunterlagen; Angebot ist entgegen den Anforderungen aus der ITT nicht verschlüsselt; Angebot ist entgegen den Anforderungen aus der ITT falsch strukturiert (nur 1 statt 2 Angebotscontainer)). Mit Ausstellung eines Warningcodes gilt das Angebot trotzdem als abgegeben. Sofern die Plattform die Einreichung nach dem jeweiligen Fristende unterstützt, d.h. bspw. ein abgegebenes Angebot wird nach Angebotsfrist aber vor Zuschlag noch angenommen, SOLL die Plattform dies ebenso durch einen Warningcode dem Bieter anzeigen. Sofern die Plattform dies nicht unterstützt und das verspätet abgegebene Angebot abweist, MUSS die Plattform dies dem Bieter durch einen Errorcode anzeigen. Im Falle, dass das Angebot bzw. der TNA angenommen worden sind, MUSS die Plattform dem Bieter in der Response die Angebots- bzw. TNA-ID mitteilen, unter der die Plattform das Angebot bzw. den TNA verwaltet. Diese ID wird vom Bieter im Falle eines Rückzuges als Referenz auf das zurückzuziehende Objekt benötigt. Diese gleiche Quittung MUSS die Plattform auch als separate Nachricht der Bieteranwendung zum Nachrichtenabruf mittels getMessages-Operation bereitstellen. Diese dient lediglich dazu, bei ggf. eintretendem Nachrichtenverlust seitens der Bieteranwendung, die Quittung wieder abrufbar zu gestalten – in einer „normalen“ Nachrichtenchoreografie KANN die Bieteranwendung diese Nachricht ignorieren, sofern sie die synchrone mitgeteilte Antwort auswertet. Sofern die Plattform gänzlich, d.h. für alle Vergabeverfahren, für die genannten Anwendungsfälle ausschließlich OSCI-Transport vorsieht, MUSS sie trotzdem diese Schnittstellenoperation anbieten. Sie MUSS den Bieter bei Aufruf der Operation durch einen entsprechenden Errorcode darauf hinweisen, dass der Bieter entgegen ITT und ITP Nachricht den falschen Zugangsweg gewählt hat. Das Angebot – bspw. – gilt dann als nicht angenommen, wenn die Plattform den Zugangsweg explizit in der ITT-Nachricht als OSCI-Transport definiert hat und den entsprechenden Errorcode an die Bieteranwendung in der Response zurückgegeben hat. Diese Operation transportiert im Request wie aufgeführt eine der unten aufgeführten Nachrichten (offerMessage, participationMessage, offerWithdrawalMessage, participationWithdrawalMessage). Die Response enthält demnach maximal eine der unten aufgeführten Nachrichten offerDeliveryReceiptMessage, participationDeliveryReceiptMessage, offerWithdrawalDeliveryReceiptMessage, participationWithdrawalDeliveryReceiptMessage. Innerhalb der Quittungen in der sendSynchronousMessageRespon-se MUSS eine Plattform die Responseinformationen (also OK/Warning/Error) doppelt einstellen: Einmal auf Servicebene und dann mit gleichem Inhalt auf Ebene des Dokuments. Dies ist notwendig um gleiche Quittungen auch asynchron bereitstellen zu können inkl. einer Möglichkeit zur Fehlerauswertung. |
getOSCITransferID | msgGetOSCITransferIDRequest | msgGetOSCITransferIDResponse | Im Rahmen der Angebots- bzw. TNA-Abgabe und deren Rückzüge über OSCI-Transport MUSS die Plattform dem Bieter – sofern sie OSCI-Transport als Zugangsweg für diese Anwendungsfälle vorsieht – eine so genannte TransferID (in Form einer UUID) ausstellen. Diese TransferID MUSS die Bieteranwendung in der OSCI-Zustellung unverändert als OSCI-Nachrichtenbetreff verwenden. Damit eine Vergabeplattform auch im OSCI-Kontext eine entsprechende Eingangsquittung ausstellen kann, MUSS die Plattform den zugehörigen OSCI-Intermediär auf den relevanten Nachrichteneingang hin überprüfen. Diese Überprüfung SOLL die Plattform anhand der TransferID, die als OSCI-Nachrichtenbetreff verwendet wurde, durchführen (d.h. die Plattform überprüft, ob im Intermediär eine neue OSCI-Nachricht mit dem Betreff der Transfer-ID vorhanden ist). Sobald diese Überprüfung ergibt, dass die entsprechende Nachricht im OSCI-Interemediär eingegangen ist, MUSS die Plattform die entsprechende Eingangsquittung der Bieteranwendung als neue Nachricht zum Abruf bereitstellen. In der getOSCITransferID-Anfrage MUSS der Bieter spezifizieren, ob die Ausstellung der Transfer-ID für eine Angebotsabgabe (dann mit Angabe der ITT-NachrichtenID, auf die sich das Angebot bezieht), auf eine TNA-Abgabe (dann mit Angabe der ITP-Nachrichten-ID, auf die sich der TNA bezieht) oder auf einen Rückzug (dann mit der entsprechenden ID (TNA-ID oder Angebots-ID), die zurückgezogen werden soll) erfolgen soll. Anhand dieser Angaben SOLL die Plattform analog zum sendSynchronousMessage-Zustellweg den Bieter über mögliche Fehlerquellen hinweisen (bspw. Abgabe eines Angebots nach veralteter ITT). Sofern die Plattform die Einreichung nach dem jeweiligen Fristende unterstützt, d.h. bspw. ein abgegebenes Angebot wird nach Angebotsfrist aber vor Zuschlag noch angenommen, SOLL die Plattform dies ebenso durch einen Warningcode dem Bieter anzeigen. Sofern die Plattform dies nicht unterstützt und das verspätet abgegebene Angebot abweist, MUSS die Plattform dies dem Bieter durch einen Errorcode anzeigen. Diese Operation transportiert lediglich im Request eine der unten aufgeführten Nachrichten (OSCITransferIDRequest) – die Response wird rein auf Ebene des Webservices beschrieben. |
Die XVergabe-Kommunikationsschnittstelle definiert für den Web-Service eine Sicherheitspolicy nach dem Web Services Policy Standard unter Verwendung des WS-Security Policy Standards. Diese Policy MUSS von der Plattform umgesetzt werden, die die XVergabe-Kommunikationsschnittstelle anbietet. Diese Policy wird an die Bieteranwendung als Teil der Servicebeschreibung mit ausgeliefert.
Hierbei werden folgende Sicherheitsziele adressiert und wie beschrieben umgesetzt:
Die über die XVergabe-Kommunikationsschnittstelle ausgetauschten Nachrichten sind generell immer nach folgendem Schema aufgebaut:
Die jeweilige Nachricht enthält neben dem auszutauschenden fachlich-inhaltlichen Informationen (Document, je nach Nachricht spezifisch) auch einen Nachrichtenkopf (MessageHeader). Dieser enthält eine Reihe von Informationen, die zur Steuerung der Nachricht notwendig sind, u.a.:
Weiterhin kann die Nachricht im Nachrichtenkopf so genannte Credential-Items aufnehmen. Diese transportieren in der Regel das zu verwendende Schlüsselmaterial für die Verschlüsselung bzw. für die OSCI-Transport-Kommunikationsparameter notwendigen Intermediärs- und Postfachzertifikate. Credential Items SOLLEN Plattform-seitig also nur bei ITP- und ITT-Nachrichten eingesetzt werden. Bieteranwendungs-seitig SOLLEN Credential-Items lediglich für den Transport des asymmetrisch verschlüsselten symmetrischen Schlüssels bei der Hybrid-Verschlüsselung dienen (in einer Offer- bzw. Participation-Nachricht).
Nachrichten von einer Bieteranwendung KÖNNEN in Abhängigkeit der konkreten Nachricht auch Anlagen enthalten. Diese werden parallel zum MessageHeader und zum Document geführt und sind somit Bestandteil der Nachricht.
Folgende Nachrichten/Dokumente werden in der XVergabe-Kommunikationsschnittstelle definiert. Für die nähere Dokumentation sei auf die HTML-Dokumentation verwiesen.
Nachricht/Dokument | Sender | Empfänger | Anlagen erlaubt | Beschreibung |
---|---|---|---|---|
Attachment | Plattform | Bieteranwendung | 0 | Transportiert ein Dokument im Rahmen von getDocuments-Response von der Plattform zur Bieteranwendung. Enthält das Binärdokument sowie ausgewählte Meta-Daten hierüber (Dateiname, Beschreibung). |
ClientInquiry | Bieteranwendung | Plattform | 0..* | Bieteranfrage innerhalb eines Verfahrens. Kann Anlagen aufnehmen. Die Anlagen SOLLEN einzeln (nicht gezipped) und unverschlüsselt angefügt werden. Es werden keine weiteren Anforderungen an die Anlagen gestellt. Wird immer in einem sendMessage-Request transportiert. |
InvitationToParticipation (kurz: ITP) | Plattform | Bieteranwendung | 0 | Aufforderung zur TNA-Abgabe. Enthält Informationen, die der Teilnehmer für die TNA-Abgabe benötigt:
Enthält weiterhin die Teilnahmeunterlagen in einer Struktur, die es erlaubt, sowohl die Unterlagen selbst für den Teilnehmer abrufbar zu machen, als auch die erwartete Struktur des TNA festzulegen. Zur Erklärung dieser Teilnahmeunterlagen-Struktur im ITP siehe unten. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also immer in einer getMessages-Response transportiert |
InvitationToTender (kurz: ITT) | Plattform | Bieteranwendung | 0 | Aufforderung zur Angebotsabgabe. Enthält Informationen, die der Teilnehmer für die Angebotsabgabe benötigt:
Enthält weiterhin die Auftragsunterlagen in einer Struktur, die es erlaubt, sowohl die Unterlagen selbst für den Teilnehmer abrufbar zu machen, als auch die erwartete Struktur des Angebots festzulegen. Zur Erklärung dieser Auftragsunterlagen-Struktur im ITT siehe unten. Die ITT kann Lose des Verfahrens referenzieren, für die ITT gilt. Sofern das Verfahren Lose enthält, und die Vergabestelle bzw. Plattform unterschiedliche Fristen, Auftragsunterlagen oder erwartete Angebotsstrukturen für diese festgelegt hat, MÜSSEN die Lose in der ITT referenziert werden. In diesem Fall können mehrere ITT gleichzeitig existieren (Eindeutigkeit wird über die Kombination aus Verfahrens-ID und Los-IDs gebildet). Sofern das Verfahren als Verhandlungsverfahren abgewickelt wird, MUSS die ITT den Verfahrensrundenzähler beginnend bei „0“ enthalten. Die Null-Runde bezeichnet die Runde, in der ein Bieter zur Abgabe eines ersten indikativen Angebotes aufgefordert wird, was nachfolgend verhandelt wird. Mit Eintritt in die Verhandlungsphase wird der Verhandlungsrundenzähler auf eins erhöht. Der Verhandlungsrundenzähler erhöht sich mit jeder darauffolgenden Verhandlungsrunde um eins. Ein Bieter SOLL nur dann ein Angebot erstellen, wenn der Verfahrensrundenzähler im ITT mit dem Verfahrensrundenzähler im aktuellsten TMI übereinstimmt. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also immer in einer getMessages-Response transportiert |
Offer | Bieteranwendung | Plattform | 1..2 | Angebotsnachricht. Referenziert eine konkrete ITT-Nachricht, damit die Plattform prüfen kann, ob das Angebot auf die neueste Version der Auftragsunterlagen abgegeben wurde. Die Plattform SOLL in diesem Fehlerfalle lediglich warnen, das Angebot aber nicht ablehnen. MUSS mindestens einen Angebotscontainer als Anlage enthalten (primaryContainer). KANN einen weiteren Angebotscontainer (secondaryContainer) als Anlage enthalten. Beide Anlagen bilden zusammen das Angebot. Jeder der Container MUSS eine PKCS7 verschlüsselte ZIP-Datei darstellen (siehe Anforderungen an Angebotscontainer/-nachrichten oben). Unterstützt eine Plattform nur primaryContainer (siehe Angabe in der ITT) und reicht ein Bieter eine Nachricht bestehend aus zwei Containern ein, SOLL die Plattform in diesem Fehlerfall einen Fehler (SECONDARY_CONTAINER_NOT_SUPPORTED) zurückgeben. Das Angebot wird in diesem Fall nicht von der Plattform angenommen. Nachricht wird durch die Bieteranwendung in einem sendSynchronousMessage-Request oder einem OSCI-Transport-Zustellauftrag an die Plattform übermittelt. |
OfferDeliveryReceipt | Plattform | Bieteranwendung | 0 | Angebotseingangsquittung, die die Plattform im Rahmen einer sendSynchronousMessage-Transaktion, die ein Offer enthält, ausstellt bzw. im OSCI-Transport-Fall bei Feststellung des entsprechenden Nachrichteneingangs (siehe Kapitel „Abgabe von Angeboten, TNAs und Rückzügen via OSCI-Transport"). Referenziert die Nachrichten-ID der Offer-Nachricht des Clients, die Angebots-ID unter der die Plattform das Angebot verarbeitet hat (und mit der ggf. ein Rückzug durch den Bieter veranlasst werden kann), enthält den Zeitpunkt des Nachrichteneingangs (KEIN kryptographischer Zeitstempel) und einen Indikator, ob das Angebot fristgerecht (vor Ablauf der Angebotsfrist) eingegangen ist. MUSS ebenso eine plattform-spezifische Angebotseingangsquittung in einem Menschen-lesbaren Format (HTML, PDF) enthalten/referenzieren, die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen SOLL, um sie dem Bieter anzuzeigen. KANN eine plattform-spezifische technische Angebotseingangsquittung enthalten/referenzieren (bspw. im XML-Format), die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen kann. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. Zusätzlich (im Falle der Angebotsabgabe via XVergabe-sendSynchronousMessae-Operation) AUCH in der sendSynchronousMessage-Response. Die beiden Quittung MÜSSEN inhaltlich identisch sein. Quittung enthält abweichend zu anderen fachlichen Nachrichten auch die ResponseInformation (Fehler, Warning, OK). |
OfferWithdrawal | Bieteranwendung | Plattform | 0..* | Angebotsrückzug. Referenziert ein konkretes zurückzuziehendes Angebot über die Angebots-ID, die die Plattform bei Angebotsabgabe ausgestellt und in der OfferDeliveryReceipt mitgeteilt hat. Kann eine textuelle Angabe zum Grund des Rückzuges aufnehmen. Kann Anlagen aufnehmen (auch zur Begründung des Rückzuges). Sofern die ITT für den Angebotsrückzug ein Signaturniveau (ungleich NONE) festlegt, SOLL mindestens eine der Anlagen ein mit dem geforderten Signaturniveau signiertes Dokument des Bieters enthalten. |
OfferWithdrawalDeliveryReceipt | Plattform | Bieteranwendung | 0 | Angebotsrückzugseingangsquittung, die die Plattform im Rahmen einer sendSynchronousMessage-Transaktion, die einen OfferWithdrawal enthält, ausstellt bzw. im OSCI-Transport-Fall bei Feststellung des entsprechenden Nachrichteneingangs (siehe Kapitel „Abgabe von Angeboten, TNAs und Rückzügen via OSCI-Transport“). Referenziert die Nachrichten-ID der OfferWithdrawal-Nachricht des Clients, enthält den Zeitpunkt des Nachrichteneingangs (KEIN kryptographischer Zeitstempel) und einen Indikator, ob der Rückzug fristgerecht (vor Ablauf der Angebotsfrist) eingegangen ist. MUSS ebenso eine plattform-spezifische Angebotsrückzugseingangsquittung in einem Menschen-lesbaren Format (HTML, PDF) enthalten/referenzieren, die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen SOLL, um sie dem Bieter anzuzeigen. KANN eine plattform-spezifische technische Angebotsrückzugseingangsquittung enthalten/referenzieren (bspw. im XML-Format), die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen kann. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. Zusätzlich (im Falle des Angebotsrückzugs via XVergabe-sendSynchronousMessae-Operation) AUCH in der sendSynchronousMessage-Response. Die beiden Quittung MÜSSEN inhaltlich identisch sein. Quittung enthält abweichend zu anderen fachlichen Nachrichten auch die ResponseInformation (Fehler, Warning, OK). |
Participation | Bieteranwendung | Plattform | 1..2 | TNA-Einreichung. Referenziert eine konkrete ITP-Nachricht, damit die Plattform prüfen kann, ob der TNA auf die neueste Version der Teilnahmeunterlagen abgegeben wurde. Die Plattform SOLL in diesem Fehlerfalle lediglich warnen, den TNA aber nicht ablehnen. MUSS mindestens einen TNA-Container als Anlage enthalten (primaryContainer). KANN einen weiteren TNA-Container (secondaryContainer) als Anlage enthalten. Beide Anlagen bilden zusammen den TNA. Jeder der Container MUSS eine PKCS7 verschlüsselte ZIP-Datei darstellen (siehe Anforderungen an Angebotscontainer/-nachrichten oben). Unterstützt eine Plattform nur primaryContainer (siehe Angabe in der ITP) und reicht ein Teilnehmer einen TNA bestehend aus zwei Containern ein, SOLL die Plattform in diesem Fehlerfall einen Fehler (SECONDARY_CONTAINER_NOT_SUPPORTED) zurückgeben. Der TNA wird in diesem Fall nicht von der Plattform angenommen. Nachricht wird durch die Bieteranwendung in einem sendSynchronousMessage-Request oder einem OSCI-Transport-Zustellauftrag an die Plattform übermittelt. |
ParticipationDeliveryReceipt | Plattform | Bieteranwendung | 0 | TNA-Eingangsquittung, die die Plattform im Rahmen einer sendSynchronousMessage-Transaktion, die eine Participation enthält, ausstellt bzw. im OSCI-Transport-Fall bei Feststellung des entsprechenden Nachrichteneingangs (siehe Kapitel „Abgabe von Angeboten, TNAs und Rückzügen via OSCI-Transport“). Referenziert die Nachrichten-ID der Participation-Nachricht des Clients, die TNA-ID unter der die Plattform den TNA verarbeitet hat (und mit der ggf. ein Rückzug durch den Teilnehmer veranlasst werden kann), enthält den Zeitpunkt des Nachrichteneingangs (KEIN kryptographischer Zeitstempel) und einen Indikator, ob der TNA fristgerecht (vor Ablauf der TNA-Einreichungsfrist) eingegangen ist. MUSS ebenso eine plattform-spezifische TNA-Eingangsquittung in einem Menschen-lesbaren Format (HTML, PDF) enthalten/referenzieren, die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen SOLL, um sie dem Teilnehmer anzuzeigen. KANN eine plattform-spezifische technische TNA-Eingangsquittung enthalten/referenzieren (bspw. im XML-Format), die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen kann. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. Zusätzlich (im Falle der TNA-Einreichung via XVergabe-sendSynchronousMessae-Operation) AUCH in der sendSynchronousMessage-Response. Die beiden Quittung MÜSSEN inhaltlich identisch sein. Quittung enthält abweichend zu anderen fachlichen Nachrichten auch die ResponseInformation (Fehler, Warning, OK). |
ParticipationWithdrawal | Bieteranwendung | Plattform | 0..* | TNA-Rrückzug. Referenziert einen konkreten zurückzuziehenden TNA über die TNA-ID, die die Plattform bei TNA-Einreichung ausgestellt und in der ParticipationDeliveryReceipt mitgeteilt hat. Kann eine textuelle Angabe zum Grund des Rückzuges aufnehmen. KANN Anlagen aufnehmen (auch zur Begründung des Rückzuges). Sofern die ITP für den TNA-Rückzug ein Signaturniveau (ungleich NONE) festlegt, SOLL mindestens eine der Anlagen ein mit dem geforderten Signaturniveau signiertes Dokument des Teilnehmers enthalten. |
ParticipationWithdrawalDeliveryReceipt | Plattform | Bieteranwendung | 0 | TNA-Rückzugseingangsquittung, die die Plattform im Rahmen einer sendSynchronousMessage-Transaktion, die einen ParticipationWithdrawal enthält, ausstellt bzw. im OSCI-Transport-Fall bei Feststellung des entsprechenden Nachrichteneingangs (siehe Kapitel „Abgabe von Angeboten, TNAs und Rückzügen via OSCI-Transport“). Referenziert die Nachrichten-ID der ParticipationWithdrawal-Nachricht des Clients, enthält den Zeitpunkt des Nachrichteneingangs (KEIN kryptographischer Zeitstempel) und einen Indikator, ob der Rückzug fristgerecht (vor Ablauf der TNA-Einreichungsfrist) eingegangen ist. MUSS ebenso eine plattform-spezifische TNA-Rückzugseingangsquittung in einem Menschen-lesbaren Format (HTML, PDF) enthalten/referenzieren, die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen SOLL, um sie dem Teilnehmer anzuzeigen. KANN eine plattform-spezifische technische TNA-Rückzugseingangsquittung enthalten/referenzieren (bspw. im XML-Format), die sich die Bieteranwendung mittels getDocument-Operation von der Plattform abrufen kann. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. Zusätzlich (im Falle des TNA-Rückzugs via XVergabe-sendSynchronousMessae-Operation) AUCH in der sendSynchronousMessage-Response. Die beiden Quittung MÜSSEN inhaltlich identisch sein. Quittung enthält abweichend zu anderen fachlichen Nachrichten auch die ResponseInformation (Fehler, Warning, OK). |
ResultNotice | Plattform | Bieteranwendung | 0 | Zuschlagsmitteilung/Absage/Information über nächste Verhandlungsrunde Kann weitere Dokumente referenzieren (bspw. Zuschlagsdokument der Vergabestelle). MUSS im Rahmen von Teilnahmewettbewerben von der Plattform genutzt werden, um Teilnehmer, die nicht zur Angebotsabgabe aufgefordert werden, formal abzusagen. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. |
ServerInquiry | Plattform | Bieteranwendung | 0 | Antwort auf Bieterfragen bzw. generelle Kommunikation mit Bietern. Analog zu ClientInquiry aufgebaut, jedoch können Anlagen nicht direkt in der Nachricht geführt sondern lediglich referenziert und MÜSSEN für einen Abruf via getDocument-Operation bereitgestellt werden. Antworten an Bieterfragen in einem Verfahren MÜSSEN allen Verfahrensteilnehmern gleichzeitig zugestellt werden. Die jeweiligen Nachrichten-IDs der ServerInquiry-Nachrichten MÜSSEN jedoch pro Teilnehmer verschieden sein. Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. |
TenderMetaInformation | Plattform | Bieteranwendung | 0 | allgemeine Verfahrensinformationen Dies ist ein zentrales Dokument innerhalb der XVergabe-Kommunikationsschnittstelle. Sie MUSS unmittelbar mit jedem Statuswechsel für alle angemeldeten Teilnehmer ausgestellt bzw. aktualisiert werden. Eine TMI wird über den Verfahrensverlauf kontinuierlich aktualisiert. Zu jedem Zeitpunkt im Vergabeverfahren existiert die TMI aber nur in ihrem aktuellen Zustand. Sie enthält die folgenden Informationen:
Nachricht wird der Bieteranwendung von der Plattform zum Abruf mittels getMessages bereitgestellt. Wird also in einer getMessages-Response transportiert. |
Anchor | ||||
---|---|---|---|---|
|
Wie oben ausgeführt dienen die ITT- bzw. ITP-Nachrichten der Strukturierung der Auftrags- bzw. Teilnahmeunterlagen und der Definition der Struktur des erwarteten Angebots bzw. des TNAs. Nachfolgend soll kurz charakterisiert werden, wie dies durch die XVergabe-Kommunikationsschnittstelle umgesetzt wird.
Die Auftrags- bzw. Teilnahmeunterlagen bestehen in der ITT bzw. ITP aus mindestens einem oder mehreren Dokumenten mit folgenden Informationen:
Über die vorgenannten Nachrichten und Dokumente hinaus definiert die XVergabe-Kommunikationsschnittstelle zwei weitere Dokumente, welche nicht über Nachrichten ausgetauscht werden.
Diese zwei Dokumente (OfferContent bzw. ParticipationContent) beschreiben ein Datenmodell für jeweils eine XML-Datei (OfferContent.XML bzw. ParticipationContent.XML), die als Meta-Datei Teil des (verschlüsselten) Angebots- bzw. TNA-Containers sein MUSS. Eine Bieteranwendung MUSS diese Datei somit erzeugen und in die Angebotscontainer vor Verschlüsselung einstellen. Sofern eine Containersignatur im ITT bzw. ITP seitens der Vergabeplattform gefordert wurde, so MUSS die Bieteranwendung diese Datei (und NUR diese) mit dem geforderten Signaturniveau elektronische signieren. Wird keine Containersignatur gefordert SOLL die entsprechende Datei nicht signiert werden. Die Datei MUSS in den jeweiligen primaryContainer eingestellt werden. Sie DARF NICHT im secondarycontainer geführt werden. Die Datei SOLL bei Öffnung des Angebots/des TNAs durch die Plattform/das Vergabemanagementsystem ausgewertet werden können. Eine darauf aufbauende Kommunikation in Richtung des Bieters/Teilnehmers ist in der XVergabe-Kommunikationsschnittstelle nicht vorgesehen.
Die Dokumente enthalten folgende Informationen:
Anchor | ||||
---|---|---|---|---|
|
Ein Vergabeverfahren durchläuft unterschiedliche Phasen, die eine Plattform über die XVergabe-Kommunikationsschnittstelle mitteilen MUSS, da hiervon die weitere Steuerung der möglichen und notwendigen Nachrichtenarten abhängt. Darüber hinaus dient das Status-Modell auch der informatorischen Anzeige ggü. dem Bieter.
Der Phasen- bzw. Statusübergang in Abhängigkeit von Entscheidungspunkten im Verfahren wird durch nachfolgende Abbildung verdeutlicht:
Dies ist der initiale Status eines Verfahrens mit Teilnahmewettbewerb. Daher DARF dieser Status NICHT für Verfahren ohne TNW genutzt werden (bspw. offenes Verfahren). Innerhalb dieser Phase erstellen die potentiellen Teilnehmer basierend auf den bereitgestellten Teilnahmeunterlagen eigene Teilnahmeanträge und reichen diese auf der Plattform ein.
Diese Phase endet mit der Frist zur Einreichung von Teilnahmeanträgen. Wird diese Frist erreicht, MUSS eine Plattform den Verfahrensstatus auf „Participation Evaluation Phase“ ändern und dies durch das Versenden einer aktualisierten TMI-Nachricht an alle am Verfahren angemeldeten Nutzer bekanntgeben.
In diesem Status MUSS die Plattform alle WebService-Operationen sowie alle darin übermittelten Nachrichten und Dokumente unterstützen. Sie KANN jedoch Nachrichten zur Angebotseinreichung bzw. -rückzug ablehnen.
In der “Participation Evaluation Phase” eines Verfahrens werden die eingereichten Teilnahmeanträge ausgewertet. Sie MUSS somit mit der Erreichung der TNA-Einreichungs-Frist beginnen. Die Phase DARF KEIN valider Ausgangs- bzw. Start-Status eines Verfahrens sein und DARF NUR bei Verfahren mit Teilnahmewettbewerb auftreten.
In dieser Phase MUSS eine Plattform alle WebService-Operationen mit Ausnahme der subscribe-Operation unterstützen. Die Plattform MUSS weiterhin alle austauschbaren Nachrichten und Dokumente unterstützen. Sie KANN jedoch Nachrichten zur Angebotseinreichung bzw. -rückzug ablehnen. Die (verspätete) Einreichung von Teilnahmeanträgen bzw. deren Rückzüge KANN durch eine Plattform weiterhin auch nach Erreichen der TNA-Einreichungsfrist unterstützt werden.
Diese Phase endet mit der Auswahl derjenigen Bieter, die zur Angebotserstellung aufgefordert werden sollen. Die Plattform MUSS den Statuswechsel durch das Versenden einer aktualisierten TMI an alle am Verfahren angemeldeten Teilnehmer anzeigen. Mit Bereitstellung einer TMI MUSS sie ebenfalls Invitation To Tender Nachrichten (Aufforderungen zur Angebotsabgabe), die die Vergabeunterlagen enthalten, an die ausgewählten Bieter sowie Result Notices an die nicht ausgewählten Teilnehmer bereitstellen.
Die “Bidding Phase” eines Verfahrens ist die Phase, in der die Vergabeunterlagen den (ggf. zuvor ausgewählten) Bietern zugänglich gemacht werden und in der die Angebote der Bieter erstellt und eingereicht werden.
Es muss hinsichtlich der Durchführung eines Teilnahmewettbewerbs unterschieden werden:
Der Beginn dieser Phase MUSS die Bereitstellung einer TMI-Nachricht angezeigt werden. Ebenso MÜSSEN den (ggf. durch TNW ausgewählten) Bietern die Vergabeunterlagen mittels ITT-Nachricht bereitgestellt werden.
Handelt es sich um Verhandlungsverfahren, so MUSS aus TMI und ITT die Verhandlungsrunde eindeutig hervorgehen. Die Angaben MÜSSEN in Abhängigkeit des Fortschritts des Verhandlungsverfahrens NICHT übereinstimmen.
Weiterhin MUSS die Plattform alle Nachrichten/Dokumente AUSGENOMMEN denen zur Einreichung bzw. Rückzug von Teilnahmeanträgen unterstützen.
Diese Phase endet mit Erreichen der Angebotseinreichungsfrist und MUSS durch die Plattform durch Bereitstellung einer aktualisierten TMI Nachricht an alle am Verfahren angemeldeten Teilnehmer angezeigt werden.
In der “Tender Evaluation Phase” werden die durch die Bieter eingereichten Angebote durch die Vergabestelle ausgewertet. Diese Phase MUSS mit Erreichen der Angebotseinreichungsfrist beginnen und durch das Versenden einer aktualisierten TMI an alle Verfahrensteilnehmer angezeigt werden.
In dieser Phase MÜSSEN alle WebService-Operationen mit AUSNAHME der subscribe-Operation durch die Plattform unterstützt werden. Ebenso MÜSSEN alle Nachrichten- und Dokumente mit AUSNAHME von TNA-Einreichungen und -Rückzügen unterstützt werden. Eine Plattform SOLL weiterhin die Nachrichten zur Angebotsabgabe und -Rückzug auch nach Erreichen der Angebotseinreichungsfrist unterstützen.
Die Phase endet mit dem Bereitstellen einer aktualisierten TMI an alle Verfahrensteilnehmer. Dies bedeutet auch, dass die Result Notices, welche den Zuschlag an den ausgewählten Bieter bzw. die Absage an die unterlegenen Bieter innerhalb dieser Phase übermittelt werden MÜSSEN.
Handelt es sich beim Vergabeverfahren um ein Verhandlungsverfahren kann auf die Tender Evaluation Phase eine neue Bidding Phase folgen. Dies muss durch das Hochzählen des Verhandlungsrundenzählers im TMI angezeigt werden.
Dieser Verfahrensstatus wird mit dem Zuschlag vergeben. In dieser “Phase” MUSS das Verfahren für die Verfahrensteilnehmer sichtbar bleiben und noch weitere (Bieter-) Kommunikation ermöglichen. Über den Zeitraum, für wie lange nach dem Zuschlag dieser Status aufrechterhalten bleiben muss, entscheidet die Vergabestelle bzw. deren Vergabeplattform.
In dieser Phase des Verfahrens SOLL die Plattform lediglich die WebServices-Operationen und die darin auszutauschenden Nachrichten und Dokumente unterstützen, die für eine Bieterkommunikation notwendig sind. Dies bedeutet die Plattform MUSS die Operationen „sendMessage“, „getMessages“, „getDocument“ und „getTenderIDs“ für das Verfahren unterstützen. Die Operationen „sendSynchronousMessage“ und „getOSCITransferID“ MUSS eine Plattform für ein Verfahren dieses Status mit einem Errorcode zurückweisen, da sie lediglich der Angebots- bzw. TNA-Einreichung bzw. deren Rückzügen dienen. Ebenso KANN die Plattform die subscribe-Operation unterbinden, um nicht weitere (unnötige) Anmeldungen zu diesem Verfahren zu ermöglichen.
Weiterhin MUSS die Plattform lediglich Inquiry-Nachrichten/Dokumente für das Verfahren unterstützen. Die weiteren Nachrichten/Dokumente MUSS sie ablehnen.
Die Phase endet mit der Entscheidung der Vergabestelle bzw. -plattform, das Verfahren zu archivieren. Dies wird einem Teilnehmer (bzw. dessen Client) nicht explizit angezeigt. Durch das Archivieren des Verfahrens wird es via XVergabe-Kommunikationsschnittstelle nicht mehr zugänglich gemacht.
Wenn eine Vergabestelle entscheidet, das Verfahren einzustellen bzw. aufzuheben, so MUSS diese Entscheidung technisch durch die Bereitstellung einer aktualisierten TMI-Nachricht an alle Verfahrensteilnehmer bekanntgemacht werden. Die Phase/Status ist identisch zum Status „CLOSED“, macht jedoch den Fakt der Aufhebung explizit deutlich.
Dies ist kein “offizieller” Verfahrensstatus aus Sicht der XVergabe-Kommunikationsschnittstelle, sondern eher ein aus Sicht der Plattform interner Verfahrensstatus. In diesem ist das Verfahren für den Zugriff via XVergabe nicht (mehr) sichtbar. Für ein archiviertes Verfahren stehen somit keine WS-Operationen zur Verfügung und MÜSSEN von der Plattform somit abgewiesen werden.
Die Entscheidung, wann ein Verfahren archiviert wird, obliegt der Vergabestelle bzw. deren -plattform.
Status | Zugelassene Web-Service-Operation | Zugelassene Nachrichten | ||||||
---|---|---|---|---|---|---|---|---|
Subscribe | getTenderIDs | getMessages | getDocument | sendMessage | sendSynchronous | getOSCITransferID | ||
Participation Phase |
|
|
|
|
|
|
| |
Participation Evaluation Phase |
|
|
|
|
|
|
|
|
Bidding Phase | mit TNW |
| ||||||
ohne TNW | ||||||||
Tender Evaluation Phase |
|
| ||||||
Closed |
|
|
|
| ||||
Cancelled |
|
|
|
| ||||
(Archived) |
|
|
|
|
|
|
|
|
Nachfolgend werden einige ausgewählte Anwendungsszenarien der XVergabe-Kommunikationsschnittstelle näher charakterisiert.
Damit ein Wirtschaftsteilnehmer mit einer XVergabe-konformen Bieteranwendung an einem Verfahren teilnehmen kann, MUSS eine Plattform wie ausgeführt die subscribe-Operation der XVergabe-Kommunikationsschnittstelle implementieren.
Da jedoch davon auszugehen ist, dass Verfahren über deren Bekanntmachungen auf weiteren (externen) Portalen aufgefunden werden und eine neue Installation einer Bieteranwendung noch über keinerlei Kenntnisse über konkret zu benutzende bzw. benutzbare Vergabeplattformen und deren XVergabe-Services verfügt, SOLL folgender Ablauf einen Wirtschaftsteilnehmer in die Lage versetzen, die Bieteranwendung schnell zu nutzen. Dieser Prozess wird auch als Enrollment-Prozess bezeichnet:
Anchor | ||||
---|---|---|---|---|
|
Wie ausgeführt erlaubt die XVergabe-Kommunikationsschnittstelle der Plattform für die Angebots- und TNA-Abgabe festzulegen, diese per OSCI-Transport durchzuführen. Ein Rückzug MUSS immer über den gleichen Transportweg erfolgen, wie die Einreichung des zurückzuziehenden Objekts, d.h. wird für die Angebotsabgabe OSCI-Transport als Zustellweg in der ITT definiert, so ist ein Angebotsrückzug durch die Bieteranwendung ebenso via OSCI-Transport durchzuführen.
Um den OSCI-Transport-Zustellweges nutzen zu können, MUSS eine Plattform, sofern sie den Zustellweg definiert, in der ITT/ITP folgende Informationen bereitstellen:
Auf Basis dieser Informationen ist es einer Bieteranwendung möglich, das Angebot bzw. den TNA als OSCI-Nachricht nach dem OSCI-Transport-Szenario „One-Way-Message, aktiver Empfänger“ durch einen so genannten Zustellauftrag auf dem OSCI-Intermediär bzw. in das Verfahrenspostfach hinein abzugeben.
Folgende Anforderungen werden hierbei an die Kommunikationspartner gestellt:
Der Ablauf ist schematisch in nachfolgender Abbildung zusammengefasst:
Anchor | ||||
---|---|---|---|---|
|
Auftrags- bzw. Teilnahmeunterlagen bzw. deren Bestandteile sind innerhalb einer ITT bzw. ITP versionierbar. Hierzu MUSS die Plattform eine neue ITT- bzw. ITP-Nachricht (mit neuer Nachrichten-ID) bereitstellen. Eine ITT/ITP ist innerhalb des Verfahrens (bei ITT Verfahrens-Los-Kombination) eindeutig, d.h. die ITT/ITP DARF NICHT anhand ihrer Nachrichten-ID eindeutig im Verfahren gehalten werden. Die Nachrichten-ID muss sich durch die Versionierung ändern. Die ITT/ITP kann anhand der Verfahrens-ID (bzw. ggf. der Angaben zu Losen bei ITT) zum Verfahren bzw. ggf. zu den Losen zugeordnet werden. Darin SOLLEN die Unterlagen jeweils wie folgt versioniert werden (sofern notwendig):
Die Bieteranwendung SOLL die ITT/ITP-Versionen und deren Dokumentenstruktur von providedDocuments anhand der Dokumenten-IDs, Veröffentlichungsdaten und Dokumentenreferenzen/Attachment-IDs vergleichen und ggf. entfallene/neue Dokumente (geänderte providedDocuments) feststellen und abrufen.
Die hier beschriebene XVergabe Schnittstelle stellt einen standardisierten Zugang zu Vergabeplattformen bereit. Es ist davon auszugehen, dass Vergabeplattformen weiterhin spezifische Zugänge (in der Regel über Web-Oberflächen oder dedizierte Clientanwendungen) bereitstellen.
Eine XVergabe-konforme Plattform MUSS sicherstellen, dass alle Auftrags-, Teilnahme- und Vergabeunterlagen via XVergabe abgerufen bzw. bereitgestellt werden können, sofern ein Bieter via XVergabe am Verfahren teilnimmt (subscribe aufgerufen hat). Weiterhin MÜSSEN die übrigen Anwendungsfälle unterstützt werden.
Es bleibt der Plattform überlassen, ob sie die über XVergabe ausgetauschten Nachrichten dem Bieter über den plattformspezifischen Zugang ebenfalls zugänglich macht, oder nicht. Gleiches gilt umgekehrt.
Für den Sonderfall, dass ein Bieter via plattformspezifischen Zugang ein Angebot abgeben hat, und die Plattform eine Angebotsquittung auch via XVergabe bereitzustellen wünscht, so kann die Plattform den Wert des Elements xvergabe-if:messages.OfferDeliveryReceipt/xvergabe-if:document/xvergabe-docs:processedOfferDetails/xvergabe-docs:offerMessageID
frei vergeben (selbst erzeugen), da keine zugehörige XVergabe-Offer-Nachricht existiert, welche hier referenziert werden könnte. Die Plattform kann in allen weiteren ähnlichen Fällen analog verfahren.