Activer la journalisation du débogage pour la collecte de données

Les méthodes suivantes contrôlent la sortie du diagnostic Web SDK. Elles n’activent pas la journalisation de la bibliothèque de balises pour une implémentation autonome de Web SDK.

debugEnableddans la commande configure : définissez debugEnabled sur true dans l’appel configure existant. Ce paramètre est utile dans les environnements de développement. S’il est déployé dans le code de votre site, il active la journalisation pour les visiteurs qui exécutent cette configuration.

alloy("configure", {
  datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
  orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
  debugEnabled: true
});

Remplacez la valeur de configuration par false ou omettez-la dans les déploiements suivants pour restaurer la valeur par défaut. Ne vous exécutez pas configure une deuxième fois sur la même instance pour activer/désactiver la journalisation. Utilisez plutôt setDebug. Un remplacement de débogage local peut être prioritaire sur la valeur de configuration. Voir debugEnabled pour la référence de configuration.

La commande setDebug : exécutez la commande sur l’instance Web SDK appropriée dans la console de votre navigateur :

alloy("setDebug", { enabled: true });

Lorsque vous avez terminé, désactivez-la :

alloy("setDebug", { enabled: false });

L’exécution de cette commande dans la console modifie votre instance locale, et non les navigateurs des autres visiteurs. Si vous placez la même commande dans le code de site déployé, cela affecte les visiteurs qui exécutent ce code. Le remplacement local peut persister entre les chargements de page pour cette instance dans la session de l’onglet de même origine lorsque l’espace de stockage du navigateur est disponible. Voir setDebug pour plus d’informations.

Le paramètre de chaîne de requête alloy_debug : ajoutez des alloy_debug=true à l’URL de la page, puis chargez la page :

https://example.com/?alloy_debug=true

Utilisez &alloy_debug=true si l’URL comporte déjà des paramètres de requête. Ce paramètre permet la journalisation locale sans modifier le code déployé. Web SDK lit le paramètre lors de la création de chaque instance. Il s’applique donc à chaque instance de Web SDK de la page. Lorsque l’espace de stockage du navigateur est disponible, le paramètre persiste pour la session de même origine de l’onglet. Par conséquent, la suppression du paramètre seul ne désactive pas la journalisation. Chargez la page avec alloy_debug=false ou exécutez setDebug avec enabled: false pour la désactiver. Si l’URL contient toujours des alloy_debug=true, le recharger permet de relancer la journalisation.

​​: ouvrez Adobe Experience Platform Debugger, sélectionnez la section Web SDK et activez le débogage dans son onglet de configuration. Désactivez l’option lorsque vous avez terminé.

Cette procédure permet d’effectuer des diagnostics. L’utilisation du débogueur pour les demandes ou l’inspection d’Edge est traitée dans la section Inspecter les demandes de collecte de données.

Sur une page contenant une bibliothèque de balises, exécutez les éléments suivants dans la console de votre navigateur :

_satellite.setDebug(true);

Cette commande expose les messages de la bibliothèque de balises, y compris la sortie _satellite.logger. Pour les instances de Web SDK gérées par l’extension de balise Web SDK, l’extension utilise le mode de débogage des balises lors de la configuration de SDK et lui transfère les modifications ultérieures du mode de débogage. Ne supposons pas que l’activation du débogage pour une instance de Web SDK autonome ou configurée en externe active également la journalisation des balises.

L’extension de balise Web SDK ne fournit pas de bouton de débogage dans son interface utilisateur de configuration des balises. Utilisez la méthode de la console pour une instance gérée par l’extension. Conservez-le en dehors des règles de balises.

Pour désactiver le mode de débogage des balises et la journalisation SDK gérée par extension correspondante :

_satellite.setDebug(false);

Le mode de débogage des balises est stocké dans l’espace de stockage local du navigateur pour l’origine de la page. Il persiste entre les chargements de page et les redémarrages du navigateur jusqu’à ce que vous le désactiviez ou effaciez les données du site et qu’il n’active pas la journalisation pour les autres visiteurs. Voir _satellite.setDebug() pour les détails sur la portée et la persistance.

La bibliothèque de balises informe l’extension uniquement lorsque le mode de débogage des balises change. Si le mode de débogage des balises est déjà activé mais que les messages Web SDK sont manquants, un remplacement de Web SDK à partir de setDebug ou alloy_debug peut avoir désactivé la connexion à SDK. Exécutez _satellite.setDebug(false) puis _satellite.setDebug(true) ou utilisez la même méthode de Web SDK qui a défini le remplacement.

Le Server SDK écrit les résultats de diagnostic dans la console du serveur et non dans le navigateur du visiteur.

Définissez debugEnabled: true dans l’appel de configure côté serveur existant pour activer la journalisation de l’instance et des descripteurs de forRequest créés à partir de cette configuration. La valeur par défaut est de false. Voir debugEnabled pour un exemple de configuration complet.

Pour une enquête ciblée, appelez setDebug sur l’identificateur de portée de requête renvoyé par forRequest. La journalisation des modifications uniquement pour ce handle, afin que vous puissiez déboguer une seule requête sans l’activer pour tous les visiteurs :

const visitor = alloy.forRequest({ request: req });

await visitor.setDebug({ enabled: true });
await visitor.sendEvent({
  xdm: { eventType: "web.webpagedetails.pageViews" }
});

L’appel de setDebug sur l’instance de niveau supérieur modifie la journalisation uniquement pour les appels effectués directement sur cette instance, et non pour ses descripteurs de requête, jusqu’à ce que vous la désactiviez ou que le processus redémarre. Pour modifier la ligne de base de tous les descripteurs de requête, mettez à jour debugEnabled dans la configuration du serveur.

Les messages identifient l’instance entre crochets, par exemple [alloy], et incluent la configuration, les entrées/résultats de méthode, les avertissements et les erreurs. Vérifiez la sortie du processus du serveur ou la destination du journal vers laquelle votre environnement d’hébergement l’achemine.

Utilisez l’API setLogLevel de Mobile Core pour sélectionner le niveau de détail des diagnostics. Android est défini par défaut sur LoggingMode.ERROR ; iOS est défini par défaut sur LogLevel.error. Définissez le niveau souhaité lors de l’initialisation de l’application avant de reproduire le problème.

​​: activer la journalisation détaillée dans votre application de développement :

import com.adobe.marketing.mobile.LoggingMode
import com.adobe.marketing.mobile.MobileCore

MobileCore.setLogLevel(LoggingMode.VERBOSE)

Affichez la sortie dans le Logcat d’Android Studio pour le processus d’application en cours d’exécution. Les messages SDK mobiles utilisent la balise AdobeExperienceSDK. Filtrez donc avec tag:AdobeExperienceSDK et assurez-vous que la visionneuse de journaux autorise les messages de débogage et détaillés. Restaurez la journalisation au niveau des erreurs lorsque vous avez terminé :

MobileCore.setLogLevel(LoggingMode.ERROR)

​​: activez la journalisation de trace dans votre application de développement :

import AEPCore
import AEPServices

MobileCore.setLogLevel(.trace)

Affichez la console de l’application en cours d’exécution dans Xcode et filtrez les AEP SDK. Restaurez la journalisation au niveau des erreurs lorsque vous avez terminé :

MobileCore.setLogLevel(.error)

Le retour au niveau d’erreur réduit le résultat du diagnostic ; il ne supprime pas les erreurs. Ces appels modifient la journalisation dans l’application en cours d’exécution, et non dans d’autres installations. Assurez-vous que votre code d’initialisation ne réactive pas la journalisation détaillée au prochain lancement ou dans une version de production.

Consultez la Référence de l’API principale mobile pour Java, Objective-C, les niveaux pris en charge et les détails spécifiques aux versions. Pour React Native ou Flutter, utilisez l’API exposée par votre wrapper Mobile SDK plutôt que de copier directement des appels natifs dans le code du wrapper. Pour l’inspection des événements connectés plutôt que la sortie de la console d’exécution, consultez 🔗.