Pular para o conteúdo principal

Limitações do conector Oracle Eloqua

info

Beta

Esse recurso está em Beta. Para usá-lo, um administrador do workspace deve ativar o Lakeflow Connect para Oracle Eloqua na página Pré-visualizações . Consulte Gerenciar prévias do Databricks.

O conector gerenciado do Oracle Eloqua no Lakeflow Connect reingere cinco tabelas na íntegra em cada execução, não captura registros excluídos de tabelas incrementais até que você execute um refresh completo e pode perder atividades que o Oracle Eloqua registra tardiamente.

Limitações gerais de conectores de software como serviço (SaaS)​

As limitações nesta seção se aplicam a todos os conectores de SaaS no Lakeflow Connect.

  • Quando você executa um pipeline agendado, os alertas não Trigger imediatamente. Em vez disso, eles fazem Trigger quando ocorre a execução da próxima 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 de origem, o Databricks pode não conseguir acessar seus dados.
  • Se um nome de tabela de origem entrar em conflito com um nome de tabela de destino existente, a atualização do pipeline falhará.
  • O suporte a pipelines de vários destinos é apenas para API.
  • Opcionalmente, você pode renomear uma tabela que ingere. Se você renomear uma tabela em seu pipeline, ele se tornará um pipeline apenas de API e você não poderá mais editar o pipeline na UI.
  • Se você selecionar uma coluna depois que um pipeline já tiver começado, o conector não fará o preenchimento automático de dados para a nova coluna. Para ingerir data histórica, execute manualmente um refresh completo na tabela.
  • O Databricks não pode ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes.
  • O sistema de origem assume que as colunas de cursor aumentam monotonicamente.
  • O conector ingere dados brutos sem transformações. Use Spark Declarative Pipelines downstream em LakeFlow Pipelines para transformações.

Limitações específicas do conector​

As limitações nesta seção aplicam-se ao conector Oracle Eloqua.

  • Espere que cada execução de pipeline reingira as tabelas option_list, event_registration_registrant, custom_object, contact_list_contact e contact_segment na íntegra. Essas tabelas não suportam ingestão incremental, portanto, cada execução lê todos os seus registros do Oracle Eloqua, e as tabelas de destino refletem inserções, atualizações e exclusões dessa execução.
  • Faça uma execução completa de um refresh de uma tabela incremental para remover registros excluídos no Oracle Eloqua. Tabelas incrementais capturam apenas registros inseridos e atualizados, portanto, os registros excluídos permanecem na tabela de destino até o próximo refresh completo. As atividades de um contato excluído também permanecem nas tabelas activity_* até um refresh completo.

Tabelas de atividades​

  • Espere que as atividades que chegam tarde sejam perdidas. Cada sincronização relê a última hora de atividades, ou o último dia para activity_email_clickthrough, três dias para activity_external_activity e sete dias para activity_bounceback. Atividades que o Oracle Eloqua registra mais tarde que isso, incluindo atividades externas retroativas por mais de três dias, são perdidas até que você faça uma execução de refresh completo. O Oracle Eloqua registra bouncebacks com horas ou dias de atraso e não documenta um atraso máximo.
  • activity_bounceback ingere atividades até uma hora antes de cada sincronização começa, porque os registros de bouncebacks do Oracle Eloqua são assíncronos. As outras tabelas de atividade ingerem atividades até o início da sincronização.
  • Uma tabela de atividade sem linhas lê novamente toda a sua história, até start_datetime, em cada sincronização. Para limitar o custo, defina uma start_datetime recente.
  • O Oracle Eloqua retorna no máximo 5.000.000 registros por exportação de atividade, e cada exportação cobre 30 dias por default. Se uma tabela produz mais de cerca de 160.000 registros por dia, defina um activity_window_step mais curto nessa tabela. Veja Opções do conector.
  • Em activity_page_view e activity_web_visit, ContactId é o contato vinculado ao visitante quando a atividade foi registrada. Para obter o contato atual do visitante, faça join de VisitorId com a tabela visitor.

Tabelas de lista de contactos e associação de segmentos​

  • contact_list_contact pula listas de contatos vazias. Ele também pula uma lista cuja contagem de membros no Oracle Eloqua ainda não foi atualizada após a adição de membros, até que a contagem seja atualizada.
  • contact_segment exporta cada segmento em cada sincronização, portanto, sua duração de sincronização aumenta com o número de segmentos em sua instância. O Oracle Eloqua aplica um limite suave de 2.000 exportações por hora a cada instância, portanto, programe a execução de contact_segment diariamente e em um horário diferente de contact_list_contact.
  • Após uma sincronização, o Oracle Eloqua impede a exclusão de uma lista de contatos ou segmento exportado por até duas horas.
  • Se uma lista de contatos ou segmento for excluído enquanto uma sincronização estiver em execução, essa sincronização falhará e a próxima sincronização será recuperada. Se o Oracle Eloqua não puder exportar um segmento, a tabela contact_segment falhará até que você corrija o segmento no Oracle Eloqua.