A_27473 - Performance - PoPP-Service - Messung von Bearbeitungszeiten

Der PoPP-Service MUSS alle Zeiten zu einem Request/Response-Paar aufzeichnen und verarbeiten. Unterzeiträume werden gleichzeitig gesondert gemessen und verarbeitet.

Rahmenbedingungen:
Die Zeit (in ms) vom vollständigen Eingang eines Requests an der Außenschnittstelle bis hin zum Start des Versands einer Antwortnachricht (Response) an derselben ist die Gesamtbearbeitungszeit. Die Gesamtbearbeitungszeit unterteilt sich ggf. in Unterzeiträume, die gesondert gemessen und ausgewertet werden (z.B. gemäß A_27477* und A_27030*).

Die vom PoPP-Service zu verantwortende Bearbeitungszeit umfasst alle Zeiten, die der PoPP-Service zur Bearbeitung des Requests selbstständig aufwendet. Die vom PoPP-Service zu verantwortende Bearbeitungszeit erfasst NICHT die Zeiten, die den Abruf an Drittsysteme (z.B. an OCSP) betreffen. [<=]

A_26178 - Performance - Selbstauskunft - Umsetzungszeit zur Änderung des Lieferintervalls

Der Anbieter MUSS die Änderung der Konfiguration vom Lieferintervall (gemäß [A_26177*]) nach Aufforderung durch die gematik innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

TIP1-A_6437 - Datenaufbewahrung von Performancedaten

Anbieter (ausgenommen ist TSP CVC eGK) MÜSSEN die Performancedaten 6 Monate aufbewahren.

A_26175 - Performance - Selbstauskunft - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Daten zur Selbstauskunft gewährleisten. [<=]

A_23042 - Verifikation der Certificate Transparency für TLS Verbindungen in die VAU

Die Hersteller der Fachdienste MÜSSEN prüfen ob die CA, welche die TLS Zertifikate für Verbindungen in den sicheren Verarbeitungskontext eines sektoralen Identity Provider erstellt hat, Certificate Transparency gemäß RFC 6962/RFC 9162 unterstützt. [<=]

A_23349 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag

Das Produkt MUSS folgende Servicezeiten gewährleisten: 

• Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr
• Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.

A_27719 - Telemetriedatenlieferung - Nutzung eines gültigen Client-Zertifikats

Der Anbieter MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik ein gültiges TLS Client-Zertifikat nutzen.
Hinweis: Ein entsprechendes TLS Client-Zertifikat muss vor Inbetriebnahme bei der gematik beantragt werden. [<=]

A_28890 - Verbindungsaufbau zum Telemetriedaten-Service

Der Anbieter MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik einen OAuth 2.0 Token Exchange (gem. RFC 8693) unterstützen.

Hinweis:
Die Basis für die Authentifizierung muss im Rahmen der Inbetriebnahme bei der gematik durchgeführt werden.  [<=]

A_28891 - Verbindungsaufbau zum Telemetriedaten-Service des Produkts

Das Produkt MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik einen OAuth 2.0 Token Exchange (gem. RFC 8693) unterstützen.

Hinweis:
Die Basis für die Authentifizierung muss im Rahmen der Inbetriebnahme bei der gematik durchgeführt werden. [<=]

A_28866 - Auswahl der Domain für TLS-terminierte Vertrauenswürdige Ausführungsumgebungen (VAU)

Der Anbieter, der eine TLS-Terminierte VAU betreibt, MUSS diese Endpunkte unter einer eigenständigen Domain betreiben, die für nichts anderes als Endpunkte dieser VAU verwendet wird.

Hinweis:
Um Überschneidungen der Namensräume von Zertifikaten zu vermeiden, also dass zum Beispiel ein *.firma.tld Zertifikat auch den vep1.firma.tld (oder ein *.sub1.fima.tld auch vep1.sub1.firma.tld) VAU Endpunkt umfasst, wird die Verwendung einer eigenständigen Second-Level Domain vorgeschrieben, die für nichts anderes als VAU Endpunkte des selben Betreibers verwendet werden darf.
Ist eine VAU über mehrere Endpunkten zu erreichen, so sind diese jeweils als alternative Namen (Subject Alternative Name) im Zertifikat aufzuführen.
Die Nutzung von Wildcard-Zertifikaten ist nicht zulässig. [<=]

A_28886 - Verbot von wildcard-Namenseinträgen für TLS-terminierte VAU Endpunkte

Zertifikate für TLS-Terminierte VAU Endpunkte DÜRFEN NICHT Wildcard-Namesseinträge beinhalten. [<=]

