Les déclencheurs sont une intégration entre Adobe Campaign et Adobe Analytics utilisant le pipeline. Le processus récupère des actions ou des déclencheurs des utilisateurs de votre site Web. Un abandon de panier est un exemple de déclencheur. Les déclencheurs sont traités dans Adobe Campaign pour envoyer des courriers électroniques en temps réel.
Résumé Ce document décrit les composants qui constituent l’intégration dans Adobe Campaign. Il explique également comment résoudre les problèmes courants et les configurations. 
Solution Adobe Campaign Classic (v6.11, v7)
Public Administrateurs, utilisateurs avancés

Si vous avez des questions sur cet article ou sur une autre rubrique d’Adobe Campaign, demandez de l’aide à la communauté.

Présentation

Les déclencheurs exécutent des actions marketing au sein d’une courte période après l’action de l’utilisateur. Le temps de réponse standard est inférieur à une heure.

Cela permet d’effectuer des intégrations plus agiles, car la configuration est minime et aucun tiers n’est impliqué.
Il prend également en charge les gros volumes de trafic sans affecter la performance des activités marketing. Par exemple, l’intégration peut traiter un million de déclencheurs par heure.

Architecture

Qu’est-ce que le commerce électronique ?

Le pipeline est un système de messagerie dans Experience Cloud qui utilise Apache Kafka. Il permet de transmettre facilement des données entre les solutions. En outre, le pipeline est une file d’attente de message plutôt qu’une base de données. Les producteurs poussent les événements dans le pipeline et les consommateurs écoutent l’enchaînement et les actions et font ce qu’ils souhaitent avec l’événement. Les événements sont conservés pendant quelques jours, mais pas plus. L’opération consiste à écouter 24/7 et traiter les événements immédiatement.

Picture1

Comment fonctionne le pipeline ?

Le processus « pipelined » s’exécute toujours sur le serveur marketing Adobe Campaign. Il se connecte au pipeline, récupère les événements et les traite immédiatement. 

Picture2

Le processus pipelined se connecte à l’Experience Cloud à l’aide d’un service d’authentification et envoie une clé privée. Le service d’authentification renvoie un jeton. Le jeton est utilisé pour authentifier les événements. Les déclencheurs sont récupérés à partir d’un service Web REST à l’aide d’une requête GET simple. La réponse est au format JSON. Les paramètres de la requête incluent le nom du déclencheur et un pointeur qui indique le dernier message récupéré. Le processus pipelined la traite automatiquement.

Utilisation

Remarque :

Il s’agit d’un exemple spécifique de diverses implémentations possibles.

Les événements de flux sont téléchargés automatiquement. Ces événements peuvent être contrôlés à l’aide d’un formulaire.

image2017-1-13 18_8_3 blur

Un flux de production de campagne recurrent effectue une requête sur les déclencheurs et s’il correspond aux critères marketing, il commence une diffusion.

image2017-1-13 18_13_31 blur

Configuration du pipeline

Présentation

Les paramètres d’authentification tels que l’identifant iclient, la clé privée et les paramètres d’authentification sont configurés dans les fichiers de configuration de l’occurrence.
La liste de déclencheurs à traiter est configurée dans une option. Il est au format JSON.

Le déclencheur est traité immédiatement à l’aide du code JavaScript. Il est enregistré dans une table de base de données sans traitement supplémentaire en temps réel.
Les déclencheurs sont utilisés pour cibler par un flux de campagne qui envoie des messages électroniques. La campagne est configurée de sorte qu’un client qui déclenche les deux événements de déclenchement reçoive un courrier électronique.

Conditions préalables

L’utilisation d’Experience Cloud Triggers dans Campaign requiert les éléments suivants :

  • Génération 8705 de la version 6,11 de Adobe Campaign ou version ultérieure.
  • Adobe Analytics Ultimate, Premium, Foundation, OD, Select, Prime, Mobile Apps, Select oder Standard.

Les configurations préalables sont les suivantes :

  • Création d’un fichier de clé privée, puis création de l’application oAuth enregistrée avec cette clé.
  • Configuration des déclencheurs dans Adobe Analytics.

La configuration d’Adobe Analytics est hors du domaine de ce document. 
Adobe Campaign nécessite les informations suivantes de Adobe Analytics :

  • Nom de l’application oAuth.
  • Le IMSOrgId. Il s’agit de l’identifiant du client Experience Cloud.
  • Noms des déclencheurs configurés dans Analytics.
  • Nom et format des champs de données à rapprocher de la base de données marketing.

