Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risolvi i problemi relativi al widget di comunicazione Connect Customer

Questo argomento è rivolto agli sviluppatori che devono esaminare i problemi che potrebbero verificarsi durante la configurazione di un widget di comunicazione nel sito Web di Connect Customer amministrazione.

“Qualcosa non ha funzionato”

Se visualizzi il seguente messaggio di errore Qualcosa non ha funzionato durante il caricamento del widget di comunicazione, apri gli strumenti del browser per visualizzare i log degli errori.

Di seguito sono riportati i problemi comuni che causano questo errore.

400 - Richiesta non valida

Se i log menzionano un codice di stato "400 - Richiesta non valida", esistono alcune possibili cause:

401 - Autorizzazione negata

Se i log menzionano un codice di stato "401 - Autorizzazione negata", si tratta di un problema relativo all'autenticazione del token web JSON (JWT). Visualizza la pagina di errore riportata sopra.

Dopo aver installato il JWT, è necessario implementarlo nella funzione di callback authenticate. L'esempio seguente mostra come implementarlo se stai cercando di recuperare il tuo token e poi usarlo:

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

Ecco una versione più semplice di ciò che deve essere implementato:

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

Per istruzioni sull'implementazione del JWT, consulta Passaggio 3: confermare e copiare il codice del widget di comunicazione e le chiavi di sicurezza.

Se hai già implementato il callback, i seguenti scenari potrebbero comunque causare un 401:

404 - Non trovato

Solitamente viene generato un codice di stato 404 quando la risorsa richiesta non esiste:

Verifica che lo snippet sia esattamente come è stato copiato dal sito web di Connect Customer amministrazione e che nessuno degli identificatori sia cambiato.

Se gli identificatori non sono cambiati e visualizzi un codice di stato 404, contatta AWS .

500 - Errore interno del server

Ciò può essere causato dal fatto che il ruolo collegato al servizio non dispone delle autorizzazioni necessarie per avviare la chat. Ciò accade se la tua istanza Connect Customer è stata creata prima di ottobre 2018 perché non hai impostato ruoli collegati ai servizi.

Soluzione: aggiungi la connect:* policy sul ruolo associato alla tua istanza Connect Customer. Per ulteriori informazioni, consulta Utilizza i ruoli e le autorizzazioni dei ruoli collegati ai servizi per Connect Customer.

Se il ruolo collegato al servizio dispone delle autorizzazioni corrette, contatta AWS .

Clienti che non ricevono messaggi dagli agenti: collegati in rete o WebSocket disconnessi

Durante una sessione di chat, un cliente che utilizza un'applicazione di chat perde la network/WebSocket connessione. La connessione viene ripristinata rapidamente, ma i messaggi inviati dall’agente in quel lasso di tempo non vengono visualizzati nell’interfaccia di chat del cliente.

L’immagine seguente mostra un esempio di interfaccia di chat del cliente e Contact Control Panel dell’agente affiancati. Un messaggio inviato dall’agente non viene visualizzato nella sessione di chat del cliente. Tuttavia, all’agente sembra che il cliente lo abbia ricevuto.

Se l'applicazione di chat del cliente perde la network/WebSocket connessione, l'interfaccia utente di chat deve eseguire le seguenti operazioni per recuperare i messaggi futuri e quelli che le sono stati inviati mentre era disconnesso:

Se l'agente invia un messaggio mentre l'interfaccia utente di chat del cliente è disconnessa, il messaggio viene archiviato correttamente nel backend Connect Customer: il CCP funziona come previsto e i messaggi vengono tutti registrati in trascrizione, ma il dispositivo del cliente non è in grado di ricevere messaggi. Quando il client si riconnette al WebSocket, c'è una lacuna nei messaggi. I futuri messaggi in arrivo verranno nuovamente visualizzati da. WebSocket Tuttavia, i messaggi gap sono ancora mancanti a meno che il codice non effettui una chiamata esplicita all'GetTranscriptAPI.

Soluzione

Usa il gestore di Session.onConnectionEstablished eventi di chat per chiamare l'GetTranscriptAPI. Il gestore di chatSession.onConnectionEstablished eventi viene attivato quando ci si riconnette. WebSocket ChatJS ha una logica integrata di heartbeat e retry per la connessione. WebSocket Tuttavia, poiché ChatJS non memorizza la trascrizione, devi aggiungere codice personalizzato all’interfaccia utente di chat per recuperare di nuovo manualmente la trascrizione.

Il seguente esempio di codice mostra come implementare onConnectionEstablished per chiamare GetTranscript.

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);
      });
}      

Per un altro esempio, guarda questa implementazione open source su. GitHub

Bypassare CORS all’apertura di link di terze parti

Per migliorare la sicurezza, il widget di comunicazione funziona all’interno di un ambiente sandbox. Di conseguenza, i link di terze parti condivisi nel widget non possono essere aperti.

Soluzione

Esistono due opzioni per bypassare CORS e consentire l’apertura dei link di terze parti.