API-Webdienste als zweiter Übertragungsweg der Marktkommunikation

Kurzantwort

Für einige regulierte Prozesse der Energiewirtschaft schreibt die Bundesnetzagentur den Austausch über API-Webdienste vor. Der Aufruf ist dann ein HTTP-Request mit JSON-Nutzdaten. Die inhaltlichen Regeln stehen in der API-Guideline des BDEW, die Regeln des Übertragungswegs in den Regelungen zum Übertragungsweg für API-Webdienste.

Abgesichert wird dieser Weg über TLS nach BSI TR-03116-3 und über Zertifikate der Smart Metering-PKI des BSI in der Rolle EMT.API. Beim Aufruf werden creationDateTime, transactionId und, soweit vorhanden, initialTransactionId als HTTP-Kopfzeilen mitgesendet und mit der Nutzlast signiert. In der asynchronen Antwort benennt referenceId die transactionId des Aufrufs.

Die fachliche Besonderheit: Der Auslöser entscheidet, nicht die Technik. Ist ein Prozess als API-Prozess beschrieben, hilft kein EDIFACT-Übertragungsweg. Umgekehrt wird kein AS4-Prozess dadurch zu einem API-Prozess, dass ein Endpunkt erreichbar ist.

Zwei Übertragungswege in einem Regelwerk

Die Marktkommunikation kannte lange genau einen Weg für den Nachrichtenaustausch: eine Übertragungsdatei, die über AS4 verschickt wird. AS4 und die Smart-Metering-PKI beschreibt diesen Weg im Detail. Daneben ist ein zweiter Weg getreten, der nicht mit Dateien arbeitet.

Die API-Guideline trennt die Begriffe sauber. Ein API-Anbieter stellt einen Webservice bereit, über den die API nutzbar ist. Ein API-Nutzer greift als Client darauf zu. Der Kommunikationsendpunkt ist die URL samt Port, unter der der Webservice erreichbar ist (API-Guideline 1.0a, Kap. 2.2 Glossar). Diese drei Rollen sind pro API-Webdienst zu klären, und sie fallen nicht mit Ihnen und Ausbeuter zusammen: Wer einen Dienst bereitstellt und wer ihn aufruft, kann je Use-Case wechseln.

Die Trennung von Inhalt und Transport gilt hier genauso wie bei AS4, nur mit anderer Schnittstelle. Bei AS4 wandert eine EDIFACT-Übertragungsdatei durch den Kanal. Bei einem API-Webdienst wandert ein JSON-Objekt im HTTP-Body, und die Fachlichkeit steckt in Ressource, Methode und Feldern. Wer beide Wege gedanklich gleichsetzt, plant die falschen Tests.

Wann ein Prozess als API läuft

Die API-Guideline nennt den Grund für den zweiten Weg in ihrem ersten Satz: Gemäß den Festlegungen der Bundesnetzagentur zu den Universalbestellprozessen (BK6-22-128) und zum 24-Stunden-Lieferantenwechsel (BK6-22-024) sind einige Prozesse über API-Webdienste zu realisieren (API-Guideline 1.0a, Kap. 1 Einleitung). Der Auslöser liegt also im Regulierungstext, nicht in einer Technikpräferenz.

Der typische Fall ist eine Abfrage mit sofortigem Antwortbedarf. Bei einem Steuerungshandlung in Verbindung mit einem intelligenten Messsystem braucht die anfragende Seite eine Antwort, die sie unmittelbar weiterverarbeiten kann. Dafür sind kurze Aufrufe mit direkter Rückmeldung geeigneter als ein Dateiaustausch mit asynchronen Rückmeldungen. Denselben Zusammenhang nennt die Einleitung der Regelungen zum Übertragungsweg, wenn sie auf die Steuerungshandlungen in Verbindung mit intelligenten Messsystemen verweist (RzÜ API-Webdienste 1.1, Kap. 1 Einleitung).

Der zweite Fall ist eine Auskunft, die vorher telefonisch oder per Datei lief. Die Bundesnetzagentur beschreibt für die Konsultation zum Umsetzungstermin 01.10.2026, dass der API-Webdienst zur Ermittlung der MaLo-ID der Marktlokation in mehrere fachlich getrennte Dienste überführt wurde, um die Kopplung zwischen Anfrage- und Antwortlogik zu reduzieren (BNetzA Mitteilung Nr. 55, Abschnitt API-Webdienste). Diese Ermittlung ist damit kein Dateiaustausch über einen Prüfidentifikator, sondern eine Abfrage an einen Dienst.