Remarque :

Une partie de cette configuration est un développement personnalisé et requiert les éléments suivants :

  • Connaissance de JSON, XML et JavaScript dans Adobe Campaign.
  • Connaissance des API QueryDef et Writer.
  • Utilisation de notions de chiffrement et d’authentification à l’aide de clés privées.

La modification du code JS nécessite des compétences techniques, ne le faites pas sans une bonne compréhension.

Les déclencheurs sont enregistrés dans une table de base de données. Par conséquent, le déclenchement de données peut être utilisé en toute sécurité par les opérateurs marketing dans les flux de production de ciblage.

Fichiers d’authentification et de configuration

L’authentification est requise car le pipeline est hébergé dans Adobe Experience Cloud.
Si le serveur marketing est hébergé sur place, lorsqu’il se connecte au pipeline, il doit authentifier pour avoir une connexion sécurisée.
Il utilise une paire de clés publiques et clés privées. Il s’agit de la même fonction qu’un utilisateur/mot de passe, mais uniquement plus sécurisé.

IMSOrgId

Le IMSOrgId est l’identifiant du client sur Adobe Experience Cloud.
Définissez-la dans le fichier serverConf.xml d’instance dans l’attribut IMSOrgId.

Exemple :

<redirection IMSOrgId="C5E715(…)98A4@AdobeOrg" (…)

Génération de clés

La clé est une paire de fichiers. Il est au format RSA et fait 4096 octets. Il peut être généré avec un outil open source tel que OpenSSL. Chaque fois que l’outil est exécuté, une nouvelle clé est générée de manière aléatoire.

Pour faciliter la tâche, les étapes sont énumérées ci-dessous :

  • openssl genrsa -out <private_key.pem> 4096
  • openssl rsa -pubout -in <private_key.pem> -out <public_key.pem>

Exemple de fichier private_key.pem :

 

 ----BEGIN RSA PRIVATE KEY----
 MIIEowIBAAKCAQEAtqcYzt5WGGABxUJSfe1Xy8sAALrfVuDYURpdgbBEmS3bQMDb
 (…)
 64+YQDOSNFTKLNbDd+bdAA+JoYwUCkhFyvrILlgvlSBvwAByQ2Lx
 ----END RSA PRIVATE KEY---- 

 Exemple de fichier public_key.pem :

----BEGIN PUBLIC KEY----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtqcYzt5WGGABxUJSfe1X
(…)
EwIDAQAB
----END PUBLIC KEY----

Remarque :

Les clés ne doivent pas être générées par PuttyGen, OpenSSL constitue la meilleure solution.

Création client oAuth dans Adobe Experience Cloud

Une application de type JWT doit être créée en se connectant à Adobe Developer Connection et procédez comme suit :

  1. Sélectionnez le compte de service (JWT Assertion).
  2. Entrez le nom de l’application.
  3. Enregistrez la clé publique.
  4. Sélectionnez l’organisation (Compte Admin obligatoire).
  5. Sélectionnez l’étendue du déclencheur.
worddav742582ccac2fe4e5078ee2804a38addf

Configuration de l’identifiant d’application dans Adobe Campaign

L’identfiant d’application du client oAuth créé doit être configuré dans Adobe Campaign. Pour ce faire, modifiez le fichier de configuration de l’occurrence dans l’élément pipelined, en particulier l’attribut appName.

Exemple :

<pipelined autoStart="true" appName="applicationID" authPrivateKey="@qQf146pexBksGvo0esVIDO(…)"/>

Chiffrement clé

Pour être utilisé par le pipelined, la clé privée doit être chiffrée.
Le chiffrement est effectué à l’aide de la fonction JavaScript cryptString.
Il doit être exécuté sur la même instance que le pipelined. 
Un exemple de chiffrement de clé privée JavaScript est disponible dans les Annexes.

Enregistrement clé dans Adobe Campaign

La clé privée chiffrée doit être enregistrée dans Adobe Campaign. Pour ce faire, modifiez le fichier de configuration de l’occurrence dans l’élément pipelined, en particulier l’attribut authPrivateKey.

Exemple :