A_23006 - Subdomäne für Webservice-Endpunkte in der VAU

Der Verarbeitungskontext des sektoralen IDP MUSS diese Endpunkte anbieten:

• Endpunkt für Authorization Requests
• Endpunkt für Pushed Authorization Requests
• Token-Endpunkt

A_26332 - Performance - PoPP-Service - Verfügbarkeit

Der Anbieter PoPP-Service MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

• Hauptzeit: 99,99%
• Nebenzeit: 99,97%

A_26335 - Performance - PoPP-Service - Skalierung

Der Anbieter PoPP-Service MUSS die Skalierbarkeit des angebotenen Dienstes im laufenden Betrieb jederzeit gewährleisten und der gematik nachvollziehbar darstellen. Dazu dokumentiert er das eingesetzte Skalierungskonzept im Betriebshandbuch.

Hinweis: Im Zuge des Zulassungsverfahrens hat der Anbieter PoPP-Service der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann. [<=]

A_26336 - Performance - PoPP-Service - Robustheit gegenüber Lastspitzen

Der PoPP-Service MUSS auch bei Lastspitzen oberhalb der definierten Spitzenlasten gemäß der Tabelle "Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben" verfügbar bleiben.
[<=]

A_27030 - Performance - PoPP-Service - Bearbeitungszeit unter Last

Der PoPP-Service MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben" erfüllen.

Tabelle 1: Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben

A_27030-01 - Performance - PoPP-Service - Bearbeitungszeit unter Last

Der PoPP-Service MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben" erfüllen.

Tabelle 2 Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben

A_27030-02 - Performance - PoPP-Service - Bearbeitungszeit unter Last

Der PoPP-Service MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben" erfüllen.

Tabelle 3 Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben

A_28839 - Performance - Telemetriedaten - Spezifika PoPP-Service - Duration

Der Anbieter PoPP-Service MUSS bei Telemetriedatenlieferung im Trace Span zugehörig zum Resource Server bzgl. des Feldes "rs_duration" die ermittelte Verarbeitungszeit im Ressource Server übertragen. [<=]

A_27477 - Performance - PoPP-Service - Bearbeitungszeiten für Unterzeiträume

Der PoPP-Service MUSS zu folgenden Zeiträumen eigene Unterzeiträume selbstständig erfassen, verarbeiten und im Rahmen des Monitorings weiterleiten.

• Backend-Duration: Zeit in ms für Anfragen an TI-Komponenten und Systeme außerhalb des PoPP-Service, z.B. OCSP.
• Resource Server-Duration: Zeit in ms bei jedem Aufruf des Resource Server ab Erhalt des Requests vom ZeTA-Guard bis zum vollständigen Versand der Antwort an den ZeTA-Guard.
• cardCheckTime: Zeit in ms bei jedem Aufruf mit Validierung einer eGK ab Start der APDU-Kommandos bis zum Abschluss der Bearbeitung der APDU-Kommandos.

A_27477-01 - Performance - PoPP-Service - Bearbeitungszeiten für Unterzeiträume

Der PoPP-Service MUSS folgende Zeiträume selbstständig erfassen und bei Telemetriedatenlieferungen als key / value Paar im Trace mitliefern.

• key "pdt_backend_duration":
• Zeit in ms für Anfragen an TI-Komponenten und Systeme außerhalb des PoPP-Service, z.B. OCSP
• Datentyp Integer
• key "pdt_checkcard_duration":
• Zeit in ms bei jedem Aufruf mit Validierung einer eGK ab Start der APDU-Kommandos bis zum Abschluss der Bearbeitung der APDU-Kommandos.
• Datentyp Integer

A_27729-01 - Performance - Telemetriedatenlieferung - Selbstauskunft

Der Produkttyp MUSS die in der Tabelle "Tab_gemSpec_Perf_Telemetriedaten_product_info" gelisteten Parameter des Open Telemetry Logs "product_info" befüllen und die Produktinformation bei jeder Änderung an den Telemetriedaten-Service überliefern.

Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik.
[<=]

A_28785 - Performance - Telemetriedatenlieferung - Bestandsdaten

Der Produkttyp MUSS die in der Tabelle "Tab_gemSpec_Perf_Telemetriedaten_metric" gelisteten Parameter unter Berücksichtigung der produktspezifischen Vorgaben als eine Open Telemetry Metrik befüllen und im festgelegten, konfigurierbaren Zeitintervall an den Telemetriedaten-Service überliefern.

