Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solucione problemas con su widget de comunicación con los clientes de Connect

Este tema está dirigido a los desarrolladores que necesitan investigar los problemas que pueden surgir al configurar un widget de comunicaciones en el sitio web de Connect Customer administración.

Algo ha salido mal.

Si ve el mensaje Se ha producido un error al cargar el widget de comunicaciones, abra las herramientas del navegador para ver los registros de errores.

A continuación, se indican los problemas comunes que pueden provocar este error.

400 solicitud no válida

Si en los registros se menciona 400 solicitud no válida, hay algunas causas posibles:

401 sin autorización

Si en los registros se menciona 401 sin autorización, se trata de un problema con la autenticación del token web JSON (JWT). Muestra la página de error anterior.

Una vez que tenga el JWT, deberá implementarlo en la función de devolución de llamada authenticate. En el siguiente ejemplo se muestra cómo implementarlo si lo que pretende es obtener su token y, después, utilizarlo:

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

A continuación, presentamos una versión más básica de lo que hay que implementar:

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

Para obtener instrucciones sobre cómo implementar JWT, consulte Paso 3: confirmar y copiar el código del widget de comunicaciones y las claves de seguridad.

Si ya has implementado la devolución de llamada, los siguientes escenarios aún podrían provocar un 401:

404 no encontrado

Por lo general, el código de estado 404 aparece cuando el recurso solicitado no existe:

Comprueba que el fragmento es exactamente como se copió del sitio web del Connect Customer administrador y que ninguno de los identificadores ha cambiado.

Si los identificadores no han cambiado y ve un 404, contacte con AWS Support.

500 error de servidor interno

Esto puede deberse a que su rol vinculado al servicio no tiene los permisos necesarios para iniciar el chat. Esto ocurre si tu instancia de Connect Customer se creó antes de octubre de 2018 porque no tienes configuradas funciones vinculadas a servicios.

Solución: agrega la connect:* política sobre el rol asociado a tu instancia de Connect Customer. Para obtener más información, consulte Usa roles vinculados a servicios y permisos de rol para Connect Customer.

Si su rol vinculado al servicio tiene los permisos correctos, contacte con AWS Support.

Clientes que no reciben mensajes de agentes: conectados o WebSocket desconectados

Durante una sesión de chat, un cliente que usa una aplicación de chat pierde la network/WebSocket conexión. Recupera la conexión rápidamente, pero los mensajes enviados por el agente durante ese tiempo no se muestran en la interfaz de chat del cliente.

En la siguiente imagen, se muestra un ejemplo de la interfaz de chat del cliente y del panel de control de contacto del agente, uno al lado del otro. Un mensaje enviado por el agente no se muestra en la sesión de chat del cliente. Sin embargo, al agente le aparece como que el cliente lo ha recibido.

Si la aplicación de chat del cliente pierde la network/WebSocket conexión, la interfaz de usuario del chat debe hacer lo siguiente para recuperar los mensajes futuros, así como los mensajes que se le hayan enviado mientras estaba desconectada:

Si el agente envía un mensaje mientras la interfaz de usuario del chat del cliente está desconectada, el mensaje se almacena correctamente en el servidor de Connect Customer: el CCP funciona según lo previsto y todos los mensajes se graban en la transcripción, pero el dispositivo del cliente no puede recibirlos. Cuando el cliente se vuelve a conectar al WebSocket, hay una brecha en los mensajes. Los mensajes entrantes futuros volverán a aparecer desde. WebSocket Sin embargo, los mensajes de brecha siguen faltando, a menos que el código haga una llamada explícita a la GetTranscript API.

Solución

Usa el controlador de Session.onConnectionEstablished eventos de chat para llamar a la GetTranscript API. El controlador de chatSession.onConnectionEstablished eventos se activa cuando se vuelven a conectar. WebSocket ChatJS tiene una lógica de latidos y reintentos integrada para la conexión. WebSocket Sin embargo, dado que ChatJS no almacena la transcripción, debe añadir un código personalizado a la interfaz de usuario del chat para volver a buscar la transcripción manualmente.

En el siguiente ejemplo de código, se muestra cómo implementar onConnectionEstablished para llamar a 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);
      });
}      

Para ver otro ejemplo, consulta esta implementación de código abierto en. GitHub

Omisión de CORS al abrir enlaces externos

Para mejorar la seguridad, el widget de comunicaciones funciona en un entorno de pruebas. Como resultado, los enlaces externos compartidos en el widget no se pueden abrir.

Solución

Existen dos opciones para omitir el CORS y permitir la apertura de enlaces externos.