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.
# Fehlerbehebung beim Kommunikations-Widget von Amazon Connect
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.
**Topics**
+ [„Es ist ein Problem aufgetreten.“](#sww)
+ [Kunden, die keine Agentennachrichten erhalten: Netzwerk oder Verbindung unterbrochen WebSocket](#mam)
+ [Umgehen von CORS beim Öffnen der Links von Drittanbietern](#bcwotpl)
## „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:
+ Ihr Kommunikations-Widget wird nicht auf einer zugelassenen Domain bereitgestellt. Sie müssen die Domains, in denen Sie Ihr Widget hosten werden, ausdrücklich angeben.
+ Die Anfrage an den Endpunkt ist nicht richtig formatiert. Dies tritt normalerweise nur auf, wenn der Inhalt des eingebetteten Codeblocks geändert wurde.
### 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](add-chat-to-website.md#confirm-and-copy-chat-widget-script).
Wenn Sie den Callback bereits implementiert haben, kann in den folgenden Situationen immer noch der Fehler 401 auftreten:
+ Ungültige Signatur
+ Abgelaufenes Token
### 404 Nicht gefunden
Ein 404-Statuscode wird normalerweise verursacht, wenn die angeforderte Ressource nicht existiert:
+ In der API-Anforderung ist eine ungültige widgetId angegeben.
+ Die widgetId ist gültig, aber der zugehörige Ablauf wurde gelöscht oder archiviert.
+ Das Widget wurde nicht veröffentlicht oder es wurde gelöscht.
Stellen Sie sicher, dass Ihr Snippet genau so ist, wie es von der Connect Customer Admin-Website kopiert wurde, und dass sich keine der Kennungen 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. Dies ist der Fall, wenn die Amazon-Connect-Instance vor Oktober 2018 erstellt wurde, weil Sie dann keine serviceverknüpften Rollen eingerichtet haben.
**Lösung**: Fügen Sie die Richtlinie `connect:*` für die Rolle hinzu, die Ihrer Amazon-Connect-Instance zugeordnet ist. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen und Rollenberechtigungen für Amazon Connect](connect-slr.md).
Wenn Ihre serviceverknüpfte Rolle die richtigen Berechtigungen hat, wenden Sie sich an den AWS Support.
## Kunden, die keine Agentennachrichten erhalten: Netzwerk oder Verbindung unterbrochen WebSocket
Während einer Chat-Sitzung verliert ein Kunde, der eine Chat-Anwendung verwendet, seine 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-Oberfläche des Kunden und das Kontakt-Control-Panel des Agenten side-by-side. 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 ihre network/WebSocket Verbindung verliert, muss die Chat-Benutzeroberfläche wie folgt vorgehen, um future Nachrichten sowie Nachrichten, die an sie gesendet wurden, während die Verbindung unterbrochen wurde, abzurufen:
+ Stellen Sie die WebSocket Verbindung wieder her, um future eingehende Nachrichten erneut zu empfangen.
+ Stellen Sie eine [chatSession.getTranscript](https://github.com/amazon-connect/amazon-connect-chatjs?tab=readme-ov-file#chatsessiongettranscript)-Anforderung ([getTranscripts](https://docs.aws.amazon.com/connect-participant/latest/APIReference/API_GetTranscript.html)-API), um alle fehlenden Nachrichten abzurufen, die gesendet wurden, während die Verbindung zum Kunden unterbrochen war.
Wenn der Kundendienstmitarbeiter eine Nachricht sendet, während die Chat-Benutzeroberfläche des Kunden unterbrochen ist, wird die Nachricht erfolgreich im Amazon-Connect-Backend gespeichert: Das CCP funktioniert wie erwartet und alle Nachrichten werden im Protokoll aufgezeichnet, aber das Gerät des Kunden kann keine Nachrichten empfangen. Wenn der Client erneut eine Verbindung zum herstellt WebSocket, besteht eine Nachrichtenlücke. Künftige eingehende Nachrichten werden wieder von der angezeigt WebSocket, aber die Lückenmeldungen fehlen immer noch, es sei denn, der Code ruft die [GetTranscript](https://docs.aws.amazon.com/connect-participant/latest/APIReference/API_GetTranscript.html)API explizit auf.
### Lösung
Verwenden Sie die [ChatSession. onConnectionEstablished](https://github.com/amazon-connect/amazon-connect-chatjs?tab=readme-ov-file#chatsessiononconnectionestablished)Event-Handler zum Aufrufen der [GetTranscript](https://docs.aws.amazon.com/connect-participant/latest/APIReference/API_GetTranscript.html)API. Der `chatSession.onConnectionEstablished` Event-Handler wird ausgelöst, wenn die WebSocket Verbindung wieder hergestellt wird. ChatJS verfügt über 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 unter dieser [Open-Source-Implementierung](https://github.com/amazon-connect/amazon-connect-chat-interface/blob/c88f854073fe6dd45546585c3bfa363d3659d73f/src/components/Chat/ChatSession.js#L408). 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.
+ **(Empfohlen)**
Aktualisieren Sie das Sandbox-Attribut, um das Öffnen von Links in einer neuen Registerkarte zu ermöglichen. Fügen Sie dazu dem Codeausschnitt das folgende Attribut hinzu:
```
amazon_connect('updateSandboxAttributes', 'allow-scripts allow-same-origin allow-popups allow-downloads allow-top-navigation-by-user-activation allow-popups-to-escape-sandbox')
```
**Anmerkung**
Der Attributwert kann nach Bedarf aktualisiert werden, um bestimmte Aktionen zuzulassen. Dies ist ein Beispiel dafür, wie das Öffnen von Links in einer neuen Registerkarte ermöglicht wird.
+ Entfernen Sie das Sandbox-Attribut, indem Sie dem Codeausschnitt das folgende Attribut hinzufügen:
```
amazon_connect('removeSandboxAttribute', true)
```