Das Default Zeitintervall ist täglich, beginnend mit 00:00:00.

Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik. [<=]

A_28835 - Telemetriedaten - Spezifika PoPP-Service - Metrik PoPP-vital

Der PoPP-Service MUSS bei den Telemetriedaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:

A_28860 - Telemetriedaten - Spezifika PoPP-Service - Metrik PoPP-blockedItems

Der PoPP-Service MUSS bei den Telemetriedaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:

A_27319 - Performance - Bestandsdaten - Spezifika PoPP-Service - Format

Der Anbieter PoPP-Service MUSS jeweils zum Wechsel in den nächsten Berichtsintervall, folgende Informationen im JSON-Format als HTTP Body an die Betriebsdatenerfassung gemäß [A_23110*] liefern.

{ 
"timestamp": "<Zeitstempel der Abfrage gemäß ISO 8601 unter expliziter Angabe der Zeitzone UTC im konkreten Format: YYYY-MM-DDTHH:mm:ss[.fff]Z, als String>",
"ci": "<CI-ID der abgefragten Produktinstanz gemäß [A_17764], als String>",
"egkhashcount": <Anzahl der gespeicherten Hashwerte in der eGK-Hash-Datenbank gemäß [A_27046], als Integer>
} [<=]

A_27319-01 - Performance - Bestandsdaten - Spezifika PoPP-Service - Format

Der Anbieter PoPP-Service MUSS jeweils zum Wechsel in den nächsten Berichtsintervall, folgende Informationen im JSON-Format als HTTP Body an die Betriebsdatenerfassung gemäß [A_23110*] liefern.

{ 
"timestamp": "<Zeitstempel der Abfrage gemäß ISO 8601 unter expliziter Angabe der Zeitzone UTC im konkreten Format: YYYY-MM-DDTHH:mm:ss[.fff]Z, als String>",
"ci": "<CI-ID der abgefragten Produktinstanz gemäß [A_17764], als String>",
"egkhashcount": <Anzahl der gespeicherten Hashwerte in der eGK-Hash-Datenbank gemäß [A_27046], als Integer>
}

A_28190 - Performance - PoPP-Service - Bearbeitungszeiten für Operation PoPP.5

Der PoPP-Service MUSS unabhängig vom Füllstand der eGK-Hash-Datenbank, aber unter Berücksichtigung der in A_27046 vorgegebenen Maximalbefüllung der eGK-Hash-Datenbank in der Lage sein, die import-Funktion in weniger als einer Minute oder mit einer Geschwindigkeit von mindestens fünftausend Einträgen pro Sekunde zu verarbeiten.

Hinweis: Der Passus "weniger als eine Minute" ist relevant, wenn die signierte Nachricht nur wenige Einträge enthält. Der Passus "mindestens fünftausend Einträge pro Sekunde" ist relevant, wenn die signierte Nachricht sehr viele Einträge enthält. Wegen des Overheads der Signaturprüfung ist eine hohe Geschwindigkeit für signierte Nachrichten mit wenigen Einträgen nicht realistisch. Der Overhead der Signaturprüfung fällt für viele Einträge in einer signierten Nachricht nicht ins Gewicht. [<=]

A_28190-01 - Performance - PoPP-Service - Import Hash-DB

Der PoPP-Service MUSS unabhängig vom Füllstand der eGK-Hash-Datenbank, aber unter Berücksichtigung der in A_27046 vorgegebenen Maximalbefüllung der eGK-Hash-Datenbank in der Lage sein, die import-Funktion in weniger als einer Minute oder mit einer Geschwindigkeit von mindestens fünftausend Einträgen pro Sekunde zu verarbeiten.

Hinweis: Der Passus "weniger als eine Minute" ist relevant, wenn die signierte Nachricht nur wenige Einträge enthält. Der Passus "mindestens fünftausend Einträge pro Sekunde" ist relevant, wenn die signierte Nachricht sehr viele Einträge enthält. Wegen des Overheads der Signaturprüfung ist eine hohe Geschwindigkeit für signierte Nachrichten mit wenigen Einträgen nicht realistisch. Der Overhead der Signaturprüfung fällt für viele Einträge in einer signierten Nachricht nicht ins Gewicht.

A_27316 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Status

Der PoPP-Service MUSS bei Telemetriedatenlieferung im Trace Span zugehörig zum Resource Server bzgl. des Feldes "status" vorrangig den Fehlercode aus der Spalte "Errorcode" gemäß [A_27317] verwenden. In allen anderen Fällen ist der gültige, an den Client zurückgemeldete, HTTP-Response Code in das Feld einzutragen. [<=]