Für die Projektplanung folgt daraus eine Reihenfolge. Zuerst den Use-Case im geltenden Regelwerk suchen. Dann prüfen, ob dort ein API-Webdienst oder ein Nachrichtentyp beschrieben ist. Erst danach über Format, Anbindung und Testfälle entscheiden.

Der Aufruf selbst

Ein Aufruf ist ein HTTP-Request, und die Antwort darauf ist zunächst nur ein Statuscode. Er sagt aus, ob der Aufruf technisch beim Empfänger angekommen ist. Der Code 202 bedeutet, dass die Anfrage technisch erfolgreich verarbeitet wurde, Nutzdaten liefert er nicht zurück. Die fachliche Rückmeldung erfolgt danach asynchron, sofern die Prozessbeschreibung eine Rückmeldung zu diesem Vorgang vorsieht (API-Guideline 1.0a, Kap. 3.5 http-Status-Code). Wer den Statuscode 202 als fachliche Bestätigung liest, verwechselt Transport und Inhalt.

Die Guideline führt genau einen positiven Statuscode: 202. Für Fehlerfälle nennt sie 400, 401, 404, 405, 415, 429, 500, 503 und 504. Bei 429 hat der Client zu viele Anfragen in einem Zeitfenster gestellt, er soll pausieren. Bei 503 und 504 lautet die Empfehlung: später erneut versuchen (API-Guideline 1.0a, Kap. 3.6.1 und 3.6.2 Status Codes).

Die Versionierung folgt Semantic Versioning im Schema <MAJOR>.<MINOR>.<PATCH>. Inkompatible Änderungen erhöhen die Major-Version, und alle URLs enthalten den Major-Anteil mit einem kleinen „v“ als Präfix, etwa /v1. Die Antwort muss im HTTP-Header X-BDEW-VERSION die vollqualifizierte Versionsnummer enthalten (API-Guideline 1.0a, Kap. 3.2 Versionierung). Beim Betrieb einer Verbindung ist der Header der schnellste Beleg dafür, welche Fassung der Gegenüber tatsächlich fährt.

Anpassungen kommen planbar. Das Änderungsmanagement der EDI@Energy-API-Webdienste erfolgt bis zu zweimal im Jahr. Inkompatible Änderungen werden im Rahmen des Änderungsmanagements angekündigt, und der Umstellungszeitraum beträgt mindestens drei Monate ab Veröffentlichung der neuen Version (API-Guideline 1.0a, Kap. 3.2.1 und 3.2.2).

Wiederholungen gehören zum Entwurf dazu. API-Anbieter müssen grundsätzlich in der Lage sein, allen berechtigten Clients gleichzeitig einen TCP-Verbindungsaufbau zu ermöglichen. Clients müssen Anfragen wiederholen, wenn die Web-API nicht erreichbar ist oder Fehler meldet, und dabei geeignete Pausen einlegen (API-Guideline 1.0a, Kap. 3.6.3 Resilienz). Ohne Pausen erzeugt eine Wiederholungsschleife genau die Überlastung, auf die der Server bereits mit 429 oder 503 antwortet.

Jeder API-Webdienst trägt feste Felder: transactionId, creationDateTime und initialTransactionId; dazu referenceId, wenn sich eine Antwort auf eine Anfrage beziehen muss (API-Guideline 1.0a, Kap. 3.4 Bestandteile). Die Idempotenz hängt an diesen Feldern. Bei jeder Anfrage und jedem Retry vergibt der Client eine neue transactionId und die creationTime. Beim Retry gibt er in initialTransactionId die transactionId des Erstaufrufs mit, damit wiederholte Anfragen technisch als derselbe Vorgang erkennbar sind (API-Guideline 1.0a, Kap. 3.4.1).

Die folgende Übersicht stellt die Felder und die zugehörige Pflicht zusammen. Sie folgt Kapitel 3.4 und 3.4.1 der API-Guideline.

