Limitações do conector do Zendesk Support

Limitações gerais

• Ao executar um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, elas são acionadas na próxima execução da atualização.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do Spark Declarative Pipelines no Lakeflow.
• Durante períodos de manutenção da fonte de dados, o Databricks poderá não conseguir acessar seus dados.
• Se o nome de uma tabela de origem entrar em conflito com o nome de uma tabela de destino existente, a atualização do pipeline falhará.
• O suporte pipeline com múltiplos destinos é feito exclusivamente via API.
• Opcionalmente, você pode renomear uma tabela que você importa. Se você renomear uma tabela em seu pipeline, ele se tornará um pipeline somente para API e você não poderá mais editá- pipeline na interface do usuário.
• Se você selecionar uma coluna depois que um pipeline já tiver sido iniciado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, execute manualmente uma refresh completa na tabela.
• O Databricks não consegue ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas provenham de esquemas de origem diferentes.
• O sistema de origem pressupõe que as colunas do cursor estejam em ordem crescente monotônica.
• O conector ingere dados brutos sem transformações. Use os Spark Declarative Pipelines downstream em Lakeflow pipelines para transformações.

Produtos Zendesk compatíveis

A Zendesk oferece uma variedade de produtos, incluindo Zendesk Support, Zendesk Chat, Zendesk Talk e outros. O Databricks suporta apenas a ingestão de dados do Zendesk Support, incluindo dados de tickets, conteúdo da base de conhecimento e dados do fórum da comunidade.

limites de taxa da API

A Zendesk impõe limites de taxa em sua API REST , especialmente para o endpoint de dados incrementais. Para garantir um desempenho consistente na ingestão de dados, a Databricks recomenda limitar o número de tabelas que você ingere simultaneamente. Por exemplo, você pode dividir tabelas em vários pipelines e programá-las em momentos diferentes.

Campos aninhados e personalizados

Alguns campos no esquema podem estar aninhados em estruturas complexas, e os campos de nível interno podem incluir atributos personalizados. Para garantir compatibilidade e consistência, esses campos são representados como um tipo de dados de string. Por exemplo, a coluna custom_fields na tabela tickets é uma matriz de objetos personalizados, que podem ter qualquer número de subcampos.

Registros de auditoria podem ser alterados após a criação

O Zendesk documenta os registros de auditoria de tickets como imutáveis, mas alguns campos dentro de uma auditoria podem continuar a mudar depois que a auditoria é criada pela primeira vez. Por exemplo, a transcrição do chat no evento ChatStartedEvent da tabela ticket_audits pode continuar a aumentar por vários minutos após o carimbo de data/hora created_at da auditoria, à medida que mensagens posteriores na conversa são adicionadas.

Como o conector ingere a tabela ticket_audits incrementalmente usando o cursor created_at, ele lê cada auditoria uma vez e não a revisita. Se um campo mudar depois que o conector ingeriu a auditoria, a tabela de destino manterá o valor que estava presente no momento da ingestão e não refletirá a atualização posterior. O conector não apresenta erro, porque ele persiste os dados exatos retornados pela API do Zendesk no momento da leitura.

Para obter os valores atuais dos registros afetados, execute um refresh completo da tabela ticket_audits.