A_27316-01 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Status

Der PoPP-Service MUSS bei Telemetriedatenlieferung im Trace Span zugehörig zum Resource Server bzgl. des Feldes "rs_statuscode" vorrangig den Fehlercode aus der Spalte "BDE-Code" gemäß [A_27317] verwenden. In allen anderen Fällen ist der gültige, an den Client zurückgemeldete, HTTP-Response Code in das Feld einzutragen. [<=]

A_26333 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Operation

Der PoPP-Service MUSS bei Telemetriedatenlieferungen bzgl. des Feldes "operation" die Angabe der Spalte "UseCase" aus Tabelle [Tab_gemSpec_Perf_PoPP_Service: Performancerelevante UseCases] nutzen.

A_26333-01 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Operation

Der PoPP-Service MUSS bei Telemetriedatenlieferungen den Use Case eindeutig über die Trace Parameter attributes:http_method und attributes:http_route kenntlich machen. Zu berücksichtigen sind die Operationen der Tabelle [Tab_gemSpec_Perf_PoPP_Service: Performancerelevante UseCases].

A_26532 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Message

Der PoPP-Service MUSS bei Telemetriedatenlieferungen bzgl. des Feldes "message_keys" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

{ "cid": "$clientid", "cv": "$clientversion", "size": $size, "rsdur": $resourceServerDuration, "cct": $cardCheckTime, "ikn": $iknummer, "pmth": "$proofmethod", "telidP": "$pn_telematikID" }