Die Nutzdaten stehen als JSON-Objekt im HTTP-Body. Jedes Objekt muss in UTF-8 ohne Byte Order Mark geschrieben werden und das Format I-JSON nach RFC 7493 einhalten. JSON-Objekte sind weder im HTTP-Header noch in Query-Parametern erlaubt (API-Guideline 1.0a, Kap. 3.7 Objekte). Umlaute sind in Bezeichnern unzulässig, und für primitive Datentypen sind ausschließlich die OpenAPI-Formate nach ISO und IETF zu verwenden (API-Guideline 1.0a, Kap. 3.3 Datentypen und JSON-Standardisierung).

Sicherheit: PKI, TLS und Signatur

Der Übertragungsweg API-Webdienste hat ein eigenes Regelwerk. Die kryptographischen Vorgaben der BSI TR-03116-3 sind grundsätzlich anzuwenden, und die Nutzung der Smart Metering-PKI des BSI ist nach § 52 Abs. 4 MsbG vorzusehen (RzÜ API-Webdienste 1.1, Kap. 1 Einleitung).

Auf der Netzwerkebene gilt: Alle Kommunikationsendpunkte werden durch DNS-Namen bestimmt, nicht durch IP-Adressen. Die Webservices müssen IPv4 implementieren und sollten IPv6 implementieren. Auf der Transportebene ist TLS nach den Regeln der TR-03116-3 einzusetzen, und die Erweiterung Server Name Indication ist zu unterstützen und zu verwenden (RzÜ API-Webdienste 1.1, Kap. 3.1 und 3.2).

Darüber liegt eine zweite Ebene. Jede API-Interaktion und die übertragene Nutzlast wird signiert. Das gilt für HTTP-Requests und für synchrone Responses mit Nutzlast. In die Signatur gehen vier Dinge ein: die Ressource samt Query-Parametern, die Kopfzeilen creationDateTime und transactionId, soweit vorhanden initialTransactionId, und die Nutzlast. Vor der Hashberechnung wird das JSON-Objekt nach RFC 8785 kanonisiert (RzÜ API-Webdienste 1.1, Kap. 3.3 Inhaltsdatensicherungsebene).

Digest und Signatur liegen base64-kodiert in den HTTP-Kopfzeilen X-BDEW-DIGEST und X-BDEW-SIGNATURE, das Zertifikat mit dem verwendeten öffentlichen Schlüssel in X-BDEW-CERT. Wichtig für die Erwartung an den Kanal: Die übertragenen Parameter und die Nutzlast werden nicht verschlüsselt. Der Schutz entsteht über TLS und über die Signatur, die Manipulation sichtbar macht, nicht über eine Verschlüsselung des Inhalts (RzÜ API-Webdienste 1.1, Kap. 3.3).

Ein Hinweis, der in Projekten häufig fehlt: Alle für die fachliche Verarbeitung erforderlichen Parameter müssen in der Signatur enthalten sein. Alle weiteren HTTP-Header sind rein informatorisch und dürfen die fachliche Verarbeitung nicht beeinflussen (RzÜ API-Webdienste 1.1, Kap. 3.3). Wer eine fachliche Steuerung in einen eigenen Header legt, baut einen Weg an der Signaturprüfung vorbei.

Zertifikate und Verzeichnisdienst

Die Kommunikation sichern Zertifikate der Smart Metering PKI. Die Vorgaben der Certificate Policy der SM-PKI sind einzuhalten. Nach dem Rollenkonzept der SM-PKI nehmen API-Nutzer und Anbieter die Rolle passiver EMT ein, sofern keine Regelung außerhalb dieses Regelwerks die Rolle eines aktiven EMT verlangt (RzÜ API-Webdienste 1.1, Kap. 4 Zertifikate und PKI).

Für den neuen Zertifikatstyp EMT.API nennt das Regelwerk vier Anforderungen (RzÜ API-Webdienste 1.1, Kap. 4.3):

1. Der CommonName wird nach dem Schema <org>.EMT.API<extension> gebildet.
2. Das Feld Organisational Unit im Subject enthält die Marktpartner-ID.
3. Der Parameter im Feld „Alternativer Antragstellername“ mit der Ausprägung UniformResourceIdentifier ist vorhanden und enthält die Adresse des genutzten Verzeichnisdiensts.
4. Ein EMT.API-Zertifikat kann für einen oder mehrere API-Webdienste genutzt werden.

Der Verzeichnisdienst ist der Teil, der in der Anbindung am häufigsten unterschätzt wird. Jeder Marktpartner muss einen dezentralen Verzeichnisdienst beauftragen oder betreiben, der Metadaten zu seinen Zertifikaten veröffentlicht und insbesondere zur API-Kennung den zugehörigen Endpunkt als URL nennt. Die API-Kennungen stehen im EDI@Energy-Dokument „Anwendungsübersicht der Prüfidentifikatoren“ (RzÜ API-Webdienste 1.1, Kap. 4.2 Verzeichnisdienst). Diese Übersicht führt die API-Kennung in einer eigenen Spalte neben dem Übertragungsweg. Für einen Prozess, der über einen API-Webdienst läuft, steht dort „API“ statt „AS4“, und die Zeile trägt eine Kennung wie API00003 für die Ermittlung der MaLo-ID. Die Spalte entscheidet damit vor jeder Technikfrage, welcher Weg gilt. Ohne gültigen Eintrag im Verzeichnisdienst findet der Gegenüber den Endpunkt nicht, und die fachlich korrekte Anbindung bleibt unerreichbar.

Der Zertifikatswechsel folgt einem festen Raster. Der Inhaber muss die Nachfolgezertifikate spätestens zehn Werktage vor dem Ungültigwerden bereitgestellt haben. So entsteht ein Überlappungszeitraum von mindestens zehn Werktagen, in dem altes und neues Zertifikat gültig sind. Die Marktpartner stellen innerhalb dieser Frist um (RzÜ API-Webdienste 1.1, Kap. 4.5 Zertifikatswechsel).

Zertifikate, die vor dem Wechsel auf EMT.API für die API-Webdienste zur prozessualen Abwicklung von Steuerungshandlungen in Verbindung mit intelligenten Messsystemen ausgestellt wurden und die die neuen Anforderungen nicht erfüllen, dürfen bis zum Gültigkeitsende weiter genutzt werden (RzÜ API-Webdienste 1.1, Kap. 4.4 Übergangsregelung). Diese Bestandsregel erklärt, warum in einem Netzgebiet beide Zertifikatstypen auftreten können. Sie ist kein Fehler, sondern ein übergangsweise zulässiger Zustand.

Beispiel: MaLo-ID ermitteln als API-Aufruf

Ein Lieferant will eine Marktlokation beliefern und kennt die MaLo-ID nicht. Statt eine Datei zu schicken, ruft sein System einen API-Webdienst auf. Der Anlass ist im Regelwerk benannt: Der Use-Case Ermittlung der MaLo-ID der Marktlokation aus GPKE Teil 2 ist gemäß der Festlegung BK6-22-024 über API-Webdienste zu realisieren (OpenAPI-Definition zur Ermittlung der MaLo-ID, info.description).

Die veröffentlichte Schnittstelle führt dafür drei Pfade, alle als POST (OpenAPI-Definition, Abschnitt paths):

Vereinfachtes Beispiel für den Aufruf, Adresse gekürzt. Der Client sendet an den Endpunkt des Netzbetreibers einen POST auf /maloId/request/v1. Er setzt transactionId und creationDateTime als HTTP-Kopfzeilen und gibt beim Retry initialTransactionId als weitere Kopfzeile mit. Im Body steht ein identificationParameter mit dem Pflichtfeld identificationDateTime, der Energieflussrichtung consumption oder production und der Anschrift (OpenAPI-Definition, Schema identificationParameter).

{
  "identificationDateTime": "2026-10-01T00:00:00Z",
  "energyDirection": "consumption",
  "identificationParameterAddress": { "zipCode": "10117", "city": "Berlin" }
}

Der Netzbetreiber antwortet mit 202. Das heißt: technisch angekommen, mehr nicht. Sucht er die Marktlokation, sendet er selbst einen POST auf /maloId/dataForMarketLocationPositive/v1. Die Zuordnung zum Vorgang läuft über referenceId in der Query, gefüllt mit der transactionId aus der Anfrage. Im Body steht resultPositive mit der gefundenen dataMarketLocation, dazu die zugehörigen Messlokationen, Tranchen und technischen Ressourcen. Die MaLo-ID darin ist elftstellig (OpenAPI-Definition, Schema maloId). Passt kein Treffer, kommt stattdessen /maloId/dataForMarketLocationNegative/v1 mit resultNegative und einem Antwortcode aus dem Entscheidungsbaum.

Bricht die Verbindung vor der Rückmeldung ab, wiederholt der Client seine Anfrage. Er vergibt eine neue transactionId, gibt aber in initialTransactionId die transactionId des Erstaufrufs mit. Der Netzbetreiber erkennt daran denselben Vorgang und legt ihn nicht doppelt an.

Wer diesen Dienst anbindet, muss mit Anpassungen rechnen. Die Bundesnetzagentur hat den Dienst zur Ermittlung der MaLo-ID in der Konsultation zum Umsetzungstermin 01.10.2026 in mehrere fachlich getrennte Dienste überführt, um die Kopplung zwischen Anfrage- und Antwortlogik zu reduzieren (BNetzA Mitteilung Nr. 55, Abschnitt API-Webdienste). Aus drei Pfaden können dann mehr werden.

Folgen und Fehlerfälle

Fehlerfall: falscher Übertragungsweg. Das Team überträgt einen API-Prozess über EDIFACT oder umgekehrt. Die Technik läuft, der Prozess nicht. Prüfen Sie zuerst den Regelwerkstext zum Use-Case.

Fehlerfall: 202 als fachliche Bestätigung. Der Vorgang gilt als erledigt, obwohl die asynchrone Rückmeldung fehlt. Behandeln Sie jeden Statuscode als technische Aussage und verfolgen Sie die Rückmeldung separat.

Fehlerfall: referenceId fehlt in der Rückmeldung. Die Antwort kommt an, lässt sich aber keinem Vorgang zuordnen. Ohne diese Referenz bleibt offen, zu welcher Anfrage die gefundene Marktlokation gehört.

Fehlerfall: 404 statt Inhalt. Der Aufruf läuft auf einen Pfad, den der Gegenüber nicht führt, oder auf eine Fassung, die dort nicht aktiv ist. Prüfen Sie Pfad, Major-Version und den Stand der Schnittstelle beim Gegenüber, nicht die Suchkriterien.

Fehlerfall: Treffer ohne Messlokation. Ein positiver Bescheid enthält eine pauschale Marktlokation ohne Messlokation. Das ist kein Datenfehler; die Schnittstelle kennzeichnet diese Angaben als nicht erforderlich, weil es Messlokationen nicht in jedem Fall gibt.

Fehlerfall: Retry ohne Idempotenz. Bei einem Timeout wiederholt das System den Aufruf mit einer neuen transactionId, ohne initialTransactionId mitzugeben. Der Anbieter sieht zwei Vorgänge. Die Felder aus Kapitel 3.4.1 sind kein Beiwerk.

Fehlerfall: fehlender Verzeichniseintrag. Zertifikat und Endpunkt sind vorhanden, der Gegenüber findet den Dienst aber nicht, weil der Eintrag im dezentralen Verzeichnisdienst fehlt.

Fehlerfall: fachliche Steuerung im Zusatz-Header. In einem selbst gewählten Header steckt eine fachliche Angabe. Die Signatur deckt ihn nicht ab, und die fachliche Verarbeitung darf von ihm nicht abhängen. Nehmen Sie solche Angaben in die Nutzlast auf.

Fehlerfall: Zertifikatswechsel zu spät. Die Nachfolgezertifikate liegen nicht zehn Werktage vor Ablauf vor. Der Überlappungszeitraum fehlt, und die Umstellung wird zum Zeitproblem.

Typische Missverständnisse

„API-Webdienste ersetzen AS4.“ Der Übertragungsweg API-Webdienste steht neben dem dateibasierten Weg. Er gilt nur für die Prozesse, die dafür vorgesehen sind.

„Ein API-Aufruf transportiert auch EDIFACT.“ Der Aufruf trägt ein JSON-Objekt im Body. Das ist der Grund, warum API-Prozesse nicht über Prüfidentifikatoren und Dateiformate beschrieben werden.

„TLS verschlüsselt die Nutzlast.“ Das Regelwerk sagt ausdrücklich, dass die übertragenen Parameter und die Nutzlast nicht verschlüsselt werden. Der Schutz kommt über TLS und über die zusätzliche Signatur.

„Ein Zertifikat gilt für meinen ganzen Marktpartner.“ Ein EMT.API-Zertifikat kann für einen oder mehrere API-Webdienste genutzt werden, und die API-Kennung gehört in den Verzeichniseintrag.

