Dieses Dokument bietet einen Überblick über Pull-Abos, den zugehörigen Workflow und die zugehörigen Eigenschaften.
Bei einem Pull-Abo fordert ein Abonnentenclient Nachrichten vom Pub/Sub-Server an.
Im Pull-Modus kann eine der beiden Dienst-APIs verwendet werden: Pull oder StreamingPull. Um die ausgewählte API auszuführen, können Sie eine von Google bereitgestellte Clientbibliothek auf hoher Ebene oder eine automatisch generierte Clientbibliothek auf niedriger Ebene auswählen. Sie können auch zwischen asynchroner und synchroner Nachrichtenverarbeitung wählen.
Hinweise
Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:
Funktionsweise von Pub/Sub und die verschiedenen Pub/Sub-Begriffe.
Die verschiedenen Arten von Abos, die von Pub/Sub unterstützt werden, und die Gründe für die Verwendung eines Pull-Abos.
Workflow bei Pull-Abos
Bei einem Pull-Abo initiiert Ihr Abonnentenclient Anfragen an einen Pub/Sub-Server, um Nachrichten abzurufen. Der Abonnentenclient verwendet eine der folgenden APIs:
Die meisten Abonnenten-Clients senden diese Anfragen nicht direkt. Stattdessen verwenden die Clients die von Trusted Cloud by S3NSbereitgestellte Clientbibliothek auf hoher Ebene, die intern Streaming-Pull-Anfragen ausführt und Nachrichten asynchron zustellt. Für einen Abonnentenclient, der mehr Kontrolle darüber benötigt, wie Nachrichten abgerufen werden, verwendet Pub/Sub eine automatisch generierte gRPC-Bibliothek auf niedriger Ebene. Mit dieser Bibliothek werden Pull- oder Streaming-Pull-Anfragen direkt gestellt. Diese Anfragen können synchron oder asynchron sein.
Die folgenden beiden Bilder zeigen den Workflow zwischen einem Abonnentenclient und einem Pull-Abo.


Pull-Workflow
Der Pull-Workflow sieht so aus (siehe Abbildung 1):
- Der Abonnentenclient ruft explizit die Methode
pull
auf, die Nachrichten zur Zustellung anfordert. Diese Anfrage ist diePullRequest
, wie im Bild zu sehen ist. Der Pub/Sub-Server antwortet mit null oder mehr Nachrichten und Bestätigungs-IDs. Eine Antwort mit null Nachrichten oder mit einem Fehler bedeutet nicht unbedingt, dass keine Nachrichten zum Empfangen verfügbar sind. Diese Antwort ist der
PullResponse
, wie im Bild dargestellt.Der Abonnentenclient ruft explizit die Methode
acknowledge
auf. Der Client verwendet die zurückgegebene Bestätigungs-ID, um zu bestätigen, dass die Nachricht verarbeitet wurde und nicht noch einmal zugestellt werden muss.
Bei einer einzelnen Streaming-Pull-Anfrage kann ein Abonnentenclient aufgrund der offenen Verbindung mehrere Antworten erhalten. Im Gegensatz dazu wird für jeden Pull-Request nur eine Antwort zurückgegeben.
Attribute eines Pull-Abos
Die Attribute, die Sie für ein Pull-Abo konfigurieren, bestimmen, wie Sie Nachrichten in Ihr Abo schreiben. Weitere Informationen finden Sie unter Abo-Attribute.
Pub/Sub-Dienst-APIs
Für das Pub/Sub-Pull-Abo kann eine der folgenden beiden APIs zum Abrufen von Nachrichten verwendet werden:
- Pull
- StreamingPull
Verwenden Sie die unären RPCs „Acknowledge“ und „ModifyAckDeadline“, wenn Sie Nachrichten über diese APIs empfangen. Die beiden Pub/Sub-APIs werden in den folgenden Abschnitten beschrieben.
StreamingPull API
Wo möglich, verwenden die Pub/Sub-Clientbibliotheken StreamingPull für maximalen Durchsatz und niedrigste Latenz. Auch wenn Sie die StreamingPull API vielleicht niemals direkt verwenden, ist es dennoch hilfreich, wenn Sie den Unterschied zur Pull API kennen.
Die StreamingPull API benötigt eine bidirektionale Verbindung, um mehrere Nachrichten zu empfangen, sobald diese verfügbar werden. So funktioniert der Workflow:
Der Client sendet eine Anfrage an den Server, um eine Verbindung herzustellen. Wenn das Verbindungskontingent überschritten wird, gibt der Server einen Fehler vom Typ „resource exhausted“ zurück. Die Clientbibliothek wiederholt Fehler aufgrund von Überschreitungen des Kontingents automatisch.
Wenn kein Fehler auftritt oder das Verbindungskontingent wieder verfügbar ist, sendet der Server kontinuierlich Nachrichten an den verbundenen Client.
Wenn das Durchsatzkontingent überschritten wird, stoppt der Server das Senden von Nachrichten. Die Verbindung ist jedoch nicht unterbrochen. Sobald wieder ein ausreichendes Durchsatzkontingent verfügbar ist, wird der Stream fortgesetzt.
Die Verbindung wird schließlich entweder vom Client oder vom Server beendet.
Die StreamingPull API hält eine offene Verbindung aufrecht. Die Pub/Sub-Server schließen die Verbindung nach einem bestimmten Zeitraum regelmäßig, um eine lang andauernde, statische Verbindung zu vermeiden. Die Clientbibliothek stellt die StreamingPull-Verbindung automatisch wieder her.
Nachrichten werden an die Verbindung gesendet, sobald sie verfügbar sind. Die StreamingPull API minimiert also die Latenz und maximiert den Durchsatz für Nachrichten.
Weitere Informationen zu den StreamingPull-RPC-Methoden StreamingPullRequest und StreamingPullResponse
Pull API
Diese API ist ein traditioneller unärer RPC, der auf einem Anfrage- und Antwortmodell basiert. Eine einzelne Pull-Antwort entspricht einer einzelnen Pull-Anfrage. Der Workflow sieht so aus:
Der Client sendet eine Anfrage an den Server. Wenn das Durchsatzkontingent überschritten wird, gibt der Server einen Fehler vom Typ „resource exhausted“ zurück.
Wenn kein Fehler vorliegt oder das Kontingent wieder verfügbar ist, antwortet der Server mit null oder mehr Nachrichten und Bestätigungs-IDs.
Wenn Sie die unäre Pull API verwenden, bedeutet eine Antwort mit null Nachrichten oder mit einem Fehler nicht unbedingt, dass keine Nachrichten zum Empfangen verfügbar sind.
Die Verwendung der Pull API garantiert keine niedrige Latenz und keinen hohen Durchsatz von Nachrichten. Um mit der Pull API einen hohen Durchsatz und eine niedrige Latenz zu erzielen, müssen mehrere gleichzeitige ausstehende Anfragen vorhanden sein. Neue Anfragen werden erstellt, wenn auf alte Anfragen geantwortet wird. Das Entwerfen einer solchen Lösung ist fehleranfällig und schwer zu warten. Für solche Anwendungsfälle empfehlen wir die StreamingPull API.
Verwenden Sie die Pull API anstelle der StreamingPull API nur, wenn Sie die folgenden Aspekte genau steuern müssen:
- Die Anzahl der Nachrichten, die der Abonnentenclient verarbeiten kann
- Arbeitsspeicher und Ressourcen des Clients
Sie können diese API auch verwenden, wenn Ihr Abonnent ein Proxy zwischen Pub/Sub und einem anderen Dienst ist, der eher pull-orientiert arbeitet.
Weitere Informationen zu den Pull-REST-Methoden finden Sie unter Methode: projects.subscriptions.pull.
Weitere Informationen zu den Pull-RPC-Methoden PullRequest und PullResponse
Arten von Nachrichtenverarbeitungsmodi
Wählen Sie einen der folgenden Pull-Modi für Ihre Abonnentenclients aus.
Asynchroner Pull-Modus
Im asynchronen Pull-Modus wird der Empfang von Nachrichten von der Verarbeitung von Nachrichten in einem Abonnentenclient entkoppelt. Dieser Modus ist die Standardeinstellung für die meisten Abonnentenclients. Im asynchronen Pull-Modus kann die StreamingPull API oder die unäre Pull API verwendet werden. Für das asynchrone Abrufen kann auch die Clientbibliothek auf hoher Ebene oder die automatisch generierte Clientbibliothek auf niedriger Ebene verwendet werden.
Weitere Informationen zu Clientbibliotheken finden Sie weiter unten in diesem Dokument.
Synchrone Pull-Zustellung
Im synchronen Pull-Modus erfolgen der Empfang und die Verarbeitung von Nachrichten sequenziell und sind nicht voneinander entkoppelt. Ähnlich wie bei StreamingPull im Vergleich zu unären Pull-APIs bietet die asynchrone Verarbeitung eine geringere Latenz und einen höheren Durchsatz als die synchrone Verarbeitung.
Verwenden Sie den synchronen Pull-Modus nur für Anwendungen, bei denen niedrige Latenz und hoher Durchsatz im Vergleich zu anderen Anforderungen nicht die wichtigsten Faktoren sind. Eine Anwendung ist beispielsweise möglicherweise auf die Verwendung des synchronen Programmiermodells beschränkt. Oder eine Anwendung mit Ressourcenbeschränkungen erfordert möglicherweise eine genauere Kontrolle über Arbeitsspeicher, Netzwerk oder CPU. Verwenden Sie in solchen Fällen den synchronen Modus mit der unären Pull API.
Pub/Sub-Clientbibliotheken
Pub/Sub bietet eine automatisch generierte Clientbibliothek auf hoher und niedriger Ebene.
Pub/Sub-Clientbibliothek auf hoher Ebene
Die allgemeine Clientbibliothek bietet Optionen zum Steuern der Quittierungsfristen mithilfe der Freigabeverwaltung. Diese Optionen sind detaillierter als bei der Konfiguration der Bestätigungsfristen auf Aboebene über die Console oder die CLI. Die Clientbibliothek auf hoher Ebene bietet auch Unterstützung für Funktionen wie die geordnete Zustellung, die genau einmalige Zustellung und die Ablaufsteuerung.
Wir empfehlen, asynchronen Pull und die StreamingPull API mit der Clientbibliothek auf hoher Ebene zu verwenden. Nicht alle Sprachen, die fürTrusted Cloud by S3NS unterstützt werden, unterstützen auch die Pull API in der Clientbibliothek auf hoher Ebene.
Informationen zur Verwendung der Clientbibliotheken auf hoher Ebene finden Sie unter Pub/Sub-Clientbibliotheken.
Automatisch generierte Pub/Sub-Clientbibliothek auf niedriger Ebene
Für Fälle, in denen Sie die Pull API direkt verwenden müssen, ist eine Clientbibliothek auf niedriger Ebene verfügbar. Sie können die automatisch generierte Clientbibliothek auf niedriger Ebene für die synchrone oder asynchrone Verarbeitung verwenden. Wenn Sie die automatisch generierte Clientbibliothek auf niedriger Ebene verwenden, müssen Sie Funktionen wie die geordnete Zustellung, die Exactly-Once-Zustellung, die Flusssteuerung und die Lease-Verwaltung manuell codieren.
Sie können das synchrone Verarbeitungsmodell verwenden, wenn Sie die automatisch generierte Clientbibliothek auf niedriger Ebene für alle unterstützten Sprachen verwenden. Sie können die automatisch generierte Clientbibliothek auf niedriger Ebene und den synchronen Pull verwenden, wenn die direkte Verwendung der Pull API sinnvoll ist. Möglicherweise haben Sie beispielsweise vorhandene Anwendungslogik, die auf diesem Modell basiert.
Wenn Sie die automatisch generierten Clientbibliotheken auf niedriger Ebene direkt verwenden möchten, lesen Sie die Übersicht über die Pub/Sub APIs.
Codebeispiele für Clientbibliotheken
StreamingPull- und High-Level-Clientbibliotheks-Codebeispiele
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub C# API.
Go
Im folgenden Beispiel wird die Hauptversion der Go Pub/Sub-Clientbibliothek (v2) verwendet. Wenn Sie noch die v1-Bibliothek verwenden, finden Sie hier den Migrationsleitfaden für v2. Eine Liste der Codebeispiele für Version 1 finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Node.js API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Python API.
Ruby
Im folgenden Beispiel wird die Ruby-Pub/Sub-Clientbibliothek v3 verwendet. Wenn Sie noch die v2-Bibliothek verwenden, finden Sie hier die Migrationsanleitung für v3. Eine Liste der Ruby v2-Codebeispiele finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel ausprobieren, folgen Sie der Einrichtungsanleitung für Ruby im Schnellstart: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Ruby API.
Benutzerdefinierte Attribute mit der High-Level-Clientbibliothek abrufen
In den folgenden Beispielen wird gezeigt, wie Nachrichten asynchron abgerufen und die benutzerdefinierten Attribute aus den Metadaten abgerufen werden.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub C# API.
Go
Im folgenden Beispiel wird die Hauptversion der Go Pub/Sub-Clientbibliothek (v2) verwendet. Wenn Sie noch die v1-Bibliothek verwenden, finden Sie hier den Migrationsleitfaden für v2. Eine Liste der Codebeispiele für Version 1 finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Python API.
Ruby
Im folgenden Beispiel wird die Ruby-Pub/Sub-Clientbibliothek v3 verwendet. Wenn Sie noch die v2-Bibliothek verwenden, finden Sie hier die Migrationsanleitung für v3. Eine Liste der Ruby v2-Codebeispiele finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel ausprobieren, folgen Sie der Einrichtungsanleitung für Ruby im Schnellstart: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Ruby API.
Fehler mit der Clientbibliothek auf hoher Ebene behandeln
In den folgenden Beispielen wird dargestellt, wie Fehler behandelt werden, die beim Abonnieren von Nachrichten auftreten können.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
Go
Im folgenden Beispiel wird die Hauptversion der Go Pub/Sub-Clientbibliothek (v2) verwendet. Wenn Sie noch die v1-Bibliothek verwenden, finden Sie hier den Migrationsleitfaden für v2. Eine Liste der Codebeispiele für Version 1 finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Python API.
Ruby
Im folgenden Beispiel wird die Hauptversion der Go Pub/Sub-Clientbibliothek (v2) verwendet. Wenn Sie noch die v1-Bibliothek verwenden, finden Sie hier den Migrationsleitfaden für v2. Eine Liste der Codebeispiele für Version 1 finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Go API.
Codebeispiele für Unary Pull
Hier sehen Sie Beispielcode für die Pull-Zustellung und die Bestätigung einer festen Anzahl von Nachrichten.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub C# API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Node.js API.
PHP
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Node.js API.
Ruby
Im folgenden Beispiel wird die Ruby-Pub/Sub-Clientbibliothek v3 verwendet. Wenn Sie noch die v2-Bibliothek verwenden, finden Sie hier die Migrationsanleitung für v3. Eine Liste der Ruby v2-Codebeispiele finden Sie unter Eingestellte Codebeispiele.
Bevor Sie dieses Beispiel ausprobieren, folgen Sie der Einrichtungsanleitung für Ruby im Schnellstart: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Ruby API.
Protokoll
Anfrage:
POST https://pubsub.googleapis.com/v1/projects/myproject/subscriptions/mysubscription:pull
{
"returnImmediately": "false",
"maxMessages": "1"
}
Antwort:
200 OK
{
"receivedMessages": [{
"ackId": "dQNNHlAbEGEIBERNK0EPKVgUWQYyODM2LwgRHFEZDDsLRk1SK...",
"message": {
"data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
"messageId": "19917247034"
}
}]
}
Anfrage:
POST https://pubsub.googleapis.com/v1/projects/myproject/subscriptions/mysubscription:acknowledge
{
"ackIds": [
"dQNNHlAbEGEIBERNK0EPKVgUWQYyODM2LwgRHFEZDDsLRk1SK..."
]
}
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Python API.
Pub/Sub stellt eine Liste von Nachrichten bereit. Wenn die Liste mehrere Nachrichten enthält, sortiert Pub/Sub die Nachrichten mit demselben Reihenfolgeschlüssel. Hier sind einige wichtige Einschränkungen:
Wenn Sie in der Anfrage einen Wert für
max_messages
festlegen, bedeutet das nicht, dassmax_messages
zurückgegeben werden, auch wenn so viele Nachrichten im Backlog vorhanden sind. Die Pub/Sub Pull API gibt möglicherweise weniger alsmax_messages
zurück, um die Zustelllatenz für Nachrichten zu reduzieren, die sofort zugestellt werden können.Eine Pull-Antwort mit 0 Nachrichten darf nicht als Indikator dafür verwendet werden, dass sich keine Nachrichten im Backlog befinden. Es ist möglich, dass Sie eine Antwort mit 0 Nachrichten erhalten und eine nachfolgende Anfrage Nachrichten zurückgibt.
Voraussetzung für die Effektivität der unären Pull-Zustellung ist, dass eine hohe Zahl gleichzeitig ausstehender Pull-Anfragen vorliegt. Je höher der Durchsatz des Themas wird, desto mehr Pull-Anfragen werden benötigt. Im Allgemeinen ist der StreamingPull-Modus für latenzempfindliche Anwendungen zu bevorzugen.
Kontingente und Limits
Sowohl Pull- als auch StreamingPull-Verbindungen unterliegen Kontingenten und Limits. Weitere Informationen finden Sie unter Pub/Sub-Kontingente und ‑Limits.
Nächste Schritte
Erstellen Sie ein Pull-Abo für Ihr Thema.
Fehlerbehebung bei einem Pull-Abo
Erstellen oder ändern Sie ein Abo mit der gcloud CLI.
Abonnements mit REST APIs erstellen oder ändern
Abo mit RPC-APIs erstellen oder ändern