Guia de solução de problemas de assimilação de streaming
Este documento fornece respostas a perguntas frequentes sobre a assimilação de streaming no Adobe Experience Platform. Para perguntas e soluções de problemas relacionadas a outros serviços do Platform, incluindo aquelas encontradas em todas as APIs do Platform, consulte o guia de solução de problemas do Experience Platform.
O Adobe Experience Platform Data Ingestion fornece APIs RESTful que você pode usar para assimilar dados em Experience Platform. Os dados assimilados são usados para atualizar perfis de clientes individuais em tempo quase real, permitindo que você forneça experiências personalizadas e relevantes em vários canais. Leia a Visão geral da assimilação de dados para obter mais informações sobre o serviço e os diferentes métodos de assimilação. Para obter etapas sobre como usar as APIs de assimilação de streaming, leia a visão geral da assimilação de streaming.
Perguntas frequentes
Veja a seguir uma lista de respostas para perguntas frequentes sobre a assimilação por transmissão.
Como saber se a carga que estou enviando está formatada corretamente?
Data Ingestion aproveita Experience Data Model esquemas (XDM) para validar o formato dos dados de entrada. O envio de dados que não estão em conformidade com a estrutura de um esquema XDM predefinido causará falha na assimilação. Para obter mais informações sobre o XDM e seu uso no Experience Platform, consulte a visão geral do Sistema XDM.
A assimilação de streaming suporta dois modos de validação: síncrono e assíncrono. Cada método de validação trata os dados com falha de forma diferente.
Validação síncrona deve ser usada durante o processo de desenvolvimento. Os registros que falham na validação são descartados e retornam uma mensagem de erro sobre o motivo da falha (por exemplo: "Formato de mensagem XDM inválido").
Validação assíncrona deve ser usada na produção. Quaisquer dados malformados que não passarem na validação serão enviados para o Data Lake como um arquivo de lote com falha, onde poderão ser recuperados posteriormente para análise adicional.
Para obter mais informações sobre validação síncrona e assíncrona, consulte a visão geral da validação de transmissão. Para obter etapas sobre como visualizar lotes que falharam na validação, consulte o guia em recuperando lotes com falha.
Posso validar uma carga de solicitação antes de enviá-la para Platform?
Cargas de solicitação só podem ser avaliadas após serem enviadas para Platform. Ao executar a validação síncrona, cargas válidas retornam objetos JSON preenchidos, enquanto cargas inválidas retornam mensagens de erro. Durante a validação assíncrona, o serviço detecta e envia dados malformados para o Data Lake, onde podem ser recuperados posteriormente para análise. Consulte a visão geral da validação de transmissão para obter mais informações.
O que acontece quando a validação síncrona é solicitada em uma borda que não oferece suporte a ela?
Quando a validação síncrona não é suportada para o local solicitado, uma resposta de erro 501 é retornada. Consulte a visão geral da validação de transmissão para obter mais informações sobre validação síncrona.
Como posso garantir que os dados sejam coletados somente de fontes confiáveis?
Experience Platform dá suporte à coleta de dados segura. Quando a coleta de dados autenticada estiver ativada, os clientes deverão enviar um JSON Web Token (JWT) e sua ID da organização como cabeçalhos de solicitação. Para obter mais informações sobre como enviar dados autenticados para o Platform, consulte o manual sobre coleta de dados autenticada.
Qual é a latência para streaming de dados em Real-Time Customer Profile?
Eventos transmitidos geralmente são refletidos em Real-Time Customer Profile em menos de 60 segundos. As latências reais podem variar devido a limitações de volume de dados, tamanho da mensagem e largura de banda.
É possível incluir várias mensagens na mesma solicitação de API?
Você pode agrupar várias mensagens em uma única carga de solicitação e transmiti-las para Platform. Quando usado corretamente, agrupar várias mensagens em uma única solicitação é uma excelente maneira de otimizar as operações de dados. Leia o tutorial sobre envio de várias mensagens em uma solicitação para obter mais informações.
Como faço para saber se os dados que estou enviando estão sendo recebidos?
Todos os dados enviados para Platform (com sucesso ou não) são armazenados como arquivos em lotes antes de serem mantidos em conjuntos de dados. O status de processamento dos lotes é exibido dentro do conjunto de dados para o qual foram enviados.
Você pode verificar se os dados foram assimilados com êxito verificando a atividade do conjunto de dados usando a interface de usuário Experience Platform. Clique em Conjuntos de dados no menu de navegação esquerdo para exibir uma lista de conjuntos de dados. Selecione o conjunto de dados para o qual você está fazendo streaming na lista exibida para abrir sua página Atividade do conjunto de dados, mostrando todos os lotes enviados durante um período selecionado. Para obter mais informações sobre como usar o Experience Platform para monitorar fluxos de dados, consulte o manual em monitorando fluxos de dados de transmissão.
Se os dados não forem assimilados e você quiser recuperá-los do Platform, é possível recuperar os lotes com falha enviando suas IDs para o Data Access API. Consulte o manual sobre recuperação de lotes com falha para obter mais informações.
Por que meus dados de transmissão não estão disponíveis no Data Lake?
Há vários motivos pelos quais a assimilação em lote pode falhar ao alcançar Data Lake, como formatação inválida, dados ausentes ou erros de sistema. Para determinar por que o lote falhou, você deve recuperar o lote usando o Data Ingestion Service API e visualizar seus detalhes. Para obter etapas detalhadas sobre como recuperar um lote com falha, consulte o manual em recuperando lotes com falha.
Como faço para analisar a resposta retornada para a solicitação da API?
Você pode analisar uma resposta verificando primeiro o código de resposta do servidor para determinar se sua solicitação foi aceita. Se um código de resposta bem-sucedido for retornado, você poderá revisar o objeto de matriz responses para determinar o status da tarefa de assimilação.
Uma solicitação de API de mensagem única bem-sucedida retorna o código de status 200. Uma solicitação de API de mensagem em lote bem-sucedida (ou parcialmente bem-sucedida) retorna o código de status 207.
O JSON a seguir é um objeto de resposta de exemplo para uma solicitação de API com duas mensagens: uma bem-sucedida e outra com falha. As mensagens cujo fluxo foi bem-sucedido retornam uma propriedade xactionId. As mensagens com falha no fluxo retornam uma propriedade statusCode e uma resposta message com mais informações.
{
"inletId": "9b0cb233972f3b0092992284c7353f5eead496218e8441a79b25e9421ea127f5",
"batchId": "1565638336649:1750:244",
"receivedTimeMs": 1565638336705,
"responses": [
{
"xactionId": "1565650704337:2124:92:3"
},
{
"statusCode": 400,
"message": "inletId: [9b0cb233972f3b0092992284c7353f5eead496218e8441a
79b25e9421ea127f5]
imsOrgId: [{ORG_ID}]
Message has unknown xdm format"
}
]
}
Por que minhas mensagens enviadas não estão sendo recebidas por Real-Time Customer Profile?
Se Real-Time Customer Profile rejeitar uma mensagem, ela provavelmente se deve a informações de identidade incorretas. Isso pode ser o resultado de fornecer um valor ou namespace inválido para uma identidade.
Há dois tipos de namespaces de identidade: padrão e personalizado. Ao usar namespaces personalizados, verifique se o namespace foi registrado em Identity Service. Consulte a visão geral do namespace de identidade para obter mais informações sobre o uso de namespaces padrão e personalizados.
Você pode usar o Experience Platform UI para ver mais informações sobre por que uma mensagem não foi assimilada. Clique em Monitoramento no menu de navegação esquerdo e exiba a guia Transmissão de ponta a ponta para ver os lotes de mensagens transmitidos durante um período selecionado.