Show Menu
SUJETS×

Guide de dépannage de l’ingestion par flux

Ce document répond aux questions les plus fréquentes sur l’ingestion par flux sur Adobe Experience Platform. For questions and troubleshooting related to other Platform services, including those that are encountered across all Platform APIs, please refer to the Experience Platform troubleshooting guide .
Adobe Experience Platform Data Ingestion provides RESTful APIs that you can use to ingest data into Experience Platform. Les données ingérées sont utilisées pour mettre à jour les profils clients individuels quasiment en temps réel, ce qui vous permet de proposer des expériences personnalisées et pertinentes sur plusieurs canaux. Pour en savoir plus sur le service et les différentes méthodes d’ingestion, consultez la présentation de Data Ingestion . Pour savoir comment utiliser les API d’ingestion par flux, consultez la présentation de l’ingestion par flux .

FAQ

Voici une liste de réponses aux questions fréquentes sur l’ingestion par flux.

Comment savoir que le payload que j’envoie est correctement formaté ?

Data Ingestion utilise Experience Data Model (XDM) des schémas pour valider le format des données entrantes. L’envoi de données non conformes à la structure d’un schéma XDM prédéfini entraîne l’échec de l’ingestion. For more information on XDM and its use in Experience Platform, see the XDM System overview .
L’ingestion par flux prend en charge deux modes de validation : synchrone et asynchrone. Chaque méthode de validation gère les données ayant échoué différemment.
La validation synchrone doit être utilisée pendant votre processus de développement. Les enregistrements dont la validation a échoué sont ignorés et renvoient un message d’erreur expliquant pourquoi ils ont échoué (par exemple : « Format de message XDM non valide »).
La validation asynchrone doit être utilisée en production. Any malformed data that does not pass validation is sent to the Data Lake as a failed batch file, where it can be retrieved later for further analysis.
Pour plus d’informations sur la validation synchrone et asynchrone, consultez la présentation de la validation de l’ingestion par flux . Pour savoir comment afficher des lots dont la validation a échoué, reportez-vous au guide sur la récupération des lots en échec .

Puis-je valider un payload de requête avant de l’envoyer à Platform?

Les payloads de requête ne peuvent être évalués qu’après avoir été envoyés à Platform. Lors d’une validation synchrone, les payloads valides renvoient des objets JSON renseignés, tandis que les payloads non valides renvoient des messages d’erreur. During asynchronous validation, the service detects and sends any malformed data to the Data Lake where it can later be retrieved for analysis. Pour plus d’informations, consultez la présentation de la validation de l’ingestion par flux .

Que se passe-t-il lorsque la validation synchrone est demandée sur une périphérie qui ne la prend pas en charge ?

Lorsque la validation synchrone n’est pas prise en charge pour l’emplacement demandé, une réponse d’erreur 501 est renvoyée. Pour plus d’informations sur la validation synchrone, consultez la présentation de la validation de l’ingestion par flux .

Comment puis-je m'assurer que les données ne sont collectées qu'à partir de sources fiables ?

Experience Platform prend en charge la collecte de données sécurisées. Lorsque la collecte de données authentifiées est activée, les clients doivent envoyer un jeton JSON Web Token (JWT) et leur ID d’organisation IMS en tant qu’en-têtes de requête. For more information on how to send authenticated data to Platform, please see the guide on authenticated data collection .

What is the latency for streaming data to Real-time Customer Profile?

Streamed events are generally reflected in Real-time Customer Profile in under 60 seconds. Les latences réelles peuvent varier en raison du volume de données, de la taille du message et des limitations de bande passante.

Puis-je inclure plusieurs messages dans la même requête d’API ?

Vous pouvez regrouper plusieurs messages dans un payload de requête unique et les diffuser sur Platform. Lorsque cette fonctionnalité est utilisée correctement, regrouper plusieurs messages au sein d’une requête unique est une excellente manière d’optimiser vos opérations de données. Pour plus d’informations, lisez le tutoriel sur l’ envoi de plusieurs messages dans une requête .

Comment savoir si les données que j’envoie sont reçues ?

All data that is sent to Platform (successfully or otherwise) is stored as batch files before being persisted in datasets. L’état du traitement des lots s’affiche dans le jeu de données dans lequel ils ont été envoyés.
Vous pouvez vérifier si les données ont bien été ingérées en vérifiant l’activité du jeu de données à l’aide de l’ interface utilisateur d’Experience Platform . Cliquez sur Jeux de données dans le volet de navigation de gauche pour afficher une liste de jeux de données. Sélectionnez le jeu de données vers lequel vous effectuez une diffusion par flux à partir de la liste affichée pour ouvrir la page d’ activité du jeu de données , qui montre tous les lots envoyés au cours d’une période sélectionnée. For more information about using Experience Platform to monitor data streams, see the guide on monitoring streaming data flows .
If your data failed to ingest and you want to recover it from Platform, you can retrieve the failed batches by sending their IDs to the Data Access API. Pour plus d’informations, consultez le guide sur la récupération des lots en échec .

Pourquoi mes données en diffusion continue ne sont-elles pas disponibles dans le lac de données ?

There are a variety of reasons why batch ingestion may fail to reach the Data Lake, such as invalid formatting, missing data, or system errors. To determine why your batch failed, you must retrieve the batch using the Data Ingestion Service API and view its details. Pour obtenir des instructions détaillées sur la récupération d’un lot en échec, consultez le guide sur la récupération des lots en échec .

Comment analyser la réponse renvoyée pour la requête d’API ?

Vous pouvez analyser une réponse en vérifiant d’abord le code de réponse du serveur afin de déterminer si votre requête a été acceptée. Si un code de réponse réussie est renvoyé, vous pouvez alors examiner l’objet de tableau responses pour déterminer l’état de la tâche d’assimilation.
Une requête d’API à message unique réussie renvoie le code d’état 200. Une requête d’API de message par lot réussie (ou partiellement réussie) renvoie le code d’état 207.
Le fichier JSON suivant est un exemple d’objet de réponse pour une requête d’API avec deux messages : une a réussi et une a échoué. Les messages dont la diffusion continue réussit renvoient une propriété xactionId . Les messages dont la diffusion continue échoue renvoient une propriété statusCode et une réponse message avec plus d’informations.
{
    "inletId": "9b0cb233972f3b0092992284c7353f5eead496218e8441a79b25e9421ea127f5",
    "batchId": "1565638336649:1750:244",
    "receivedTimeMs": 1565638336705,
    "responses": [
        {
            "xactionId": "1565650704337:2124:92:3"
        },
        {
            "statusCode": 400,
            "message": "inletId: [9b0cb233972f3b0092992284c7353f5eead496218e8441a
                79b25e9421ea127f5] 
                imsOrgId: [{IMS_ORG}] 
                Message has unknown xdm format"
        }
    ]
}

Why are my sent messages not being received by Real-time Customer Profile?

If Real-time Customer Profile rejects a message, it is most likely due to incorrect identity information. Cela peut être le résultat d’une valeur ou d’un espace de noms d’identité non valide.
Il existe deux types d’espace de noms d’identité : par défaut et personnalisé. Lors de l’utilisation d’espaces de noms personnalisés, assurez-vous que l’espace de noms a été enregistré dans Identity Service. Pour plus d’informations sur l’utilisation des espaces de noms par défaut et personnalisés, consultez la présentation des espaces de noms d’identité .
You can use the Experience Platform UI to see more information on why a message failed ingestion. Cliquez sur Surveillance dans le volet de navigation de gauche, puis consultez l’onglet Diffusion en continu de bout en bout pour voir les lots de messages diffusés au cours d’une période sélectionnée.