<pipelined autoStart="true" appName="applicationID" authPrivateKey="@qQf146pexBksGvo0esVIDO(…)"/>

Démarrage automatique du processus pipelined

Le processus de pipelined doit être démarré automatiquement.

Pour ce faire, définissez l’élément dans le fichier de configuration sur autostart="true" :

<pipelined autoStart="true" appName="applicationID" authPrivateKey="@qQf146pexBksGvo0esVIDO(…)"/>

Redémarrage des processus Pipelined

Il peut également être démarré manuellement en utilisant l’option de ligne de commande :
nlserver start pipelined@instance

Un redémarrage est nécessaire pour que les modifications prennent effet :
nlserver restart pipelined@instance

En cas d’erreur

Recherchez les erreurs sur la sortie standard (si vous avez commencé manuellement) ou dans le fichier journal pipelined. Reportez-vous à la section Dépannage de ce document pour plus d’informations sur la résolution des problèmes.

Options de configuration Pipelined

Option Description
appName Identifiant de l’application OAuth enregistrée dans Adobe Developer Connection (où la clé publique a été téléchargée).
Voir : https://marketing.adobe.com/developer/fr/documentation/authentication-1/auth-service-account-1
authGatewayEndpoint URL pour obtenir les « jetons de passerelle ». Valeur par défaut : https://api.omniture.com
authPrivateKey Clé privé (partie publique téléchargée dans Adobe Developer Connection) le chiffrement AES avec l’option :
cryptString("PRIVATE_KEY")
disableAuth Authentification (se connecter sans jetons de gateway est uniquement accepté par des paramètres de pipeline de développement)
discoverPipelineEndpoint URL pour découvrir le paramètre de Services de Pipeline à utiliser pour cette classe. Valeur par défaut : https://producer-pipeline-pnw.adobe.net
dumpStatePeriodSec Période entre 2 vidages de l’état interne de processus dans var/INSTANCE/pipelined.json ? L’état interne est également accessible à la demande sur http://INSTANCE:7781/pipelined/status
forcedPipelineEndpoint Désactivation de la découverte du PipelineServicesEndpoint et forçage
monitorServerPort Le processus pipelined écoute ce port pour fournir l’état interne du processus à l’adresse http://INSTANCE:PORT/pipelined/status. La valeur par défaut est 7781
pointerFlushMessageCount Lorsque ce nombre de messages est traité, les décalages sont enregistrés dans la base de données. La valeur par défaut est 1000
pointerFlushPeriodSec Après cette période, les décalages seront enregistrés dans la base de données. La valeur par défaut est 5 (secondes)
processingJSThreads Nombre de messages de traitement des threads dédiés avec des connecteurs JS personnalisés. La valeur par défaut est 4
processingThreads Nombre de messages de traitement des threads dédiés avec code intégré. La valeur par défaut est 4
retryPeriodSec Délai entre les tentatives (s’il existe des erreurs de traitement). La valeur par défaut est 30 (secondes)
retryValiditySec Ignore le message s’il n’a pas été traité correctement après cette période (trop de tentatives). La valeur par défaut est 300 (secondes)

Option de commerce NmsPipeline_Config

Une fois l’authentification terminée, pipelined peut récupérer les événements et les traiter. Ne déclenche que les déclencheurs configurés dans Adobe Campaign, en ignorant les autres. Le déclencheur doit avoir été généré à partir d’Analytics et envoyé au projet ci-dessus.
L’option peut également être configurée avec un caractère générique pour capturer tous les déclencheurs, quel que soit le nom.
La configuration des déclencheurs est effectuée dans une option, sous. Administration > Plateforme > Option Le nom de cette option est NmsPipeline_Config. Le type de données est « texte long ». Il est au format JSON.

Exemple 1

Cet exemple spécifie deux déclencheurs.

Collez le code JSON de ce modèle dans la valeur d’option. Veillez à supprimer les commentaires.

{
	"topics": [ // list of "topics" that the pipelined is listening to.
		{
			"name": "triggers", // Name of the first topic : triggers.
			"consumer": "customer_dev", // Name of the instance that listens. 
			"triggers": [ // Array of triggers. 
				{
					"name": "3e8a2ba7-fccc-49bb-bdac-33ee33cf02bf", // TriggerType ID from Analytics 
					"jsConnector": "cus:triggers.js" // Javascript library holding the processing function.
				}, {
					"name": "2da3fdff-13af-4c51-8ed0-05802a572e94", // Second TriggerType ID 
					"jsConnector": "cus:triggers.js" // Can use the same JS for all.
				},
			]
		}
	]
}

