Ativações recomendadas

Para limitar o crescimento de dados associado ao uso pesado de Virtual Agent e Bate-papo do agente, ative os trabalhos de limpeza na tabela a seguir:

Quais tabelas devem ser limpas

Essas tabelas devem ser limpas porque podem crescer para milhões de registros em instâncias de longa execução:

• Histórico de presença do agente [awa_agent_presence_history]
• AWA Tamanho do documento [awa_document_size]
• AWA Item de trabalho [awa_work_item]
• Consumidor [sys_cs_consumer]
• Contexto do dispositivo do consumidor [sys_cs_consumer_device_context]
• Conversa [sys_cs_conversation]
• Interação [interação]
• Blob JSON de interação [interaction_json_blob]
• Perfil do grupo em tempo real [live_group_profile]

Há outras tabelas relacionadas, como as tabelas Mensagem de conversa [sys_cs_message] e Mensagem do Feed de atividades [live_message], que também podem se tornar grandes. Essas tabelas têm reference_cascade_rule_delete atributos que fazem com que sejam limpas como um efeito colateral da limpeza das tabelas na lista anterior.

Quais registros nas tabelas devem ser excluídos

A configuração de Limpeza automática permite selecionar os campos Campo de correspondência e Idade em segundos. O campo Campo de correspondência corresponde a uma coluna de data na tabela e o campo Idade em segundos indica quando as exclusões são acionadas. Quando um registro atinge um ponto em que o campo Campo de correspondência tem uma data que está mais no passado do que o campo Idade em segundos, o limpador exclui o registro quando é executado.

O ideal é que o campo Campo de correspondência indique há quanto tempo o registro está ativo. As colunas na tabela a seguir funcionam bem como o campo Campo de correspondência para as tabelas em questão, com a condição adicional no campo Condições onde indicado.

interaction.closed_at e sys_cs_conversation.conversation_completed não são boas opções para o campo Campo de correspondência porque não têm valores para conversas com falha e algumas interações encerradas. As lacunas podem ser fechadas com regras de negócio que definem esta data se estiver vazia quando ocorre uma mudança de estado apropriada, mas para simplificar, use o campo sys_updated_on para essas tabelas.

Outras tabelas podem ser limitadas por condições no campo de estado que garantem que somente os bate-papos encerrados sejam excluídos. Como as interações nunca devem ser deixadas abertas por mais de alguns dias em geral, essas condições podem ser omitidas para tornar as consultas mais simples e executadas mais rapidamente após a última atualização. O estado na tabela awa_work_item pode ser mais importante porque tarefas de execução mais longa, como casos, também são representadas.

O problema com a tabela sys_cs_consumer é que, embora normalmente você queira manter esses registros para corresponder novas conversas a usuários existentes, no caso de usuários convidados, um registro diferente é criado para cada conversa.

Para a tabela sys_cs_consumer_device_context, há uma referência à tabela CS Consumer Account [sys_cs_consumer_account] (que tem uma referência à tabela sys_cs_consumer), mas a referência não está marcada com reference_cascade_rule=delete. A recomendação é adicionar essa regra à referência da conta do consumidor. Dessa forma, quando o limpador excluir os registros nas tabelas sys_cs_consumer e sys_cs_consumer_account, ele também os excluirá.

As tabelas awa_agent_presence e awa_agent_channel_availability não aumentam por bate-papo da mesma forma que outras tabelas, mas são acessadas regularmente pelo mecanismo de atribuição e podem terminar com entradas obsoletas de usuários que não estão mais ativos. Entradas não utilizadas por muito tempo também devem ser limpas aqui. É preciso ter cuidado extra com a coluna awa_agent_channel_availability porque ela pode não ser atualizada com frequência. Por esse motivo, uma condição extra deve ser adicionada a esse limpador para que somente registros associados a usuários inativos possam ser removidos.

Quando os registros podem ser excluídos com segurança

Existem várias considerações para determinar quando os registros podem ser excluídos com segurança:

• Não exclua registros de conversas em andamento.

  Para conversas de bate-papo baseadas em sessão, o limite de idade é de apenas alguns dias. Se as conversas por SMS/mensagens forem incluídas, o limite de idade poderá se estender por algumas semanas ou mais. Uma maneira de avaliar isso é examinar todas as propriedades do formulário com.glide.cs.*_idle_timeout e localizar aquela com o valor mais alto.

• Não exclua registros que contribuem para painéis/relatórios sobre atividades recentes.

  O AWA do painel Interactions-Advanced Analytics inclui um indicador de tendências semanais que analisa três meses no passado. Para oferecer suporte total a isso, você deve manter os registros de interação e awa_work_item por pelo menos 90 dias.

• Não exclua registros se algum de seus dados precisar ser arquivado para referência posterior.

  O tempo disso depende do tempo de qualquer lógica personalizada adicionada para fazer o arquivamento necessário. Você deve ser capaz de configurar isso para que ele seja executado com antecedência suficiente para não ser o fator de decisão.

Considerações de desempenho

Os índices sys_updated_on são necessários para as tabelas ausentes?

Os testes foram executados em uma instância que teve mais de 12.000.000 interações, com uma limpeza de tabela configurada para uma tabela com um índice no campo sys_updated_on (interação) e uma que não tem (interaction_json_blob). Em ambos os casos, para execuções iniciais e subsequentes, o tempo gasto fazendo exclusões (potencialmente muitos minutos) superou em muito o tempo gasto na consulta dos registros (2 segundos ou menos). Dado este resultado, nenhum índice adicional precisa ser adicionado às tabelas, pois o impacto no desempenho seria mínimo.

Quando o trabalho de limpeza de tabela inicial e repetido deve ser executado?

Normalmente, o limpador de tabela sys_trigger é executado uma vez por hora. Se um ou mais limpadores forem definidos em tabelas com muitos registros desatualizados, o número de exclusões feitas durante a primeira execução poderá ser muito alto e sobrecarregar o sistema. Antes de ajustar e ativar a configuração de limpeza de tabela, altere temporariamente esta programação de limpeza de tabela para que sua próxima execução ocorra fora do horário comercial (um momento em que o sistema geralmente está com uma carga mais leve).

Se não houver horários de folga, algumas propriedades que regem os limpadores de tabela podem ajudar. Em particular, glide.db.tablecleaner.chunk_delete_max_time_spend limita quanto tempo o limpador gasta tentando excluir registros em lote durante uma única execução. O valor é fornecido em segundos e o padrão é 1200 (20 minutos). Isso significa que, na configuração do sistema de base, o limpador de tabela é executado por hora por no máximo 20 minutos (para referência, durante um teste, cerca de 400.000 interações podem ser excluídas em 20 minutos, incluindo exclusões em cascata). Se 20 minutos a cada hora for muito agressivo, o valor da propriedade poderá ser reduzido.