• $clientid: <product_id> gemäß Token Self-Assessment des Clientsystems, Datentyp String
• $clientversion: <product_version> gemäß Token Self-Assessment des Clientsystems, Datentyp String
• $size: Größe des Requests in kilobyte, Datentyp Integer
• $resourceServerDuration: Zeit in ms für die Bearbeitungszeit im Resource-Server, Datentyp Integer 
• $cardCheckTime: Zeit in ms für die Echtheitsprüfung der eGK mittels APDU-Kommandos gem. [Kapitel 6.2.1 "eGK Handling"#gemSpec_PoPP_Service], Datentyp Integer
• $iknummer: Wert von insurerId des PoPP-Token gem. [A_26431*], Datentyp Integer
• $proofmethod: Wert von proofMethod aus dem PoPP-Token gem. [A_26431*], Datentyp String
• $telidP: Telematik-ID des angemeldeten Nutzers, verschlüsselt gemäß [A_28578*], Datentyp String.

A_26532-01 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Message

Der PoPP-Service MUSS bei Telemetriedatenlieferungen produkttypspezifische Informationen als key / value Paar im Trace mitliefern. 

• key "pdt_size":
• Größe des Requests in Kilobyte
• Datentyp Integer
• key "pdt_ikn"
• Wert von insurerId des PoPP-Token gem. [A_26431*]
• Datentyp Integer
• key "pdt_proofmethod" 
• Wert von proofMethod aus dem PoPP-Token gem. [A_26431*] 
• Datentyp String
• key "pdt_telidP"
• Telematik-ID des angemeldeten Nutzers, verschlüsselt gemäß [A_28578*]
• Datentyp String
• key "pdt_cardCheckTime"
• Zeit in ms für die Echtheitsprüfung der eGK mittels APDU-Kommandos gem. [Kapitel 6.2.1 "eGK Handling"#gemSpec_PoPP_Service]
• Datentyp Integer
• key "pdt_backend_duration":
• Zeit in ms für Anfragen an TI-Komponenten und Systeme außerhalb des PoPP-Service, z.B. OCSP
• Datentyp Integer
• key "pdt_directory_search_duration":
• Zeit in ms für Suche in Verzeichnissen und Systemen außerhalb des PoPP-Service, z.B. Verzeichnisdienst FHIR
• Datentyp Integer

A_27320 - Performance - Bestandsdaten - Spezifika PoPP-Service

Der Anbieter PoPP-Service MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Informationen berichten:

• Anzahl der vorhandenen eGK Hashes in der eGK-Hash-Datenbank, gemäß [A_27046].

A_28889 - Performance - Telemetriedaten - Spezifika PoPP-Service - RS Duration

Der PoPP-Service MUSS bei Telemetriedatenlieferung im Trace Span zugehörig zum Resource Server die Bearbeitungszeit im Felde "rs_duration" übermitteln.
[<=]

A_28786 - Performance - Telemetriedatenlieferung - Ausnahme der Vollständigkeit

Sofern aufgrund einer nicht vollständig durchgeführten Operation die Werte für die Parameter aus den produktspezifischen Vorgaben nicht vorliegen, KANN der Produkttyp bei der Telemetriedatenlieferung auf die Übermittlung des Key-Value-Paares verzichten. [<=]

A_28780 - Performance - Telemetriedatenlieferung - Batchverarbeitung RS

Das Produkt MUSS für die Telemetriedatenlieferung von Traces des Ressource Servers an den Telemetriedaten-Service des ZETA Guards als ExportProcessorType den Typ Batch verwenden (dies ist auch der Standardwert bei OpenTelemetry)
[<=]

A_28779 - Performance - Telemetriedatenlieferung - Konfiguration Datenlieferung RS

Das Produkt MUSS die Konfigurierbarkeit der Telemetriedatenlieferung des Ressource Servers an den Telemetriedaten-Service des ZETA Guards in einer ausgelagerten Konfiguration für folgende Parameter ermöglichen:

Batch - BatchExportOptions

• maxQueueSize (Default = 2048)
• scheduledDelayMilliseconds (Default = 5000)
• exporterTimeoutMilliseconds (Default = 30000)
• maxExportBatchSize (Default = 512)

• enabled (Default = true)
• initial_interval (Default = 5s)
• max_interval (Default = 1215s)
• max_elapsed_time (Default = 1820s)
• multiplier (Default = 3)

A_28782 - Performance - Telemetriedatenlieferung - Konfiguration Datenlieferung ZETA Guard

Das Produkt MUSS die Konfigurierbarkeit der Telemetriedatenlieferung des ZETA Guards an die gematik Telemetriedatencloud in einer ausgelagerten Konfiguration für folgende Parameter unterstützen:

Batch - BatchExportOptions

• maxQueueSize (Default = 2048)
  
• scheduledDelayMilliseconds (Default = 5000)
  
• exporterTimeoutMilliseconds (Default = 30000)
  
• maxExportBatchSize (Default = 512)
  

• enabled (Default = true)
  
• initial_interval (Default = 5s)
  
• max_interval (Default = 1215s)
  
• max_elapsed_time (Default = 1820s)
  
• multiplier (Default = 3)
  

• otel_traces_sampler (Default always_off)
• otel_traces_sampler_arg (Default 0)

A_28766 - Performance - Telemetriedatenlieferung - Konfiguration

Der Anbieter MUSS die Konfiguration der Parameter zur Telemetriedatenlieferung nach Aufforderung der gematik innerhalb von maximal 24h umsetzen. Dies gilt sowohl für die Telemetriedatenlieferung zwischen Ressource Server und dem Telemetriedaten-Service des ZETA Guards, als auch für die Telemetriedatenlieferung des ZETA Guards an die gematik Telemetriedatencloud. [<=]

A_28754 - Wiederherstellung Datenlieferung im Störungsfall

Der Anbieter MUSS zur Kompensation von Störungsfällen eine Wiederherstellungsstrategie mit OpenTelemetry Standardmechanismen implementieren, die sicherstellt, dass angefallene Telemetriedaten nachgeliefert werden können (z.B. ausreichend Speicherplatz, ausreichend Bandbreite - nicht abschließend).

Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik.
[<=]

A_27722-01 - Performance - Telemetriedatenlieferung - Status Code des Ressource Servers

Der Produkttyp MUSS im Parameter rs.status entweder einen HTTP-Statuscode des Ressource Servers gemäß Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes oder gemäß produkttypspezifischer Definition an den Telemetriedaten-Service  übermitteln.

Tabelle 4: Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes

A_27722-02 - Performance - Telemetriedatenlieferung - Status Code des Ressource Servers

Der Produkttyp MUSS im Parameter rs.status entweder einen HTTP-Statuscode des Ressource Servers gemäß Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes oder gemäß produkttypspezifischer Definition an den Telemetriedaten-Service  übermitteln.

Tabelle 5: Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes

A_27722-03 - Performance - Telemetriedatenlieferung - Status Code des Ressource Servers

Der Produkttyp MUSS im Parameter rs_statuscode entweder einen HTTP-Statuscode des Ressource Servers gemäß Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes oder gemäß produkttypspezifischer Definition an den Telemetriedaten-Service  übermitteln.

Tabelle 6: Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes

A_27722-04 - Performance - Telemetriedatenlieferung - Status Code des Ressource Servers

Der Produkttyp MUSS im Parameter rs_statuscode entweder einen HTTP-Statuscode des Ressource Servers gemäß Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes oder gemäß produkttypspezifischer Definition an den Telemetriedaten-Service  übermitteln.

Tabelle 7: Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes