Über arc42

arc42, das Template zur Dokumentation von Software- und Systemarchitekturen.

Template Version {revnumber}. {revremark}, {revdate}

Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. Siehe https://arc42.org.

1. Einführung

Die gematik entwickelt im Auftrag des Bundesgesundheitsminiteriums die mobile Applikation „eRezept“. Auf den Plattformen iOS und Android bietet diese App Services rund um das eRezept an. Um den Benutzern besseren Komfort bieten zu können, sollen die Applikationen um Push Notifications erweitert werden.

1.1. Aufgabenstellung

Das auslösende System von Notifications ist im ersten Schritt der eRezept-Fachdienst innerhalb der geschützten TI (Telematikinfrastruktur). Weitere Ausbaustufen können der ePA-Fachdienst oder die Messenger TIM bzw. KIM sein.

Das Gesamtsystem und die Aufgaben des Push-Gateways sind in gemF_PushNotification_V1.0.0 beschrieben, insbesondere in Kapitel 5.2. Zusätzlich liegt das Push-Notification-Konzept der gematik zu Grunde. Diese konkreten Anforderungen sind bei der Leistungserbringung zu berücksichtigen.

2. Randbedingungen

Entwicklungsumgebung

Es ist die Entwicklungsumgebung des Kunden zu nutzen, insbesondere gitlab (Repositories) und Jenkins (Continuous Integration). Dies bedingt Zugänge zu den entsprechenden Systemen für die beteiligten Entwickler, siehe Stakeholder.

Betrieb

Das System soll in einer bestimmten Betriebsumgebung betrieben werden, konkret in den google-Kubernetes-Umgebungen der gematik. Dies bedingt die Bereitstellung des Systems in Form von Docker-Images mit geeigneten Deploymentskripten in Form von Helm-Charts.

3. Kontextabgrenzung

Das Push-Gateway abstrahiert verschiedene Push-Service-Anbieter wie z. B. Apple Push Notification Service (APNS) und Firebase. Es ist im Wesentlichen getrieben durch Anforderungen, sogenannte AFOs, die von der gematik spezifiziert und veröffentlicht werden. Dem Push-Gateway liegen in diesem Kontext insbesondere die AFOs aus der gematik-Spezifikation gemF_PushNotification_V1.1.0 zugrunde.

Diese werden dort in Kapitel 5.2 beschrieben und lauten im Einzelnen:

  • [A_27164] - Push Gateway - OpenApi_Notification_PushGateway

  • [A_27165-01] - Push Gateway - Push Notification senden – Aufruf Push Provider

  • [A_27512] - Push Gateway - Direkte Kommunikation mit Push Provider

  • [A_27539] - Push Gateway - Keine Verarbeitung unverschlüsselter personenbezogener Daten

  • [A_27611] - Push Gateway - Keine Rückschlüsse auf genutzte Anwendungen

  • [A_27435] - Push Gateway – Unverzügliches Löschen von Push Notification

  • [A_27757] - Push Gateway – Maximal-Frist für Push Notifications im Push Gateway

  • [A_27167] - Push Gateway - Prio Feld mappen

3.1. Fachlicher Kontext

Das Push-Gateway agiert als Mittelsmann zwischen Fachdiensten und Push-Providern. Es abstrahiert die Schnittstellen der unterstützten Push-Provider und bietet eine einheitliche Schnittstelle für Fachdienste an, damit diese nicht jeweils separat die Schnittstellen der Push-Provider anbinden müssen.

3.2. Technischer Kontext

Das Kontextdiagramm zeigt die beteiligten Systeme. Deren Interaktion wird über die verbindenden Linien dargestellt.

kontextdiagramm
Abbildung 1. Kontextdiagramm

3.2.1. REST-Api

Das Push-Gateway implementiert die OpenAPI in der Version 1.0.0, die von der gematik gepflegt wird.

3.2.2. Push-Api

Jeder Push-Provider bietet eigene technische Möglichkeiten mit ihm zu kommunizieren. In diesem Projekt werden Client-Bibliotheken verwendet, die die technischen Details der Kommunikation umsetzen. Im Fall von Firebase ist dies die Bibliothek com.google.firebase:firebase-admin, im Fall von APNS ist dies die Bibliothek com.eatthepath:pushy. Daher ist hier die Schnittstelle der Push-Provider vereinfacht dargestellt.

4. Lösungsstrategie

4.1. Einführung

Die Basis des Systems bilden die folgenden Komponenten:

  • Formal beschriebene REST-Api als Zugangspunkt für Fachdienste, siehe [openapi]

  • Filterung formal zustellbarer Push-Notifications

  • Persistenz zur Speicherung abgelehnter Pushkeys

  • Pufferung und Retry-Mechanismen für formal zustellbare Push-Notifications

  • Verarbeitung formal zustellbarer Push-Notifications

4.2. Architekturstil

Das System ist ein Baustein innerhalb einer deutlich größeren verteilten Infrastruktur. Als Vermittler zwischen Fachdiensten und Push-Providern muss es für Fachdienste erreichbar sein und selbst Zugriff auf die Push-Provider haben, um seine Aufgaben erledigen zu können. Es handelt sich daher um ein verteiltes Client-Server-System, wobei die Fachdienste die Client-Rolle gegenüber dem System einnehmen und das System die Client-Rolle gegenüber den Push-Providern.

4.3. REST

Die Anforderungen der gematik schließen die Implementierung einer eigens definierten REST-Api ein. Andere Ansätze, wie etwa SOAP oder ähnliches scheiden daher aus. Ferner ermöglicht die zustandslose Kommunikation von REST-Systemen eine besonders gute Skalierung was insbesondere die Erfüllung von Szenario EFZV01 begünstigt.

4.4. Persistenz

Für die Filterung von unzustellbaren Push-Notifications muss es u. A. Aufzeichnungen von bereits abgelehnten Pushkeys geben. Zu diesem Zweck wird eine relationale Datenbank (postgreSQL) vom Kunden gewünscht.

Anmerkung

Da es in diesem Szenario keine Relationen gibt, ist ein relationales DB-System nicht unbedingt erste Wahl. Daher wurde der Einsatz einer NoSQL-DB (Mongo-DB) mit dem Kunden diskutiert, aber aus betrieblichen Gründen abgelehnt.

5. Technologiestack

Die folgenden Technologien kommen in diesem System zum Einsatz:

Programmiersprachen

Es wird Kotlin als Programmiersprache verwendet und gegenüber Java bevorzugt. Java ist weit verbreitet, bietet ein großartiges Ecosystem und eine ausführliche Dokumentation. Die Sprache Kotlin ist mit Java zu 100 % interoperabel und macht einige Dinge besser als Java. NullPointerExceptions sind eine häufige Fehlerquelle in Java-Programmen. Sie sind in Java sehr einfach zu produzieren. In Kotlin müssen Felder, die null sein dürfen, explizit als solche markiert werden. Das Typsystem stellt sicher, dass null nur dort auftreten kann. NullPointerExceptions sind so viel schwieriger zu produzieren als in Java. Ein weiterer Grund für Kotlin ist die Erweiterbarkeit durch sogenannte Extensions. Diese ermöglichen die Erweiterung von Funktionalität, ohne auf Vererbung angewiesen zu sein. So kann man Bibliotheken, die man nicht unter Kontrolle hat, um projektspezifisches Verhalten ergänzen. In Java ist dies nicht möglich. Ein dritter Vorteil von Kotlin ist, dass alles implizit unveränderbar ist (final, immutable), anders als in Java. Dadurch können ungewollte Seiteneffekte reduziert werden.

Backend

Im Backend kommt Spring Boot als Application Framework zum Einsatz. Mit seiner hohen Modularität und Adaptierbarkeit vereinfacht es die Anbindung anderer Technologien erheblich. Die Bereitstellung von Telemetriedaten der Anwendung wird ebenfalls sehr gut unterstützt.

Persistenz

Die Persistenzschicht wird benötigt um Gültigkeitsstatus bzgl. Pushkeys zu speichern und für Folgerequests zu verwenden. Da hier keine Relationen gegeben sind, ist eine relationales DBMS eigentlich nicht notwendig. Mit Verweis auf ADR-002 haben wir uns dennoch für PostgreSQL entschieden.

Die Konformität mit der ISO 9075 ist zu gut 96 % gegeben (siehe [postgresql-iso9075-conformance]) was einen späteren Wechsel des DMBS erschweren kann. Die Portabilität der Datenbank ist jedoch weder implizit noch explizit gefordert, sodass dieser Umstand wenig Gewicht hat.

Migration

Um Schemaänderungen nachvollziehbar und reproduzierbar zu halten, wird ein Datenbankmigrationswerkzeug verwendet. Wegen der geringeren Komplexität und keinem zu erwartenden Wechsel des DMBS wird der Einsatz von Flyway gegenüber Liquibase bevorzugt.

Pufferung

Für die Entkopplung von Requestverarbeitung und Nachrichtenversand kommt ein JMS-Broker zum Einsatz. Dies ermöglicht die gezielte Skalierung überlasteter Komponenten (REST-Api-Server, JMS-Consumer) sowie die Umsetzung von Retries, wenn fachlich erforderlich. Die Payloads landen in Queues, die von JMS-Consumern geordnet abgearbeitet werden. Die Integration mit Spring Boot ist bei Apache Artemis straight-forward, weshalb diese Broker-Implementierung verwendet wird. Der Einsatz von Google’s Äquivalent wurde diskutiert, aus Zeitgründen aber verworfen, da die JMS-Variante zum Zeitpunkt der Diskussion bereits fertiggestellt war.

Buildtool

Aufgrund von bereits vorhandenem Knowhow beim Auftragnehmer kommt Maven zum Einsatz. Gradle würde jedoch ebenfalls funktionieren.

Code-Generierung

Die gematik stellt eine OpenAPI-Spec bereit, die implementiert werden muss. Die REST-Schnittstelle wird daher aus dieser OpenAPI-Spec generiert und per Delegation implementiert.

6. Bausteinsicht

6.1. Whitebox Gesamtsystem

bausteinsicht level 1
Abbildung 2. Bausteinsicht - Ebene 1
Begründung

Der Eingang und die Validierung von eingehenden Push-Nachrichten wird von deren eigentlicher Verarbeitung entkoppelt. Damit folgt das System dem "Fire and forget-Ansatz". Zu diesem Zweck enthält das System Bausteine, die entsprechende Verantwortlichkeiten im Gesamtprozess übernehmen.

Enthaltene Bausteine
Baustein Verantwortlichkeit

REST-Api-Server

Dieses Subsystem ist der Zugangspunkt für Fachdienste, die Push-Notifications versenden wollen. Es implementiert die OpenAPI der gematik und evaluiert, ob eine Weiterleitung an einen Push-Provider sinnvoll ist oder nicht.

Message-Broker

Dieses Subsystem nimmt alle potentiell zustellbaren Push-Notification-Payloads entgegen und veröffentlicht sie in diversen JMS-Queues. Alles was hier ankommt, wird an einen Push-Provider ausgeliefert.

Message-Consumer

Dieses Subsystem hört auf die Queues des Message-Brokers und verarbeitet JMS-Nachrichten. Im Erfolgsfall wird so aus der JMS-Nachricht eine Push-Notification für eine bestimmte App auf einem bestimmten Gerät. Im Fehlerfall wird je nach Fehler zeitversetzt eine neue Übermittlung an den Push-Provider versucht, oder die Nachricht verworfen.
Wichtige Schnittstellen

Zu den wichtigen Schnittstellen gehören insbesondere die Zugangspunkte zu den Push-Providern, APNS und Firebase. Auf deren Verfügbarkeit oder Funktionalität kann sich das System nicht verlassen. Es muss deshalb geeignete Pufferungsmöglichkeiten umsetzen, um etwaigen Ausfällen der Push-Provider-Systeme robust zu begegnen.

6.1.1. REST-Api-Server

  • Zugangspunkt für Fachdienste, die Push-Notifications versenden

  • Schnittstelle wird aus OpenApi-Spec im Modul spring-boot-server generiert und als Abhängigkeit im Modul backend eingebunden

  • Verwendet eine Datenbank zur Speicherung abgelehnter Pushkeys

  • Responses haben nur bedingt Bezug zum vorangegangenen Request, insbesondere bzgl. abgelehnter Pushkeys

6.1.2. Message-Broker

  • Enthält alle Push-Notification-Payloads, die formal korrekt sind und deren Pushkey-Status gültig ist

  • Bietet jeden Push-Notification-Payload zur Verarbeitung an, solange sie nicht erfolgreich beim Push-Provider abgeliefert wurden und [A_27757] nicht verletzt wird

  • Sorgt durch Konfiguration für die Umsetzung von [A_27757]

6.1.3. Message-Consumer

  • Sorgt unter Berücksichtigung aller relevanten AFOs für die geordnete Verarbeitung aller Push-Notification-Payloads im Message-Broker, insbesondere die Konvertierung und Übermittlung an den jeweils zuständigen Push-Provider (APNS oder Firebase)

6.1.4. APNS

Die Schnittstelle wird verwendet, um Push-Notifications über APNS an iOS-Geräte zu versenden. Zu diesem Zweck kommt die Java-Bibliothek com.eatthepath:pushy zum Einsatz.

6.1.5. Firebase

Die Scnittstelle wird verwendet, um Push-Notifications über Firebase an Android-Geräte zu versenden. Zu diesem Zweck kommt die Java-Bibliothek com.google.firebase:firebase-admin zum Einsatz.

6.2. Ebene 2

bausteinsicht level 2 rest api server
Abbildung 3. Bausteinsicht - Ebene 2

6.2.1. Whitebox REST-Api-Server

Das REST-Api-Server Modul zerfällt in drei Submodule, Validation, Filtering und JMS-Producer.

Enthaltene Bausteine
Baustein Verantwortlichkeit

Validation

Dieses Subsystem validiert die empfangenen Requests auf formale Korrektheit. Diese Aufgabe übernimmt im Wesentlichen das Spring-Boot Framework.

Filtering

Dieses Subsystem ermittelt, ob eine Zustellung an einen Push-Provider sinnvoll ist. Dazu legt es insbesondere die Informationen hinsichtlich bereits zurückgewiesener Pushkeys zu Grunde. Enthält ein Request einen bereits zurückgewiesenen Pushkey, wird gar nicht erst versucht den Payload an den Push-Provider zu senden, weil dieser ohnehin abgelehnt würde. Außerdem wird mithilfe der Push-Konfiguration ermittelt, ob für den Payload ein konfigurierter Push-Client zuständig und verfügbar ist.

JMS-Producer

Dieses Subsystem erzeugt JMS-Nachrichten aus validen und relevanten Requests und sendet sie in entsprechende Queues an den Broker.

6.2.2. Whitebox JMS-Broker

Das JMS-Broker ist eine Blackbox (Apache Artemis) und enthält per Konfiguration vier Message-Queues, je zwei für APNS und Firebase (plain und enrypted). Die Payloads (plain und encrypted) und die Verarbeitung (APNS und Firebase) unterscheiden sich geringfügig, was die Aufteilung bedingt. Außerdem kann man so im Broker sehen, welches Format wie oft verwendet wird.

bausteinsicht level 2 broker
Abbildung 4. Bausteinsicht - Ebene 2
Enthaltene Bausteine
Baustein Verantwortlichkeit

APNS Plain

Diese Queue enthält alle Payloads für APNS die nicht verschlüsselt sind (plain) sind.

APNS Encrypted

Diese Queue enthält alle Payloads für APNS die verschlüsselt sind (encrypted) sind.

Firebase Plain

Diese Queue enthält alle Payloads für Firebase die nicht verschlüsselt sind (plain) sind.

Firebase Encrypted

Diese Queue enthält alle Payloads für Firebase die verschlüsselt sind (encrypted) sind.
Anmerkung

Für jede Queue sind separate Consumer vorgesehen.

7. Laufzeitsicht

Die Abbildung Laufzeitsicht zeigt die Verarbeitung von Fachdienst-Requests bis hin zur Zustellung der daraus resultierenden Push-Notification an Endgeräte.

runtimeview combined
Abbildung 5. Laufzeitsicht

7.1. Komplikationsloser Durchlauf

Die Abbildung Laufzeitsicht im Erfolgsfall zeigt die Verarbeitung von Fachdienst-Requests unter der Annahme, dass keine Fehler auftreten.

runtimeview success
Abbildung 6. Laufzeitsicht im Erfolgsfall

7.2. Durchlauf mit Retry

Die Abbildung Laufzeitsicht im Fehlerfall mit Retry zeigt die Verarbeitung von Fachdienst-Requests unter der Annahme, dass Retries notwendig sind.

runtimeview retry
Abbildung 7. Laufzeitsicht im Fehlerfall mit Retry

7.3. Durchlauf ohne Retry

Die Abbildung Laufzeitsicht im Fehlerfall ohne Retry zeigt die Verarbeitung von Fachdienst-Requests unter der Annahme, dass Retries nicht sinnvoll sind.

runtimeview no retry
Abbildung 8. Laufzeitsicht im Fehlerfall ohne Retry

8. Verteilungssichten

Die Abbilung Verteilungssicht DevOps zeigt die Verteilung der Komponenten im Kontext der DevOps-Infrastruktur.

verteilungssicht devops
Abbildung 9. Verteilungssicht DevOps

Die Abbildung Verteilungssicht Stage zeigt die Verteilung der Komponenten im Kontext einer verwendeten Stage (EU, RU, PU).

verteilungssicht stage
Abbildung 10. Verteilungssicht Stage

9. Querschnittliche Konzepte

9.1. Funktionale Fehlerbehandlung

Es werden im Wesentlichen zwei Fehlerarten unterschieden, fachliche Fehler und nicht fachliche Fehler. Da fachliche Fehler fachlich begründet sind, sind sie gleichermaßen erwartbar und somit bereits zur Compilezeit bekannt, mit allen Garantien, die der Compiler zusichert. Als solche sind sie im Grunde Teil des fachlichen Modells. Anders als Exceptions unterbrechen sie, richtig angewendet, nicht den Programmfluss und sind daher frei von daraus resultierenden Seiteneffekten. Das macht den Code leichter wart- und testbar.

Die Implementierung des Push-Gateways macht starken Gebrauch von diesem Pattern und verwendet dabei die Bibliothek arrow. Eine detaillierte Erklärung der funktionalen Fehlerbehandlung mit Either ist in diesem Artikel zu finden.

9.2. Fire and Forget

Die Entgegennahme von Push-Notification-Requests und deren eigentliche Verarbeitung sind technisch entkoppelt. Damit werden u. A. kurze Antwortzeiten für die Fachdienste erreicht. Dafür wird akzeptiert, dass eine 2xx-er-Antwort des REST-Api-Servers nicht zwingend bedeutet, dass eine Push-Notification tatsächlich auf dem Zielgerät angekommen ist. Die Zustellung hängt von Gegebenheiten ab, die sich außerhalb der Kontrolle des Push-Gateways befinden, wodurch ein Warten auf beteiligte Fremdsysteme zu langläufigen Requests führen kann, was die Erfüllung von Szenario EFZV01 gefährdet.

9.3. Konfiguration

9.3.1. Modi

Das Backend kann zum Zwecke der leichteren Skalierbarkeit in unterschiedlichen Modi betrieben werden:

Modus Erklärung

PRODUCER

In diesem Modus stellt die Anwendung die REST-Schnittstelle zur Verfügung und fungiert als Produzent von JMS-Nachrichten für den Broker.

CONSUMER

In diesem Modus agiert die Anwendung lediglich als Konsument der aufgelaufenen JMS-Nachrichten beim Broker. Sie hört auf die Queues und arbeiten eintreffende JMS-Nachrichten geordnet ab.

BOTH

In diesem Modus übernimmt die Anwendung sowohl PRODUCER- als auch CONSUMER-Aufgaben. Dieser Modus ist insbesondere zum Testen auf der lokalen Maschine gedacht und soll die Weiterentwicklung vereinfachen.

9.3.2. Push-Konfiguration

Der Anwendung liegt eine komplexe Push-Konfiguration in Dateiform zugrunde. Diese bestimmt insbesondere wie Fachdienste Ziel-Apps beschreiben müssen und welche Push-Provider bedient werden können.

10. Architekturentscheidungen

ADR-ID Titel Status Kontext Entscheidung Begründung Konsequenzen Alternativen Datum

ADR-002

Technologieauswahl Persistenz

Entschieden

Aufzeichnung abgelehnter Pushkeys

PostgreSQL

Einfache betriebsseitige Umsetzbarkeit

Relationales DB-System obwohl es keine Relationen gibt

NoSQL DB-System (MongoDB)

12/2025

ADR-001

Technologieauswahl Pufferung

Entschieden

Pufferung und Retry-Mechanismen

JMS (Artemis Broker)

Erfüllt alle Anforderungen durch Konfiguration

Erzeugt Integrationsaufwand, vermeidet Implementierungsaufwand

Google’s JMS-Äquivalent

11/2025

11. Qualitätsanforderungen

Das zu entwickelnde Push Gateway verfolgt die folgenden Ziele:

  1. Schaffung einer einheitlichen Fassade für die proprietären Schnittstellen von iOS (APNS) und Android (Firebase)

  2. Entkoppelung der Fachdienste von technischen Details und zu erwartenden Änderungen an den proprietären Schnittstellen von iOS (APNS) und Android (Firebase)

  3. Umsetzung der in Kapitel Kontext und Scope genannten AFOs

  4. Unterstützung der Maximallast von 10.000 Notifications pro Stunde

Daraus ergibt sich der folgende Qualtätsbaum nach [iso25010]:

qualitaetsbaum
Abbildung 11. Qualitätsbaum

11.1. Qualitätsszenarien

Die Erreichung der genannten [Ziele] wird durch die folgenden Qualitätsszenarien prüfbar.

11.1.1. Szenario FEKO01

Stimulus

In der Spezifikation werden eine oder mehrere Anforderungen, so genannte AFOs, spezifiziert.

Quelle

Fachabteilung/Product Owner

Artefakt

Anwendungslogik und zugehörige Schnittstellen

Umgebung

Produktionsnahes Entwicklungs- oder Testsystem während der Weiterentwicklung

Antwort

Die Änderungen werden implementiert, getestet und bereitgestellt, ohne bestehende Funktionalitäten unbeabsichtigt zu beeinflussen.

Antwortmetrik

Die Umsetzung ist fachlich korrekt und erzeugt das gewünschte Verhalten.

11.1.2. Szenario FEVO01

Stimulus

In der Spezifikation werden eine oder mehrere Anforderungen, so genannte AFOs, spezifiziert.

Quelle

Fachabteilung/Product Owner

Artefakt

Anwendungslogik und zugehörige Schnittstellen

Umgebung

Produktionsnahes Entwicklungs- oder Testsystem während der Weiterentwicklung

Antwort

Alle relevanten Änderungen werden implementiert, getestet und bereitgestellt, ohne bestehende Funktionalitäten unbeabsichtigt zu beeinflussen.

Antwortmetrik

Die Umsetzung ist vollständig und erzeugt das gewünschte Verhalten.

11.1.3. Szenario EFZV01

Stimulus

Das System empfängt innerhalb einer Stunde insgesamt 10.000 Push-Notification-Requests.

Quelle

Fachdienste

Artefakte

REST-Api-Server, Broker, JMS-Consumer

Umgebung

Produktionsbetrieb unter Normalbedingungen oder produktionsnahe Testumgebung

Antwort

Das System verarbeitet alle eingehenden Requests fachlich korrekt und vollständig, ohne die vereinbarten Service-Qualitäten zu verletzen.

Antwortmetrik

Aus dem Log und/oder den Telemetriedaten des Systems ist ersichtlich, dass 10.000 Requests pro Stunde verarbeitet werden. Das System lehnt keine Requests aufgrund von Überlast ab.

Anmerkungen

  • Da sich die eigentliche Zustellung von Notifications an Endgeräte der Kontrolle des Systems entzieht, muss an dieser Stelle darauf verzichtet werden erfolgreiche Zustellungen für die Erfüllung des Szenarios zu Grunde zu legen. Es kann lediglich die erfolgreich quittierte Ablieferung bei beteiligten Push-Providern geltend gemacht werden, sofern die Fachlichkeit dies hergibt.

  • Lasttests im Modul loadtests stellen die Erfüllung dieses Szenarios sicher.

    • Falls gegen echte Push-Provider getestet wird, sind ferner bei den beteiligten Push-Providern geeignete Rate-Limits sicherzustellen, die der hohen Anzahl von Nachrichten gerecht werden.

12. Risiken und technische Schulden

13. Glossar

Begriff Definition

Push-Gateway

Die Anwendung, die in diesem Dokument beschrieben ist

Push-Notification

Optional verschlüsselter Payload, der von Fachdiensten an das Push-Gateway gesendet wird, welches den Payload an unterstützte Push-Provider weiterleitet

Push-Provider

Als Blackbox zu betrachtendes Fremdsystem, was für die Zustellung von Push-Notifications auf Endgeräte verwendet wird, jedoch keine Garantie gibt, dass dies auch tatsächlich stattfindet

Quellenverzeichnis