Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beheben Sie Probleme mit Ihrem Connect-Widget für Kundenkommunikation

Dieses Thema richtet sich an Entwickler, die Probleme untersuchen müssen, die bei der Konfiguration eines Kommunikations-Widgets auf der Connect Customer Admin-Website auftreten können.

„Es ist ein Problem aufgetreten.“

Wenn Sie beim Laden Ihres Kommunikations-Widgets die Fehlermeldung Ein Problem ist aufgetreten sehen, öffnen Sie die Browser-Tools, um die Fehlerprotokolle einzusehen.

Folgende Probleme verursachen diesen Fehler häufig:

400 Ungültige Anfrage

Wenn in den Protokollen „400 Ungültige Anfrage“ erwähnt wird, gibt es mehrere mögliche Ursachen:

401 Nicht autorisiert

Wenn in den Protokollen „401 Nicht autorisiert“ erwähnt wird, liegt ein Problem mit der Authentifizierung über das JSON Web Token (JWT) vor. Es zeigt die obige Fehlerseite an.

Nachdem Sie das JWT eingerichtet haben, müssen Sie es in der Callback-Funktion authenticate implementieren. Das folgende Beispiel zeigt das Implementieren, wenn das Token abgerufen und verwendet werden soll:

amazon_connect('authenticate', function(callback) {
  window.fetch('/token').then(res => {
    res.json().then(data => {
      callback(data.data);
    });
  });
});   

Dies ist eine vereinfachte Version dessen, was implementiert werden muss:

amazon_connect('authenticate', function(callback) {
   callback(token);
});  

Eine Anleitung zum Implementieren von JWT finden Sie unter Schritt 3: Bestätigen und Kopieren des Kommunikations-Widget-Codes und der Sicherheitsschlüssel.

Wenn Sie den Callback bereits implementiert haben, können die folgenden Szenarien immer noch zu einer 401 führen:

404 Nicht gefunden

Ein 404-Statuscode wird normalerweise verursacht, wenn die angeforderte Ressource nicht existiert:

Stellen Sie sicher, dass Ihr Snippet genau so ist, wie es von der Connect Customer Admin-Website kopiert wurde, und dass sich keine der Identifikatoren geändert hat.

Wenn sich die Kennungen nicht geändert haben und Sie den Fehler 404 erhalten, wenden Sie sich an den AWS Support.

500 Interner Serverfehler

Dieser kann darauf zurückzuführen sein, dass Ihre servicebezogene Rolle nicht über die erforderlichen Berechtigungen verfügt, um den Chat zu starten. Das passiert, wenn Ihre Connect Customer-Instanz vor Oktober 2018 erstellt wurde, weil Sie keine serviceverknüpften Rollen eingerichtet haben.

Lösung: Fügen Sie die connect:* Richtlinie für die Rolle hinzu, die Ihrer Connect Customer-Instanz zugeordnet ist. Weitere Informationen finden Sie unter Verwenden Sie serviceverknüpfte Rollen und Rollenberechtigungen für Connect Customer.

Wenn Ihre serviceverknüpfte Rolle die richtigen Berechtigungen hat, wenden Sie sich an den AWS Support.

Kunden, die keine Agentennachrichten erhalten: Netzwerk oder Verbindung WebSocket unterbrochen

Während einer Chat-Sitzung verliert ein Kunde, der eine Chat-Anwendung verwendet, die network/WebSocket Verbindung. Die Verbindung wird schnell wieder hergestellt, aber Nachrichten, die während dieser Zeit vom Kundendienstmitarbeiter gesendet wurden, werden nicht in der Chat-Oberfläche des Kunden wiedergegeben.

Die folgende Abbildung zeigt ein Beispiel für die Chat-Benutzeroberfläche des Kunden neben dem Contact Control Panel des Kundendienstmitarbeiters. Eine vom Kundendienstmitarbeiter gesendete Nachricht wird in der Chat-Sitzung des Kunden nicht wiedergegeben. Für den Kundendienstmitarbeiter sieht es jedoch so aus, als ob der Kunde sie erhalten hätte.

Wenn die Chat-Anwendung des Kunden die network/WebSocket Verbindung verliert, muss die Chat-Benutzeroberfläche die folgenden Schritte ausführen, um zukünftige Nachrichten sowie Nachrichten abzurufen, die an sie gesendet wurden, während die Verbindung unterbrochen wurde:

Wenn der Agent eine Nachricht sendet, während die Chat-Benutzeroberfläche des Kunden getrennt ist, wird die Nachricht erfolgreich im Connect Customer-Backend gespeichert: Das CCP funktioniert wie erwartet und alle Nachrichten werden als Protokoll aufgezeichnet, aber das Gerät des Kunden kann keine Nachrichten empfangen. Wenn der Client erneut eine Verbindung zum herstellt WebSocket, gibt es eine Lücke in den Nachrichten. Zukünftige eingehende Nachrichten werden wieder von der WebSocket angezeigt. Die Lückennachrichten fehlen jedoch immer noch, es sei denn, der Code ruft die GetTranscript API explizit auf.

Lösung

Verwenden Sie den Session.onConnectionEstablished Chat-Event-Handler, um die GetTranscript API aufzurufen. Der chatSession.onConnectionEstablished Event-Handler wird ausgelöst, wenn die WebSocket Verbindung wiederhergestellt wird. ChatJS hat eine integrierte Heartbeat- und Wiederholungslogik für die Verbindung. WebSocket Da ChatJS das Transkript jedoch nicht speichert, müssen Sie der Chat-Benutzeroberfläche benutzerdefinierten Code hinzufügen, um das Transkript erneut manuell abzurufen.

Das folgende Codebeispiel zeigt, wie onConnectionEstablished implementiert wird, um GetTranscript aufzurufen.

import "amazon-connect-chatjs";

const chatSession = connect.ChatSession.create({
  chatDetails: {
    ContactId: "the ID of the contact",
    ParticipantId: "the ID of the chat participant",
    ParticipantToken: "the participant token",
  },
  type: "CUSTOMER",
  options: { region: "us-west-2" },
});

// Triggered when the websocket reconnects
chatSession.onConnectionEstablished(() => {
  chatSession.getTranscript({
    scanDirection: "BACKWARD",
    sortOrder: "ASCENDING",
    maxResults: 15,
    // nextToken?: nextToken - OPTIONAL, for pagination
  })
    .then((response) => {
      const { initialContactId, nextToken, transcript } = response.data;
      // ...
    })
    .catch(() => {})
});

function loadLatestTranscript(args) {
    // Documentation: https://github.com/amazon-connect/amazon-connect-chatjs?tab=readme-ov-file#chatsessiongettranscript
    return chatSession.getTranscript({
        scanDirection: "BACKWARD",
        sortOrder: "ASCENDING",
        maxResults: 15,
        // nextToken?: nextToken - OPTIONAL, for pagination
      })
      .then((response) => {
        const { initialContactId, nextToken, transcript } = response.data;
        
        const exampleMessageObj = transcript[0];
        const {
          DisplayName,
          ParticipantId,
          ParticipantRole, // CUSTOMER, AGENT, SUPERVISOR, SYSTEM
          Content,
          ContentType,
          Id,
          Type,
          AbsoluteTime, // sentTime = new Date(item.AbsoluteTime).getTime() / 1000
          MessageMetadata, // { Receipts: [{ RecipientParticipantId: "asdf" }] }
          Attachments,
          RelatedContactid,
        } = exampleMessageObj;

        return transcript // TODO - store the new transcript somewhere
      })
      .catch((err) => {
        console.log("CustomerUI", "ChatSession", "transcript fetch error: ", err);
      });
}      

Ein weiteres Beispiel finden Sie in dieser Open-Source-Implementierung unter. GitHub

Umgehen von CORS beim Öffnen der Links von Drittanbietern

Zur Verbesserung der Sicherheit arbeitet das Kommunikations-Widget in einer Sandbox-Umgebung. Daher können Links von Drittanbietern, die innerhalb des Widgets geteilt werden, nicht geöffnet werden.

Lösung

Es gibt zwei Möglichkeiten, CORS zu umgehen und das Öffnen der Links von Drittanbietern zuzulassen.