„Die API-Guideline schreibt die Prozesse vor.“ Sie beschreibt Design-Regeln wie URL-Aufbau, Versionierung, Datentypen und Statuscodes. Welcher Prozess über eine API läuft, steht in den Festlegungen und im AHB.

„Der API-Webdienst zur MaLo-ID ist ein Dienst.“ Die veröffentlichte Schnittstelle führt drei Pfade: die Anfrage, die positive und die negative Rückmeldung. Wer nur /maloId/request/v1 anbindet, kann die Antwort nicht verarbeiten.

„Ein API-Webdienst ist nur eine andere AS4-Verkleidung.“ Der Übertragungsweg API-Webdienste hat ein eigenes Regelwerk, eine eigene Signatur über den HTTP-Kopfzeilen und einen eigenen Zertifikatstyp EMT.API.

Von AS4 zu API-Webdiensten

Die folgende Gegenüberstellung fasst zusammen, was sich mit dem zweiten Weg ändert. Sie folgt den Regelungen zum Übertragungsweg für API-Webdienste, Kapitel 3 und 4, und der API-Guideline, Kapitel 3.

Quellen und Pflegehinweis

Tragende Quelle für die Aufrufform ist die API-Guideline des BDEW in der Fassung 1.0a vom 1. Oktober 2024. Die Regeln des Übertragungswegs stehen in der Anlage zur Mitteilung Nr. 46, Version 1.1 vom 1. Oktober 2024, anzuwenden ab 3. April 2025. Für das Beispiel trägt die veröffentlichte OpenAPI-Definition zur Ermittlung der MaLo-ID die Pfade, Methoden und Schemas.

Die API-Guideline liegt inzwischen auch als Fassung 1.0b vor (BDEW: API-Guideline 1.0b). Ich habe diese Fassung nicht ausgewertet; welcher Stand aktuell verbindlich ist, prüfen Sie beim BDEW-Forum Datenformate, bevor Sie eine Fassung zitieren.

Der Grund: Die Bundesnetzagentur stellt im Rahmen des Änderungsmanagements zweimal im Jahr die sich ändernden EDI@Energy-Dokumente zur Konsultation (BNetzA Mitteilung Nr. 55, Abschnitt API-Webdienste). Für den Umsetzungstermin 01.10.2026 stehen die API-Webdienste Strom in Release 2.0.0 zur Konsultation, und der Dienst zur Ermittlung der MaLo-ID wurde dabei in mehrere fachlich getrennte Dienste überführt. Zur verbesserten Lesbarkeit stellt EDI@Energy ergänzend eine OpenAPI-Dokumentation bereit, die ausschließlich der unterstützenden und informativen Darstellung dient. Prüfen Sie bei jedem Release vier Dinge: die Fassung der API-Guideline, die Version der Regelungen zum Übertragungsweg für API-Webdienste, den Stand des Repository der API-Webdienste und die API-Kennungen in der Anwendungsübersicht der Prüfidentifikatoren. Für den Umsetzungstermin 01.10.2026 stehen die API-Webdienste Strom in Release 2.0.0 zur Konsultation, und der Dienst zur Ermittlung der MaLo-ID wurde dabei in mehrere fachlich getrennte Dienste überführt. Zur verbesserten Lesbarkeit stellt EDI@Energy ergänzend eine OpenAPI-Dokumentation bereit, die ausschließlich der unterstützenden und informativen Darstellung dient. Prüfen Sie bei jedem Release vier Dinge: die Fassung der API-Guideline, die Version der Regelungen zum Übertragungsweg für API-Webdienste, den Stand des Repository der API-Webdienste und die API-Kennungen in der Anwendungsübersicht der Prüfidentifikatoren.

• BDEW: API-Guideline, Version 1.0a
• Bundesnetzagentur/BDEW: Regelungen zum Übertragungsweg für API-Webdienste, Version 1.1
• Bundesnetzagentur: Mitteilung Nr. 55 zu den Datenformaten, Konsultation für den Umsetzungstermin 01.10.2026
• EDI@Energy: OpenAPI-Definition zur Ermittlung der MaLo-ID der Marktlokation
• EDI@Energy: API-Webdienste Strom im Repository

Abrufdatum aller Quellen: 16. September 2026.