Exemple 2

Cet exemple capture tous les déclencheurs.

{
 "topics": [
    {
      "name": "triggers",     
      "consumer":  "customer_dev",                         
      "triggers": [    
        {
          "name": "*",
          "jsConnector": "cus:pipeline.js" 
        }
      ]
    }
 ]
 }

Remarque :

La valeur UID de déclenchement à un nom de déclencheur spécifique dans l’interface Analytics peut se trouver dans les paramètres querystring de l’URL de l’interface de diagnostic. Le triggerType UID est transmis dans le flux de données du pipeline et le code peut être saisi dans la pipeline.JS pour mapper le déclencheur UID à un libellé convivial qui peut être stocké dans une colonne nom du déclencheur dans le schéma pipelineEvents.

Paramètre Consommateur

Le processus fonctionne avec un modèle « fournisseur et consommateur ». Il peut y avoir de nombreux consommateurs dans la même file d’attente. Les messages ne sont « consommés » que pour un consommateur individuel Chaque client obtient son propre « copie » des messages.


Le paramètre « consommateur » identifie l’exemple en tant que l’une de ces consommateurs. Il s’agit de l’identité de l’occurrence qui appelle le pipeline. Vous pouvez le remplir avec le nom de l’occurrence. Le service de flux suit les messages récupérés par chaque consommateur. L’utilisation de différents consommateurs pour différentes instances garantit que chaque message est envoyé à chaque occurrence.

Configuration de l’option de pipeline

Ajoutez ou modifiez d’Experience Cloud Triggers sous le tableau « déclencheurs » ; ne modifiez pas le reste.
Assurez-vous que le JSON est valide. Ce site Web peut vous aider : http://jsonlint.com/

  • « nom » correspond à l’identifiant de déclenchement. Un caractère générique "*" intercepte tous les déclencheurs.
  • « Consommateur » est une chaîne unique qui identifie de manière unique l’occurrence de nlserver. Il peut généralement s’agir du nom d’occurrence lui-même. Pour plusieurs environnements (dev/stage/prod), vérifiez qu’il est unique pour chacune d’elles afin que chaque instance obtienne une copie du message.
  • Pipelined prend également en charge la rubrique « alias ».

Relancez pipelined après avoir apporté des modifications.

Traitement des événements

Traitement des événements dans JavaScript

Fichier JS

Le pipeline utilise une fonction JavaScript pour traiter chaque message. Cette fonction est définie par l’utilisateur.

Il est configuré dans l’option NmsPipeline_Config dans l’attribut « JSConnector ». Ce javascript est appelé chaque fois qu’un événement est reçu. Il est exécuté par le processus pipelined.

L’exemple de fichier JS est cus:triggers.js.

Fonction JS

Le JavaScript de pipeline doit commencer par une fonction spécifique.

Cette fonction est appelée une fois pour chaque événement :

    function processPipelineMessage(xmlTrigger) {}

Il doit revenir <undefined/>..

Relancez pipelined après avoir modifié le JS.

Déclencheur, format de données

Les données du déclencheur sont transmises à la fonction JS. Il se trouve au format XML.

  • L’attribut @triggerId contient le nom du déclencheur.
  • L’élément d’enrichissements contient les données générées par Analytics et est associé au déclencheur. Il est au format JSON.
  • @offset est le « pointeur » du message. Il indique l’ordre du message dans la file d’attente.
  • @partition est un conteneur de messages dans la file d’attente. Le décalage est relatif à une partition. Il y a environ 15 partitions dans la file d’attente.

Exemple :

