<extra> Schnittstellenspezifikation d . Version einheitliches XML-basiertes Transportverfahren

Transkript

1 <extra> einheitliches XML-basiertes Transportverfahren Schnittstellenspezifikation d Version Stand der Spezifikation: Version: Redaktion: Deutsche Rentenversicherung Bund Referat 0552 Berner Strasse Würzburg Verfahrensverantwortlich: Christoph Bißantz Telefon 0931/ christoph.bissantz@drv-bund.de Techn. Verantwortlich: Florian Stratil Telefon 0931/ florian.stratil@drv-bund.de

2 Seite: 2 0 Allgemeines Das vorliegende Dokument dient als Grundlage für die Kommunikation zwischen den teilnehmenden D -Anbietern und der Datenstelle der Rentenversicherung (DSRV) im Verfahren D . Das Dokument unterteilt sich in zwei Abschnitte. Teil A Allgemeine Informationen Teil B Beschreibung der Elemente In Teil A werden nur die allgemeinen Parameter und Voraussetzungen der Kommunikationsbeziehung erläutert. In Teil B wird auf die einzelnen Elemente der verwendeten extra-profilierung eingegangen. Änderungsübersicht Version Datum Kap. Änderungsgrund Bearbeiter Alle Initiale Erstellung des Dokuments F.Stratil Alle Finale Abstimmung des Dokuments F.Stratil , Anpassung URL, Ergänzung zu Verschlüsselung und Signatur F.Stratil Komprimierung angepasst F.Stratil Seite 2 von 22

3 Seite: 3 1 sverzeichnis 0 Allgemeines sverzeichnis Teil A Allgemeine Informationen Grafischer Überblick Geschäftsprozesse Server-Adressen Authentifizierung Verwendetes extra-schema Profile-Attribut des Root-Elements Nutzdatenbeschreibung Verschlüsselung / Komprimierung (DataTransforms) Beschreibung der einzelnen Geschäftsprozesse Zugangseröffnung Verwendung der ResponseID Teil B Beschreibung der Elemente Verwendete Namensräume und Präfixe Aufbau des Transport-Headers Transport-Header des Request Transport-Header der Response Aufbau des TransportPlugins Aufbau des DataTransforms-Plugins Request Zugangseröffnung Element Transport Element TransportHeader Element TransportPlugins Element TransportBody Element Data Element Base64CharSequence Response Zugangseröffnung Element Transport Element TransportHeader Element TransportBody Anhang Seite 3 von 22

4 Seite: StatusCodes Referenzierte Dokumente Abbildungsverzeichnis Seite 4 von 22

5 Seite: 5 2 Teil A Allgemeine Informationen 2.1 Grafischer Überblick Geschäftsprozesse Folgende Grafik zeigt den Ablauf des in diesem Dokument beschriebenen Geschäftsprozesses auf Client D Anbieter Server Rentenversicherung Zugangseröffnung Request Zugangseröffnung Response zum Request Abb. 1 Grafischer Ablauf der Kommunikation 2.2 Server-Adressen Bei den Test- und Produktionsservern der DSRV handelt es sich um physikalisch getrennte Server. Aus diesem Grund werden unterschiedliche Adressen verwendet Testsystem: Produktionssystem: Authentifizierung Die Authentifizierung des Absenders findet beim Aufbau der https-verbindung über ein Client- Zertifikat statt. Zum Einsatz kommt in diesem Verfahren ein Zertifikat der DRV Bund. Für die Kommunikationsverschlüsselung wird TLS 1.2 verwendet. 2.4 Verwendetes extra-schema Zum Einsatz kommt das extra-basisschema in der Version Profile-Attribut des Root-Elements Folgendes Profile Attribut müssen alle Geschäftsprozesse im Root Element einbinden. Seite 5 von 22

6 Seite: Nutzdatenbeschreibung Die für die Zugangseröffnung oder -widerruf notwendigen Daten werden als gesondertes XML-Schema zur Verfügung gestellt. Die Daten werden verschlüsselt als Base64-CharSequence im TransportBody des extra-schemas übermittelt. In der Regel erfolgt die Umwandlung der verschlüsselten Nutzdaten in einen Base64-kodierte Zeichenkette durch den Parser. Eine vorherige Umwandlung ist nicht notwendig und kann ggf. zu Problemen in der Kommunikation führen. Pro Aufruf wird nur ein Datensatz übermittelt Encoding Die Nutzdaten sind als ISO codiert Verschlüsselung / Komprimierung (DataTransforms) Die fachlichen Nutzdaten in den Geschäftsprozessen werden mit dem PKCS7 verschlüsselt. Hierbei werden die Nutzdaten mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und signiert. Verwendete Verschlüsselung: Um die Integrität der Daten zu gewährleisten, müssen die verschlüsselten Nutzdaten vom Absender mit seinem privaten Schlüssel signiert werden Reihenfolge der Komprimierung und der Verschlüsselung Die im DataTransforms beschrieben Komprimierung und Verschlüsselung hat folgende Sortierung. Die Reihenfolge der Schritte wird über das Attribut order festgelegt. 1. Komprimierung der Daten GZIP oder unkomprimiert, beschrieben in den einzelnen Geschäftsprozessen 2. Verschlüsselung der Daten mit PCKS7 2.5 Beschreibung der einzelnen Geschäftsprozesse An dieser Stelle werden die im Abschnitt 2.1 dargestellten Geschäftsprozesse beschrieben Zugangseröffnung Dieser Prozess dient der Zuordnung der D -Adresse zu einer Versicherungsnummer. Procedure: DataType: Scenario (Optional): Mögliche Komprimierungen: Beim Senden der Daten sind die Paketebenen nicht vorgesehen. Ein Beispiel XML kann der Datei 01-request.xml entnommen werden. Seite 6 von 22

7 Seite: Verwendung der ResponseID Die jeweiligen Zugangseröffnungen werden auf Seiten der DSRV mit einer eindeutigen Ticketnummer verbunden über die sich die Sendung verfolgen lässt. Diese wird in den ResponseDetails der Response auf den Vorgang Zugangseröffnung an den Client übermittelt. Diese Ticketnummer bleibt über den gesamten Verarbeitungsvorgang der Sendung bei der DSRV mit der Sendung verknüpft um den Status der Sendung verfolgen zu können. Dies erleichtert die Suche bei Fehlern und Rückfragen. Seite 7 von 22

8 Seite: 8 3 Teil B Beschreibung der Elemente 3.1 Verwendete Namensräume und Präfixe Innerhalb der extra-kommunikation werden folgende Namensräume verwendet: Namensraum Präfix xreq xres xcpt xplg xs 3.2 Aufbau des Transport-Headers Da der generelle Aufbau des Transport-Headers bei allen Anfragen identisch ist, wird er an dieser Stelle zentral beschrieben Transport-Header des Request Auszug aus der Schema-Datei: Abb. 2 Aufbau Request-Header Element TransportHeader xreq:transportheader Enthält die relevanten Steuerungsinformationen, die zwischen Sender und der DSRV als Empfänger auszutauschen sind xreq:transport Element Sender xcpt:sender Enthält SenderID des Absenders Seite 8 von 22

9 Seite: 9 xreq:transportheader Element SenderID xcpt:senderid Eindeutige Kennung des Absenders xs:string Element Receiver xcpt:receiver Enthält ReceiverID des Empfängers xreq:transportheader Element ReceiverID xcpt:receiverid Betriebsnummer Empfänger; muss immer Betriebsnummer der DSRV sein xs:string xcpt:receiver Element RequestDetails xcpt:requestdetails Diverse Request-spezifische Informationen xreq:transportheader Element RequestID xcpt:requestid ID des Requests, eindeutiger Begriff aus der Begriffswelt des Senders zur genauen Identifikation des Sendevorgangs z.b. Auftragsnummer aus dem System des Senders xs:string xcpt:requestdetails Element TimeStamp Seite 9 von 22

10 Seite: 10 xcpt:timestamp Ein Zeitstempel z.b T15:09:00 zum Beginn der Übertragung des Senders xs:datetime xcpt:requestdetails Element Application xcpt:application Enthält Product und Manufacturer xcpt:requestdetails Element Product xcpt:product Bezeichnung eines (Software-) Produkts des Senders xs:string xcpt:application Element Manufacturer xcpt:manufacturer Herstellerbezeichnung des Software-Produktes des Senders xs:string xcpt:application Element Procedure xcpt:procedure Der zulässige ist in Teil A unter 2.5 Beschreibung der einzelnen Geschäftsprozesse beschrieben. xs:anyuri xcpt:requestdetails Element DataType xcpt:datatype Mit dem DataType wird der jeweilige Geschäftsprozess bei der DSRV adressiert. Der zulässige ist in Teil A unter 2.5 Beschreibung der einzelnen Geschäftsprozesse beschrieben. Seite 10 von 22

11 Seite: 11 xs:anyuri xcpt:requestdetails Element Scenario xcpt:scenario Mit dem optionalen Element Scenario wird die Art des Datenaustauschs zwischen Client und Server definiert. Der zulässige ist in Teil A unter 2.5 Beschreibung der einzelnen Geschäftsprozesse beschrieben. xs:anyuri xcpt:requestdetails Seite 11 von 22

12 Seite: Transport-Header der Response Beim Transport Header der Response handelt es sich um eine Kopie des Request-Headers, die um die Informationen des Empfängers ergänzt wird. Abb. 3 Aufbau Transport-Header Response Element TransportHeader xres:transportheader Enthält die relevanten Steuerungsinformationen, die zwischen Sender und der DSRV als Empfänger auszutauschen sind xres:transport Der Response Header ist nach extra-philosophie eine Kopie des RequestHeaders, den der Empfänger lediglich um die ResponseDetails ergänzt. Damit ist sichergestellt, dass beide Seiten alle Informationen in einer Datenstruktur finden, die ein Vorgang beim Sender und beim Empfänger auslöst Element Sender xcpt:sender Enthält SenderID des Absenders, Original aus Request xres:transportheader Element SenderID xcpt:senderid Das Element wurde unter Element SenderID des Request-Headers beschrieben. Original aus Request Element Receiver Seite 12 von 22

13 Seite: 13 xcpt:receiver Enthält ReceiverID des Empfängers, Original aus Request xres:transportheader Element ReceiverID xcpt:receiverid Das Element wurde unter Element ReceiverID des Request-Headers beschrieben. Original aus Request Element RequestDetails xcpt:requestdetails Diverse Request-spezifische Informationen, Original aus Request Die RequestDetails werden im Transport Header der Response unverändert mit allen Unterelementen aus dem Request übernommen. xres:transportheader Element ResponseDetails xcpt:responsedetails Diverse Response-spezifische Informationen, die die DSRV als Empfänger dem ursprünglichen Sender zur Verfügung stellt xres:transportheader Element ResponseID xcpt:responseid Eindeutige fortlaufende nummerische Meldungsnummer aus der DSRV Monitordatenbank, die den Vorgang beim Empfänger eindeutig identifiziert. Diese ID erleichtert die Suche und Nachvollziehbarkeit der Sendung während der Verarbeitung. xs:string xcpt:responsedetails Element TimeStamp xcpt:timestamp Ein Zeitstempel z.b T15:09:00 der das Eingangsdatum beim Empfänger repräsentiert. Seite 13 von 22

14 Seite: 14 xs:datetime xcpt:responsedetails Element Report xcpt:report Report zum Empfangsvorgang dieser Lieferung Höchste Gewichtung der Art des Reports xs:anyuri Im unprofilierten extra-schema ist es möglich im Report mehrere Flag-Elemente anzuführen, die jeweils einen eigenen Report beinhalten. Innerhalb dieses Verfahrens wird immer nur ein Report zurückgeliefert, weshalb die höchste Gewichtung immer der Gewichtung des Reports entspricht. Mögliche e für highestweight sind: wenn der Request angenommen oder verarbeitet werden konnten wenn es bei der Verarbeitung des Requests zu einem Fehler gekommen ist Element Flag xcpt:flag Einzelne Statusrückmeldung Gewichtung des Reports xs:anyuri Mögliche e siehe Attribut highestweight Element Code xcpt:code Alphanummerischer Statuscode (Siehe Anhang StatusCodes) xs:string Seite 14 von 22

15 Seite: 15 xcpt:report Element Text xcpt:text Text zum Statuscode xs:string xcpt:report Seite 15 von 22

16 Seite: Aufbau des TransportPlugins Aufbau des DataTransforms-Plugins Im DataTransforms-Plugin wird die Verschlüsselung und Komprimierung der Nutzdaten beschrieben Element DataTransforms xplg:datatransforms Enthält die Informationen, wie die Nutzdaten für den Transport aufbereitet wurden 1.2 xs:string Element Compression xplg:compression Enthält die Informationen zur Komprimierung der Daten 1 xs:positiveinteger Element Algorithm xplg:algorithm Verwendete Kompression Bezeichnung der Komprimierung. Der zulässige wird in Teil A unter 2.5 Beschreibung der einzelnen Geschäftsprozesse beschrieben. xs:anyuri Element InputData Seite 16 von 22

17 Seite: 17 xplg:inputdata Enthält die Größe der Nutzdaten vor der Komprimierung Dateigröße in Bytes xs:nonnegativeinteger Element Encryption xplg:encryption Enthält die Verschlüsselungsinformation 2 xs:positiveinteger Element Algorithm xplg:algorithm Verwendeter Verschlüsselungs-Algorithmus Bezeichnung der Verschlüsselung Der zulässige wird in Teil A unter Verschlüsselung / Komprimierung (DataTransforms) beschrieben. xs:anyuri Element OutputData xplg:outputdata Enthält die Größe der Nutzdaten nach der Verschlüsselung Dateigröße in Bytes Seite 17 von 22

18 Seite: 18 xs:nonnegativeinteger Seite 18 von 22

19 Seite: Request Zugangseröffnung Abb. 4 Aufbau Request Zugangseröffnung Element 1.4 siehe Profile-Attribut des Root-Elements xs:anyuri Element TransportHeader xreq:transportheader Die Elemente und der Aufbau des Transport-Headers werden im Abschnitt Transport-Header des Request beschrieben xreq:transport Element TransportPlugins xreq:transportplugins Enthält das DataTransforms-Plugin. Der Aufbau wird in den Abschnitten Aufbau des DataTransforms-Plugins beschrieben. xreq:transport Element TransportBody xreq:transportbody Enthält den Body der Transportebene des Requests Seite 19 von 22

20 Seite: 20 xreq:transport Element Data xcpt:data Enthält die fachlichen Daten gemäß den Angaben in den RequestDetails procedure und datatype. Die Nutzdaten werden wie im Teil A Nutzdatenbeschreibung und Verschlüsselung / Komprimierung (DataTransforms) beschrieben behandelt. xreq:transportbody Element Base64CharSequence xcpt:base64charsequence Base64-Zeichenfolge der verschlüsselten Nutzdaten xs:base64binary xcpt:data 3.5 Response Zugangseröffnung Element 1.4 siehe Profile-Attribut des Root-Elements xs:anyuri Element TransportHeader xres:transportheader Enthält die relevanten Steuerungsinformationen, die zwischen Sender und der DSRV als Empfänger auszutauschen sind. Der Aufbau ist unter Transport-Header der Response beschrieben. xres:transport Der Response Header ist nach extra-philosophie eine Kopie des RequestHeaders, den der Empfänger lediglich um die ResponseDetails ergänzt. Damit ist sichergestellt, dass beide Seiten alle Informationen in einer Datenstruktur finden, die ein Vorgang beim Sender und beim Empfänger auslöst. Seite 20 von 22

21 Seite: Element TransportBody xres:transportbody Enthält einen leeren Body der Transportebene xres:transport Die Response des Empfängers auf einen Sendevorgang Zugangseröffnung, enthält nur eine technische Bestätigung, jedoch keine fachlichen Daten des Fachverfahrens. Deshalb ist das Element TransportBody leer. Seite 21 von 22

22 Seite: 22 4 Anhang 4.1 StatusCodes Statuscode Text Erläuterung C00 E01 Daten erfolgreich angenommen Daten fehlerhaft oder unvollständig Die Daten zur Zugangseröffnung wurden erfolgreich angenommen Die Daten zur Zugangseröffnung konnten nicht angenommen werde E02 Kunde unbekannt Auf Grund der übermittelten Daten konnte keine eindeutige Zuordnung zu einer Versicherungsnummer durchgeführt werden. E50 Technischer Fehler Bei der Bearbeitung ist es zu einem technischen Fehler gekommen. Bitte probieren Sie es zu einem späteren Zeitpunkt noch einmal oder wenden Sie sich an die Hotline E84 Schwerer Ausnahmefehler Es ist ein schwerer Ausnahmefehler aufgetreten. Bitte wenden Sie sich an die Hotline I E E E E Legende: I und E stehen für die Gewichtung im Report: I(nfo) und E(rror) 4.2 Referenzierte Dokumente Name des Dokuments RegistrierungExtra.zip Beschreibung Zip-Datei mit Schnittstellendokumentation, profilierten Schema-Dateien und Beispielen 4.3 Abbildungsverzeichnis Abb. 1 Grafischer Ablauf der Kommunikation 5 Abb. 2 Aufbau Request-Header 8 Abb. 3 Aufbau Transport-Header Response 12 Abb. 7 Aufbau Request Zugangseröffnung 19 Seite 22 von 22