Auf dieser Seite werden gängige Ansätze für die Dienstarchitektur beschrieben, die zum Erstellen von Google Chat-Apps verwendet werden. Wenn Sie eine vorhandene App in Google Chat einbinden möchten, können Sie Ihre vorhandene Implementierung verwenden oder anpassen. Wenn Sie eine neue Chat-App erstellen, finden Sie auf dieser Seite ähnliche Informationen auf unterschiedliche Weise, damit Sie die Architektur auswählen können, die für Ihren Anwendungsfall am besten geeignet ist:
- Übersichtstabelle ansehen
- Zusammenfassung der einzelnen Architekturstile
- Zusammenfassung der Chat-App-Logik
- Zusammenfassung nach Konversationsmustern der Chat-App ansehen
Übersicht nach Funktionen und Möglichkeiten
In der folgenden Tabelle werden die wichtigsten Funktionen von Chat-Apps und der empfohlene () Dienstarchitekturstil hervorgehoben. In einigen Fällen ist es möglich, mit diesen Funktionen einen anderen Architekturstil zu entwickeln, der jedoch nicht so gut für den Anwendungsfall geeignet ist wie andere Stile ().
Funktionen |
Web- oder HTTP-Dienst |
Pub/Sub |
Webhooks |
Apps Script |
AppSheet |
Dialogflow |
Skript |
|---|---|---|---|---|---|---|---|
Gewünschte Zielgruppe |
|||||||
Dein Team |
|||||||
Meine Organisation |
|||||||
Die Öffentlichkeit |
|||||||
Nutzerinteraktivität |
|||||||
Natural Language Processing verwenden |
|||||||
Messaging-Muster |
|||||||
Synchrone Nachrichten senden und empfangen |
|||||||
Synchrone Nachrichten senden und empfangen sowie asynchrone Nachrichten senden |
|||||||
Nur asynchrone Nachrichten senden |
|||||||
Nachrichten aus einem externen System an einen einzelnen Chatbereich senden |
|||||||
Auf andere Dienste und Systeme zugreifen |
|||||||
Integrieren Sie andere Google-Services. |
|||||||
Kommunikation hinter einer Firewall |
|||||||
Chat-Ereignisse abfragen oder abonnieren |
|||||||
Codierungs- und Bereitstellungsstile |
|||||||
Entwicklung ohne Code |
|||||||
Entwicklung mit wenig Code |
|||||||
Entwicklung in einer Programmiersprache Ihrer Wahl |
|||||||
Vereinfachte DevOps |
|||||||
Vollständiges DevOps- und CI/CD-Management |
Dienstarchitekturstile
In diesem Abschnitt werden einige der gängigsten Architekturansätze zum Erstellen von Chat-Apps beschrieben.
Web- oder HTTP-Dienst
Ein Web- oder HTTP-Dienst ist die am häufigsten bereitgestellte Architektur, da sie Entwicklern die größte Flexibilität beim Erstellen öffentlicher Chat-Apps bietet. Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat-App wird öffentlich im Google Workspace Marketplace bereitgestellt.
- Die Chat App kann alle Messaging-Muster senden und empfangen: synchrone Nachrichten senden und empfangen, asynchrone Nachrichten senden und Nachrichten von einem externen System senden.
- Die Chat-App wird in einer beliebigen Programmiersprache entwickelt.
- Für die Chat-App ist eine vollständige DevOps- und CI/CD-Verwaltung erforderlich.
- Der Chat-App-Dienst wird in Cloud- oder On-Premise-Servern implementiert.
In diesem Design konfigurieren Sie Chat so, dass es über HTTP in einen Remote-Dienst eingebunden wird, wie im folgenden Diagramm dargestellt:
Im vorherigen Diagramm wird der Informationsfluss bei der Interaktion eines Nutzers mit einer HTTP-Chat-App so dargestellt:
- Ein Nutzer sendet eine Nachricht in einem Chat-Bereich an eine Chat-App.
- Eine HTTP-Anfrage wird an einen Webserver gesendet, der entweder ein Cloud- oder ein lokales System ist, das die Chat-App-Logik enthält.
- Optional kann die Chat-App-Logik mit externen Drittanbieterdiensten interagieren, z. B. mit einem Projektmanagementsystem oder einem Ticketing-Tool.
- Der Webserver sendet eine HTTP-Antwort zurück an den Chat-App-Dienst in Chat.
- Die Antwort wird an den Nutzer gesendet.
- Optional kann die Chat-App die Chat API aufrufen, um asynchron Nachrichten zu posten oder andere Vorgänge auszuführen.
Diese Architektur bietet Ihnen die Flexibilität, vorhandene Bibliotheken und Komponenten zu verwenden, die bereits in Ihrem System vorhanden sind, da diese Chat-Apps in verschiedenen Programmiersprachen entwickelt werden können. Es gibt verschiedene Möglichkeiten, diese Architektur zu implementieren. In Google Cloud können Sie Cloud Run und App Engine verwenden. Weitere Informationen
Pub/Sub
Wenn die Chat-App hinter einer Firewall implementiert ist, kann Chat keine HTTP-Aufrufe an sie senden. Eine Möglichkeit besteht darin, Pub/Sub zu verwenden, damit die Chat-App-Implementierung ein Thema abonnieren kann, das Nachrichten von Google Chat enthält. Pub/Sub ist ein asynchroner Messaging-Dienst, der Dienste, die Nachrichten erzeugen, von Diensten entkoppelt, die diese Nachrichten verarbeiten. Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat-App wird hinter einer Firewall entwickelt.
- Die Chat-App empfängt Ereignisse zu einem Chatbereich.
- Die Chat App wird für Ihre Organisation bereitgestellt.
- Die Chat App kann synchrone Nachrichten senden und empfangen sowie asynchrone Nachrichten senden.
- Die Chat-App wird in einer beliebigen Programmiersprache entwickelt.
- Für die Chat-App ist eine vollständige DevOps- und CI/CD-Verwaltung erforderlich.
Das folgende Diagramm zeigt die Architektur einer Chat-App, die mit Pub/Sub erstellt wurde:
Im obigen Diagramm wird der Informationsfluss eines Nutzers, der mit einer Pub/Sub-Chat-App interagiert, so dargestellt:
Ein Nutzer sendet eine Nachricht in Google Chat an eine Chat-App, entweder in einer Direktnachricht oder in einem Chat-Gruppenbereich, oder es findet ein Ereignis in einem Chat-Gruppenbereich statt, für das die Chat-App ein aktives Abo hat.
Chat sendet die Nachricht an ein Pub/Sub-Thema.
Ein Anwendungsserver, also ein Cloud- oder lokales System, das die Logik der Chat-App enthält, abonniert das Pub/Sub-Thema, um die Nachricht über die Firewall zu empfangen.
Optional kann die Chat-App die Chat API aufrufen, um asynchron Nachrichten zu posten oder andere Vorgänge auszuführen.
Pub/Sub als Endpunkt für Ihre Chat-App verwenden
Webhooks
Sie können eine Chat-App erstellen, die nur Nachrichten an einen bestimmten Chatbereich senden kann, indem Sie Aufrufe an eine Webhook-URL für Chat verwenden. Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat-App wird für Ihr Team bereitgestellt.
- Die Chat App sendet Nachrichten von einem externen System an einen einzelnen Chatbereich.
Bei dieser Architektur ist die Chat-App auf einen bestimmten Chat-Gruppenbereich beschränkt und lässt keine Nutzerinteraktion zu, wie im folgenden Diagramm dargestellt:
Im vorherigen Diagramm hat eine Chat-App den folgenden Informationsfluss:
- Die Chat-App-Logik empfängt Informationen von externen Drittanbieterdiensten wie einem Projektmanagementsystem oder einem Ticketing-Tool.
- Die Logik der Chat-App wird entweder in einem Cloud- oder einem On-Premise-System gehostet, das Nachrichten über eine Webhook-URL an einen bestimmten Chat-Bereich senden kann.
- Nutzer können Nachrichten von der Chat-App in diesem bestimmten Chat-Bereich empfangen, aber nicht mit der Chat-App interagieren.
Diese Art von Chat-App kann nicht in anderen Chat-Bereichen oder mit anderen Teams geteilt und nicht im Google Workspace Marketplace veröffentlicht werden. Eingehende Webhooks werden für Chat-Apps empfohlen, um Benachrichtigungen oder Status zu melden, oder für bestimmte Arten von Chat-App-Prototypen.
Apps Script
Sie können die Logik Ihrer Chat-App vollständig in JavaScript erstellen. Google Apps Script ist eine Low-Code-Entwicklungsplattform für Chat-Apps. Apps Script übernimmt den Autorisierungsvorgang und die OAuth 2.0-Tokens für die Nutzerauthentifizierung. Sie können Apps Script verwenden, um öffentliche Chat-Apps zu erstellen. Aufgrund der täglichen Kontingente und Limits wird dies jedoch nicht empfohlen.
Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat App wird für Ihr Team oder Ihre Organisation bereitgestellt.
- Die Chat App kann alle Messaging-Muster senden und empfangen: synchrone Nachrichten senden und empfangen, asynchrone Nachrichten senden und Nachrichten von einem externen System senden.
- Für die Chat-App ist eine vereinfachte DevOps-Verwaltung erforderlich.
Diese Architektur ist nützlich für Chat-Apps, die auch in andere Google Workspace- und Google-Dienste wie Google Tabellen, Google Präsentationen, Google Kalender, Google Drive, Google Maps und YouTube eingebunden werden, wie im folgenden Diagramm dargestellt:
Im vorherigen Diagramm wird der Informationsfluss bei der Interaktion eines Nutzers mit einer Apps Script-Chat-App so dargestellt:
- Ein Nutzer sendet eine Nachricht an eine Chat-App, entweder in einer Direktnachricht oder in einem Chat-Gruppenbereich.
- Die in Apps Script implementierte Chat-App-Logik, die sich in Google Cloud befindet, empfängt die Nachricht.
- Optional kann die Logik der Chat-App in Google Workspace-Dienste wie Google Kalender oder Google Tabellen oder in andere Google-Dienste wie Google Maps oder YouTube eingebunden werden.
- Die Chat-App-Logik sendet eine Antwort zurück an den Chat-App-Dienst in Chat.
- Die Antwort wird an den Nutzer gesendet.
AppSheet
Mit AppSheet können Sie eine Chat-App erstellen, die für Ihre Domain freigegeben ist, ohne auch nur eine Zeile Code schreiben zu müssen. Sie können den Entwicklungsprozess vereinfachen, indem Sie den automatischen Konfigurationsmodus verwenden und Vorlagen zum Erstellen gängiger Chat-App-Aktionen nutzen. Einige AppSheet-Web-App-Funktionen sind jedoch in Chat-Apps nicht verfügbar.
Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat-App wird für Sie und Ihr Team bereitgestellt.
- Die Chat App kann synchrone Nachrichten senden und empfangen sowie asynchrone Nachrichten senden.
- Für die Chat-App ist eine vereinfachte DevOps-Verwaltung erforderlich.
Das folgende Diagramm zeigt die Architektur einer Chat-App, die mit AppSheet erstellt wurde:
Im vorherigen Diagramm wird der Informationsfluss bei der Interaktion eines Nutzers mit einer AppSheet Chat-App so dargestellt:
- Ein Nutzer sendet eine Nachricht in Google Chat an eine Chat-App, entweder in einer Direktnachricht oder in einem Chat-Gruppenbereich.
- Die in AppSheet implementierte Chat-App-Logik, die sich in Google Cloud befindet, empfängt die Nachricht.
- Optional kann die Logik der Chat-App in Google Workspace-Dienste wie Apps Script oder Google Sheets eingebunden werden.
- Die Chat-App-Logik sendet eine Antwort zurück an den Chat-App-Dienst in Chat.
- Die Antwort wird an den Nutzer gesendet.
Dialogflow
Sie können eine Chat-App mit Dialogflow erstellen, einer Plattform für natürliche Sprache für automatisierte Unterhaltungen und dynamische Antworten. Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat-App kann synchrone Nachrichten senden und empfangen.
- Die Chat App nutzt Natural Language Processing, um auf Nutzer zu reagieren und mit ihnen zu interagieren.
Das folgende Diagramm zeigt die Architektur einer Chat-App, die mit Dialogflow erstellt wurde:
Im vorherigen Diagramm sieht der Informationsfluss bei der Interaktion eines Nutzers mit einer Dialogflow-Chat-App so aus:
- Ein Nutzer sendet eine Nachricht in Google Chat an eine Chat-App, entweder in einer Direktnachricht oder in einem Chat-Gruppenbereich.
- Ein virtueller Dialogflow-Agent, der sich in Google Cloud befindet, empfängt und verarbeitet die Nachricht, um eine Antwort zu generieren.
- Optional kann der Dialogflow-Agent über einen Dialogflow-Webhook mit externen Drittanbieterdiensten wie einem Projektmanagementsystem oder einem Ticketing-Tool interagieren.
- Der Dialogflow-Agent sendet eine Antwort zurück an den Chat-App-Dienst in Chat.
- Die Antwort wird im Chatbereich angezeigt.
Dialogflow Google Chat-App erstellen
Befehlszeilenanwendung oder ‑skript
Sie können eine Befehlszeilenanwendung oder ein Script erstellen, das Nachrichten an Chat sendet oder andere Vorgänge ausführt, z. B. einen Gruppenbereich erstellt oder die Mitglieder eines Gruppenbereichs verwaltet, ohne dass Nutzer die Chat-App in Chat direkt aufrufen oder darauf antworten können. Diese Architektur wird für die folgenden Anwendungsfälle empfohlen:
- Die Chat-App wird in einer beliebigen Programmiersprache entwickelt.
- Die Chat-App kann nur asynchrone Nachrichten senden.
Im folgenden Diagramm wird diese Architektur dargestellt:
Im vorherigen Diagramm fließen Informationen in der Chat App so:
- Die Chat-App ruft die Chat API auf, um eine Nachricht zu senden oder eine andere Operation auszuführen.
- Chat führt den angeforderten Vorgang aus.
- Optional gibt die Chat-App eine Bestätigung in der CLI aus.
Implementierung der Chat-App-Logik
Google Chat schränkt die Art und Weise, wie Sie die Logik der Chat-App implementieren, nicht ein. Sie können einen Parser für Befehle mit fester Syntax erstellen, fortschrittliche KI- und Sprachverarbeitungsbibliotheken oder ‑dienste verwenden, Ereignisse abonnieren und darauf reagieren oder alles andere, was für Ihre jeweiligen Ziele geeignet ist.
Nutzerinteraktionen verarbeiten
Die Chat-App kann auf verschiedene Weise mit Nutzern interagieren. Eine Nutzerinteraktion ist jede Aktion, die ein Nutzer ausführt, um eine Chat-App aufzurufen oder mit ihr zu interagieren.
Befehlsparser
Befehlsgesteuerte Chat-Apps untersuchen die Nutzlast von Nutzerinteraktionen mit Chat-Apps und extrahieren dann Befehle und Parameter aus diesen Inhalten. Ein Beispiel finden Sie unter Auf Google Chat-App-Befehle reagieren.
Ein anderer Ansatz besteht darin, die Nachricht zu tokenisieren, den Befehl zu extrahieren und dann auf ein Dictionary zu verweisen, das Befehle Handler-Funktionen für jeden Befehl zuordnet.
Dialogbasierte Benutzeroberfläche
Dialogbasierte Apps reagieren auf Nutzerinteraktionen in Chat-Apps, indem sie kartenbasierte Dialogfelder anzeigen, in denen der Nutzer mit der Chat-App interagieren kann, z. B. Formulare ausfüllen oder Aktionen anfordern.
Jedes Mal, wenn der Nutzer eine Aktion in einem Dialogfeld ausführt, wird ein neues Ereignis an die Chat-App gesendet. Diese kann darauf reagieren, indem sie das Dialogfeld aktualisiert oder eine Nachricht sendet.
Natural Language Processing
Viele Chat-App-Implementierungen verwenden Natural Language Processing (NLP), um zu ermitteln, wonach der Nutzer fragt. Es gibt viele Möglichkeiten, NLP zu implementieren. Sie können die Implementierung nach Belieben vornehmen.
Sie können NLP in Ihrer Chat-App-Implementierung mit Dialogflow ES oder Dialogflow CX verwenden. Damit lassen sich virtuelle Agents für automatisierte Unterhaltungen und dynamische Antworten erstellen.
Proaktiv Anfragen an Chat senden
Chat-Apps können auch Nachrichten oder andere Anfragen an Google Chat senden, die nicht durch direkte Nutzerinteraktionen in Google Chat ausgelöst werden. Stattdessen können diese Chat-Apps beispielsweise durch Drittanbieteranwendungen oder durch einen Befehlszeilenaufruf eines Nutzers ausgelöst werden. Nutzer können jedoch nicht direkt in Chat mit diesen Chat-Apps interagieren.
Nicht interaktive Chat-Apps verwenden die Chat API, um Nachrichten oder andere Arten von Anfragen an Chat zu senden.
Konversationsmuster
Sie sollten überlegen, wie Ihre Chat-App mit Nutzern interagieren soll. In den folgenden Abschnitten werden Konversationsmuster beschrieben, die in Ihrer Chat-App implementiert werden können.
Call-and-Response (synchron)
Bei einem synchronen Anfrage-Antwort-Muster antwortet die Chat App auf Nachrichten von Nutzern auf einer Eins-zu-eins-Basis. Eine Nachricht eines Nutzers an die Chat-App führt zu einer Antwort der Chat-App, wie im folgenden Diagramm dargestellt:
Im vorherigen Diagramm sieht der Informationsfluss bei der Interaktion eines Nutzers mit einer Chat-App so aus:
- Ein Nutzer sendet eine synchrone Nachricht an eine Chat-App, z. B. „Wann ist mein nächstes Meeting?“.
- Die Chat-App sendet eine synchrone Nachricht an den Nutzer, z. B. „Dr. Silva um 14:30 Uhr“.
Für diesen Typ von Konversationsmuster können Sie eine Chat-App-Architektur mit einem Webdienst, Pub/Sub, Apps Script, AppSheet oder Dialogflow implementieren.
Mehrere Antworten (asynchron)
Das Muster für mehrere Antworten kann synchrone und asynchrone Nachrichten enthalten. Dieses Muster zeichnet sich durch die bidirektionale Kommunikation zwischen Nutzern und der Chat-App aus, wobei die Chat-App beliebig viele zusätzliche Nachrichten generiert, wie im folgenden Diagramm dargestellt:
Im vorherigen Diagramm sieht der Informationsfluss bei der Interaktion eines Nutzers mit einer Chat-App so aus:
- Ein Nutzer sendet eine synchrone Nachricht an eine Chat-App, z. B. „Verkehr im Blick behalten“.
- Die Chat App sendet eine synchrone Nachricht an den Nutzer, um die Anfrage zu bestätigen, z. B. „Überwachung aktiviert“.
- Später sendet die Chat-App eine oder mehrere asynchrone Nachrichten an den Nutzer, indem sie die REST API aufruft, z. B. „Neuer Traffic“.
- Der Nutzer sendet eine zusätzliche synchrone Nachricht an die Chat-App, z. B. „Ignore traffic“ (Verkehr ignorieren).
- Die Chat-App sendet eine synchrone Nachricht an den Nutzer, um die Anfrage zu bestätigen, z. B. „Überwachung deaktiviert“.
Für diesen Typ von Konversationsmuster können Sie eine Chat-App-Architektur mit einem Webdienst, Pub/Sub, Apps Script oder AppSheet implementieren.
Ereignisse abfragen oder abonnieren (asynchron)
Bei einem asynchronen ereignisgesteuerten Muster empfängt die Chat-App Ereignisse, indem sie entweder die Chat API abfragt oder ein Abo für einen Chat-Gruppenbereich oder einen Nutzer über die Google Workspace Events API erstellt. Ereignisse beschreiben Änderungen an Chat-Ressourcen, z. B. wenn eine neue Nachricht gepostet wird oder ein Nutzer einem Gruppenbereich beitritt. Ereignisgesteuerte Chat-Apps untersuchen die Ereignisnutzlast, um Daten zur geänderten Chat-Ressource zu erhalten, und reagieren dann entsprechend.
Chat-Apps können viele Arten von Ereignissen empfangen, darunter Ereignisse zu Gruppenbereichen, Mitgliedschaften, Nachrichten und Reaktionen. Wenn eine Chat-App ein Ereignis durch Abfragen der Chat API oder über ein aktives Abo empfängt, kann sie optional eine beliebige Anzahl asynchroner Antworten generieren, die sie über die Chat API an Chat zurücksendet.
Mit dieser Art von Logik können Sie externe Systeme wie ein Ticketverwaltungssystem aktualisieren oder Nachrichten asynchron an einen Chat-Gruppenbereich senden, z. B. eine Willkommensnachricht, wenn ein neuer Nutzer einem Chat-Gruppenbereich beitritt.
Das folgende Diagramm zeigt ein Beispiel für ein ereignisgesteuertes Konversationsmuster:
Im vorherigen Diagramm erfolgt die Interaktion zwischen Chat und der Chat-App so:
- Die Chat-App abonniert einen Google Chat-Bereich.
- Der Gruppenbereich, in dem die Chat-App abonniert ist, ändert sich.
- Die Chat App sendet ein Ereignis an ein Thema in Pub/Sub, das als Benachrichtigungsendpunkt für das Abo dient. Das Ereignis enthält Daten dazu, was sich in der Ressource geändert hat.
- Die Chat-App verarbeitet die Pub/Sub-Nachricht, die das Ereignis enthält, und ergreift bei Bedarf Maßnahmen.
Für diesen Typ von Konversationsmuster können Sie eine Chat-App-Architektur mit Pub/Sub, einem Webdienst oder Apps Script implementieren.
Weitere Informationen zum Empfangen und Beantworten von Ereignissen finden Sie unter Mit Ereignissen aus Google Chat-Ereignissen arbeiten.
Einseitige Nachricht von einer Chat-App
Mit dem Muster für unidirektionale Nachrichten von Chat-Apps kann eine Chat-App asynchrone Nachrichten an einen Chat-Gruppenbereich senden, ohne dass Nutzer direkt mit der Chat-App interagieren können. Dieses Muster ist nicht dialogorientiert oder interaktiv, kann aber für Dinge wie die Meldung von Alarmen nützlich sein, wie im folgenden Diagramm dargestellt:
Im vorherigen Diagramm sieht der Informationsfluss für einen Nutzer im selben Bereich wie die Chat-App so aus:
- Die Chat-App sendet eine asynchrone Nachricht an den Nutzer, indem sie die Chat API aufruft oder an eine Webhook-URL postet, z. B. „Warteschlangenüberlauf“.
- Optional sendet die Chat App zusätzliche asynchrone Nachrichten.
Für diesen Typ von Konversationsmuster können Sie eine Chat-App-Architektur mit einem Webdienst, einem Webhook, Apps Script, AppSheet, einer Befehlszeilenanwendung oder einem Skript implementieren.
Einseitige Nachricht an eine Google Chat-App
Bei einem Einwegnachrichtenmuster für eine Chat-App kann ein Nutzer eine Nachricht an eine Chat-App senden, ohne dass die Chat-App antwortet, während die Anfrage trotzdem verarbeitet wird. Diese Architektur ist zwar technisch möglich, führt aber zu einer schlechten Nutzererfahrung. Wir raten dringend davon ab.