<trigger offset="1500435" partition="4" triggerId="LogoUpload_1_Visits_from_specific_Channel_or_ppp">
 <enrichments>{"analyticsHitSummary":{"dimensions":{" eVar01":{"type":"string","data":["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],"name":" eVar01","source":"session summary"}, "timeGMT":{"type":"int","data":[1469164186,1469164195],"name":"timeGMT","source":"session summary"}},"products":{}}}</enrichments>
 <aliases/>
 </trigger>

Format de données d’enrichissement

Remarque :

Il s’agit d’un exemple spécifique de diverses implémentations possibles.

Le contenu est défini dans l’analyse pour chaque déclencheur. Il est au format JSON.
Par exemple, dans un trigger LogoUpload_uploading_Visits :

  • eVar01 peut contenir l’identifiant de client utilisé pour fusionner avec les destinataires de la campagne. Il est au format de chaîne. Il doit être reconcilié pour trouver l’identifiant Shopper, qui est la clé primaire.
  • timeGMT peut contenir la période de déclenchement côté Analytics. Il est au format date UTC (secondes depuis 01/01/1970 UTC).

Exemple :

{
 "analyticsHitSummary": {
 "dimensions": {
 "eVar01": {
 "type": "string",
 "data": ["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],
 "name": " eVar01",
 "source": "session summary"
 },
 "timeGMT": {
 "type": "int",
 "data": [1469164186, 1469164195],
 "name": "timeGMT",
 "source": "session summary"
 }
 },
 "products": {}
 }
 }

Ordre du traitement des événements

Les événements sont traités un par un, par ordre de décalage. Chaque thread du pipeline traite une partition différente.

Le décalage du dernier événement récupéré est stocké dans la base de données. Par conséquent, si le processus est arrêté, il reprend à partir du dernier message. Ces données sont stockées dans le fichier xtk de schéma intégré:pipelineOffset.

Ce pointeur est spécifique à chaque instance et à chaque consommateur. Par conséquent, lorsque de nombreuses instances accèdent à la même structure avec des consommateurs différents, ils obtiennent tous les messages et dans le même ordre.

Le paramètre « consommateur » de l’option de structure identifie l’instance d’appel. 

Actuellement, il n’existe aucun moyen d’obtenir des files d’attente différentes pour des environnements distincts, tels que « staging » ou « dev ».

Gestion de connexion et des erreurs

Les journaux tels que logInfo() sont dirigés vers le journal pipelined. Des erreurs telles que logError() sont écrites dans le journal pipelined et entraînent la mise en file d’attente de l’événement.
Les messages par erreur sont relancées à plusieurs reprises dans l’ensemble de durée dans les options canalisées.
Pour corriger et surveiller les objectifs, les données complètes de déclencheur sont écrites dans le tableau de déclencheur. Il se trouve dans le champ « data » au format XML. Une autre méthode consiste à utiliser un logInfo() contenant les données du déclencheur.

Analyse des données

Ce code JS d’occurrence analyse le eVar01 dans les enrichissements.

function processPipelineMessage(xmlTrigger)
 {
 (…)
 var shopper_id = ""
 if (xmlTrigger.enrichments.length() > 0)
 {
 if (xmlTrigger.enrichments.toString().match(/eVar01/) != undefined)
 {
 var enrichments = JSON.parse(xmlTrigger.enrichments.toString())
 shopper_id = enrichments.analyticsHitSummary.dimensions. eVar01.data[0]
 }
 }
 (…)
 }

Soyez prudent lorsque vous analysez les erreurs.
Ce code est utilisé pour tous les déclencheurs, la plupart des données ne sont pas obligatoires. Par conséquent, il peut rester vide lorsqu’il est absent.

Stockage du déclencheur

Remarque :

Il s’agit d’un exemple spécifique de diverses implémentations possibles.

Cet exemple de code JS enregistre le déclencheur dans la base de données.

function processPipelineMessage(xmlTrigger)
 {
 (…)
 var event = 
 <pipelineEvent
 xtkschema = "cus:pipelineEvent"
 _operation = "insert"
 created = {timeNow}
 lastModified = {timeNow}
 triggerType = {triggerType}
 timeGMT = {timeGMT}
 shopper_id = {shopper_id}
 data = {xmlTrigger.toXMLString()}
 />
 xtk.session.Write(event)
 return <undef/>; 
 }

Contraintes

Les performances de ce code doivent être optimales car il s’exécute à hautes fréquences. Il existe des effets négatifs potentiels pour d’autres activités marketing. Surtout si plus d’un million d’événements sont traités par heure sur le serveur marketing. Ou s’il n’est pas correctement identifiable.

Le contexte de ce JavaScript est limité. Toutes les fonctions de l’API ne sont pas disponibles. Par exemple, getOption() ou getCurrentdate() ne fonctionne pas. 

Pour accélérer le traitement, plusieurs threads de ce script sont exécutés simultanément. Le code doit être sécurisé.

Stockage des événements

Remarque :

Il s’agit d’un exemple spécifique de diverses implémentations possibles.

Schéma d’événement de pipeline

Les événements sont stockés dans une table de base de données. Elle est utilisée par les campagnes marketing pour cibler les clients et enrichir les courriers électroniques à l’aide de déclencheurs.
Bien que chaque déclencheur puisse avoir une structure de données distincte, tous les déclencheurs peuvent être conservés dans une même table. 
Le champ triggerType identifie de quel déclencheur viennent les données.

Voici un exemple de code de schéma pour ce tableau :

Attribut Saisissez Libellé Description
pipelineEventId Longue Clé primaire La clé primaire interne du déclencheur.
data Mémo Déclencher les données Contenu intégral des données de déclenchement au format XML. Pour les opérations de débogage et de contrôle.
triggerType Chaîne 50 TriggerType Nom du déclencheur. Identifie le comportement du client sur le site Web.
shopper_id Chaîne 32 shopper_id Identifiant interne du consommateur. Défini par le flux de travail de réconciliation. Si la valeur est zéro, cela signifie que le client est inconnu dans la campagne.
shopper_key Longue shopper_key Identifiant externe du consommateur tel que capturé par Analytics.
créé Heuredate Créé Heure à laquelle l’événement a été créé dans la campagne.
lastModified Heuredate Dernière modification La dernière fois que l’événement a été modifié dans Adobe.
timeGMT Heuredate Horodatage Heure à laquelle l’événement a été généré dans Analytics.

Affichage des événements

Les événements peuvent être affichés avec un formulaire simple basé sur le schéma d’événements.

image2017-1-13 18_8_3 blur

Traitement des événements

Flux de production Reconciliation

La Réconciliation est le processus de correspondance du client à partir de Analytics dans la base de données de Campaign. Par exemple, les critères de correspondance peuvent correspondre à shopper_id.

Pour des raisons de performances, la correspondance doit être effectuée en mode par lots par un flux de production. 
La fréquence des retours est fixée à 15 minutes pour optimiser la charge de travail. Par conséquent, le délai entre la réception d’événements dans Adobe Campaign et son traitement par un flux marketing va jusqu’à 15 minutes.

Options de transcodage d’unité dans JS

En théorie, il est possible d’exécuter la requête de certification pour chaque déclencheur dans le JS. Les performances sont élevées et les résultats sont plus rapides. Cela peut être nécessaire pour des cas d’utilisation spécifiques lorsque de la réactivité est nécessaire. 

Il peut être difficile de le faire si aucun index n’est défini sur shopper_id. Si les critères se trouvent sur un serveur de base de données distinct du serveur marketing, il utilise un lien de base de données dont les performances sont médiocres.

Effacer le flux de production

Les déclencheurs sont traités dans l’heure, de sorte qu’il n’y a pas de raison de les conserver longtemps. Le volume peut être d’environ 1 million de déclencheurs par heure. Cela explique pourquoi un flux de production d’élimination doit être mis en place. L’élimination supprime tous les déclencheurs antérieurs à trois jours et exécutés une fois par jour.

Flux de travaux de campagne

Le flux de production de campagne est souvent semblable à d’autres campagnes récurrentes qui ont été utilisées.
Par exemple, il peut commencer par une requête sur les déclencheurs recherchant des événements spécifiques au cours du dernier jour. Cette cible est utilisée pour envoyer le courrier électronique. Les Enrichissements ou les données peuvent provenir du déclencheur. Il peut être utilisé en toute sécurité par Marketing car il ne nécessite aucune configuration.

image2017-1-13 18_13_31 blur

Surveillance du pipeline

Etat du processus de pipeline

Le service Web d’état pipelined donne des informations sur l’état du processus pipelined.

Il est accessible manuellement à l’aide d’un navigateur ou automatiquement avec une application de surveillance.

Il est au format REST, décrit ci-dessous.

image2017-1-10 17-2-30

indicateurs

Cette section répertorie les indicateurs du service Web d’état.
Les indicateurs recommandés pour la surveillance sont mis en surbrillance.

  • Consommateur : nom du client qui récupère les déclencheurs. Configuré dans l’option de pipeline.
  • requête http
    • last-alive-ms-ago : durée en ms, depuis qu’une vérification de connexion a été effectuée.
    • last-failed-cnx-ms-ago : temps en ms depuis le dernier échec de la vérification de connexion.
    • pipeline-host : nom de l’hôte dans lequel les données de pipeline sont extraites.
  • pointeur de rotation
    • current-offsets : valeur du pointeur dans le pipeline, par thread enfant.
    • last-flush-ms-ago : durée en ms, depuis qu’un lot de déclencheurs a été extrait.
    • next-offsets-flush : délai d’attente jusqu’au prochain lot, lorsque terminé.
    • processed-since-last-flush : nombre de déclencheurs traités dans le dernier lot.
  • routage
    • déclencheurs : liste des déclencheurs récupérés. configuré dans l’option pipelined.
  • stats
    • average-pointer-flush-time-ms : durée de traitement moyenne pour un lot de déclencheurs.
    • average-trigger-processing-time-ms : durée moyenne passée lors de l’analyse des données de déclencheurs.
    • bytes-read : nombre d’octets lus depuis la file d’attente depuis le démarrage du processus.
    • current-messages : nombre actuel de messages en attente qui ont été extraits de la file d’attente et attendent le traitement. Cet indicateur doit être proche de zéro.
    • current-retries : nombre actuel de messages dont le traitement a échoué et qui sont en attente d’acceptation.
    • peak-messages : nombre maximal de messages en attente que le processus a pu traiter depuis son lancement.
    • pointer-flushes : nombre de lots de messages traités depuis le début.
    • routing-JS-custom : nombre de messages traités par le JS personnalisé.
    • trigger-discarded : nombre de messages supprimés après trop de tentatives en raison des erreurs de traitement.
    • trigger-processed : nombre de messages traités sans erreur.
    • trigger-received : nombre de messages reçus de la file d’attente.

Ces stats sont affichés par thread de traitement.

  • average-trigger-processing-time-ms : durée moyenne passée lors de l’analyse des données de déclencheurs.
  • is-JS-processor : valeur « 1 » si ce thread utilise le JS personnalisé.
  • trigger-discarded : nombre de messages supprimés après trop de tentatives en raison des erreurs de traitement. Cet indicateur doit être défini sur zéro.
  • trigger-failures : nombre d’erreurs de traitement dans le JS. Cet indicateur doit être défini sur zéro.
  • trigger-received : nombre de messages reçus de la file d’attente. 

 

  • Paramètres : ils sont définis dans les fichiers de configuration.
    • flush-pointer-msg-count : nombre de messages dans un lot.
    • flush-pointer-period-ms : délai entre deux lots, en millisecondes.
    • processing-threads-JS : nombre de threads de traitement exécutant le JS personnalisé.
    • retry-period-ms : délai entre deux tentatives lorsqu’une erreur de traitement se produit.
    • retry-validity-duration-ms : la durée à partir du moment où le traitement est retenté jusqu’à ce que le message soit supprimé.

Rapport sur les messages de pipeline

Ce rapport affiche le nombre de messages par heure dans les cinq derniers jours.

image2017-1-10 17-3-10

Dépannage de pipeline

Pipelined échoue avec l’erreur « Aucune tâche ne correspond au masque pipelined@ »

Votre version d’AC ne prend pas en charge le pipeline.

  1. Vérifiez si l’élément pipelined est présent dans le fichier de configuration. Dans le cas contraire, elle n’est pas prise en charge.
  2. Mise à niveau vers la version 6,11 génération 8705 ou version ultérieure.

Pipelined échoue avec « aurait dû commencer par »[' ou '{' (iRc=16384)"

L’option NmsPipeline_Config n’est pas définie. Il s’agit en fait d’une erreur d’analyse JSON.
Définissez la configuration JSON dans l’option NmsPipeline_Config. Voir « Option de routage » dans cette page.

Pipeline échoue avec « la rubrique doit être une organisation ou un client valide »

La configuration IMSOrgid n’est pas valide.

  1. Vérifiez que l’IMSOrgId est défini dans serverConf.xml.
  2. Recherchez un objet IMSOrgId vide dans le fichier de configuration de l’occurrence qui peut remplacer la valeur par défaut. Si tel est le cas, supprimez-le.
  3. Vérifiez que le IMSOrgId correspond à celui du client dans l’Experience Cloud. 

Pipelined échoue avec « clé non valide »

Le paramètre @authPrivateKey du fichier de configuration de l’occurrence est incorrect.

  1. Vérifiez que authPrivateKey est défini.
  2. Vérifiez que le authPrivateKey : commence par @, se termine par = et est d’environ 2600 caractères.
  3. Recherchez la clé d’origine et vérifiez qu’elle est : dans le format de RSA, 4096 bits et commence par ? -----BEGIN RSA PRIVATE KEY-----
    Si nécessaire, recréez la clé et enregistrez-la sur Adobe Developer Connection.
  4. Vérifiez que la clé a été codée au sein de la même instance que pipelined.
    Le cas échéant, rétablissez le codage à l’aide de l’échantillon JavaScript ou flux de production..

Pipelined échoue avec « impossible de lire le jeton lors de l’authentification »

Format de la clé privée non valide.

  1. Exécutez les étapes du chiffrement clé sur cette page.
  2. Vérifiez que la clé est chiffrée sur la même instance.
  3. Vérifiez que l’authPrivateKey du fichier de configuration correspond à la clé générée.
    Veillez à utiliser la OpenSSL pour générer la paire de clés. Par exemple, PuttyGen ne génère pas le format correct.

Aucun déclencheur n’est recherché

Lorsque le processus de pipelined est en cours d’exécution et qu’aucun déclencheur n’est récupéré :

  1. Assurez-vous que le déclencheur est actif dans Analytics et qu’il génère des événements.
  2. Assurez-vous que le processus de pipelined est en cours d’exécution.
  3. Recherchez les erreurs dans le journal pipelined.
  4. Recherchez des erreurs dans la page d’état pipelined. trigger-discarted, trigger-failures doit être zéro.
  5. Vérifiez que le nom de déclencheur est configuré dans l’option NmsPipeline_Config. En cas de doute, utilisez l’option de caractère générique.
  6. Vérifiez que l’option Analytics a un déclencheur actif et qu’il génère des événements. Il peut y avoir un délai quelques heures après l’exécution de la configuration dans Analytics avant l’activation.

Les événements ne sont pas associés à un client

Lorsque certains événements ne sont pas liés à un client :

  1. Vérifiez que le flux de tâches de certification est en cours d’exécution, le cas échéant.
  2. Vérifiez que l’événement contient un identifiant client.
  3. Créez une requête sur le tableau clientèle à l’aide de l’identifiant client.
  4. Vérifiez la fréquence de l’importation du client. Les nouveaux clients sont importés dans Adobe Campaign avec un flux de production.

Retard dans le traitement des événements

Lorsque l’horodatage d’Analytics est plus ancien que la date de création de l’événement dans Campaign.

La latence normale est de moins de 15 minutes. 

  1. Vérifiez si le processus de pipelined a été exécuté.
  2. Recherchez des erreurs dans pipelined.log qui peuvent entraîner des tentatives. Corrigez les erreurs, le cas échéant.
  3. Vérifiez la taille de la file d’attente sur la page de statut. Si la taille de la file d’attente est importante, améliorez les performances de JS.
  4. Dans la mesure où un délai semble augmenter avec le volume, configurez les déclencheurs sur Analytics en utilisant moins de messages.

Annexes

Comment utiliser le code JavaScript de chiffrement de clés

Exécutez un script JavaScript pour chiffrer la clé privée. Il est nécessaire pour la configuration du pipeline.

Voici un exemple de code que vous pouvez utiliser pour exécuter la fonction cryptString :

/*
USAGE:
  nlserver javascript -instance:<instancename> -file -arg:"<private_key.pem file>" -file encryptKey.js
*/

function usage()
{
  return "USAGE:\n" +
    '  nlserver javascript -instance:<instancename> -file -arg:"<private_key.pem file>" -file encryptKey.js\n'
}

var fn = application.arg;
if( fn == "" )
  logError("Missing key file file\n" + usage());

//open the pem file
plaintext = loadFile(fn)

if( !plaintext.match(/^-----BEGIN RSA PRIVATE KEY-----/) )
  logError("File should be an rsa private key")

logInfo("Encrypted key:\n" + cryptString(plaintext))

Sur le serveur, exécutez JavaScript :

nlserver javascript -instance:<instancename> -file -arg:"<private_key.pem file>" -file encryptKey.js

Copiez et collez la clé codée de la sortie vers la console.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne