Triggers ist eine Integration zwischen Adobe Campaign und Adobe Analytics unter Verwendung der Pipeline. Die Pipeline ruft Aktionen oder Trigger der Benutzer von Ihrer Website ab. Der Abbruch einer Einkaufsaktivität ist ein Beispiel für einen Trigger. Trigger werden in Adobe Campaign verarbeitet, um E-Mails fast in Echtzeit senden zu können.
Übersicht Dieses Dokument beschreibt die Komponenten, aus denen die Integration in Adobe Campaign besteht. Außerdem wird beschrieben, wie häufig auftretende Probleme und Konfigurationen behoben werden. 
Lösung Adobe Campaign Classic (v6.11, v7)
Zielgruppe Administratoren, Fortgeschrittene Benutzer

Wenn Sie Fragen zu diesem Artikel oder einem anderen Adobe Campaign-Thema haben, wenden Sie sich an die Community.

Übersicht

Nach einer Handlung des Benutzers führen Trigger innerhalb kurzer Zeit Marketing-Aktionen aus. Die typische Reaktionszeit liegt bei weniger als einer Stunde.

Dies ermöglicht eine flexiblere Integration, da die Konfiguration minimal ist und Dritte nicht beteiligt sind.
Es unterstützt auch hohe Datenvolumen, ohne die Leistung von Marketing-Aktivitäten zu beeinträchtigen. Beispielsweise kann die Integration eine Million Trigger pro Stunde verarbeiten.

Architektur

Was ist Pipeline?

Pipeline ist ein Meldungssystem, das in der Experience Cloud gehostet wird, welches Apache Kafka verwendet. Es ist eine Möglichkeit, mühelos Daten zwischen Lösungen zu übergeben. Darüber hinaus ist Pipeline keine Datenbank, sondern eine Nachrichtenwarteschlange. Produzenten stellen Ereignisse in die Pipeline, während die Konsumenten auf den Fluss hören und mit dem Ereignis machen, was sie wollen. Ereignisse werden einige Tage lang aufbewahrt, aber nicht länger. Der Zweck ist es, immer zuzuhören und Ereignisse sofort zu verarbeiten.

Picture1

Wie funktioniert Pipeline?

Der durch die Pipeline geleitete Prozess wird immer auf dem Adobe Campaign-Marketingserver ausgeführt. Er stellt eine Verbindung mit der Pipeline her, ruft die Ereignisse ab und verarbeitet sie sofort. 

Picture2

Der durch die Pipeline geleitete Prozess meldet sich bei Experience Cloud mithilfe eines Authentifizierungsdienstes an und sendet einen persönlichen Schlüssel. Der Authentifizierungsdienst gibt ein Token zurück. Das Token wird zum Authentifizieren der Ereignisse verwendet. Trigger werden von einem REST-Webdienst mithilfe einer einfachen GET-Anforderung abgerufen. Die Antwort liegt im JSON-Format vor. Zu den Parametern der Anforderung gehören der Name des Triggers und ein Zeiger, der die letzte abgerufene Nachricht angibt. Der durch die Pipeline geleitete Prozess verarbeitet ihn automatisch.

Verwendung

Hinweis:

Es handelt sich um ein bestimmtes Beispiel aus verschiedenen möglichen Implementierungen.

Die Pipeline-Ereignisse werden automatisch heruntergeladen. Diese Ereignisse können mithilfe eines Formulars überwacht werden.

image2017-1-13 18_8_3 blur

Ein wiederkehrender Kampagnen-Workflow führt eine Abfrage von Triggern durch. Wenn diese den Marketing-Kriterien entsprechen, wird eine Auslieferung gestartet.

image2017-1-13 18_13_31 blur

Pipeline-Konfiguration

Übersicht

Authentifizierungsparameter wie der Benutzername des Kunden, der private Schlüssel und der Authentifizierungsendpunkt werden in den Instanzkonfigurationsdateien konfiguriert.
Die zu verarbeitende Liste der Trigger ist in einer Option konfiguriert. Sie liegt im JSON-Format vor.

Der Trigger wird sofort mithilfe von JavaScript-Code verarbeitet. Die Datei wird in einer Datenbanktabelle gespeichert, ohne dass sie in Echtzeit weiterverarbeitet wird.
Die Trigger werden von einem Kampagnen-Workflow, der E-Mails sendet, zum Targeting verwendet. Die Kampagne wird so eingerichtet, dass ein Kunde, der über beide Trigger-Ereignisse verfügt, eine E-Mail erhält.

Voraussetzungen

Die Verwendung von Experience Cloud Triggers in Campaign erfordert:

  • Adobe Campaign-Version 6.11, Build 8705 oder neuer.
  • Adobe Analytics Ultimate, Premium, Foundation, OD, Select, Prime, Mobile Apps, Select oder Standard.

Vorausgesetzte Konfigurationen sind:

  • Erstellen einer privaten Schlüsseldatei und anschließendes Erstellen der oAuth-Applikation, die mit diesem Schlüssel registriert ist.
  • Konfiguration der Trigger in Adobe Analytics.

Die Adobe Analytics-Konfiguration liegt außerhalb des Anwendungsbereichs dieses Dokuments. 
Adobe Campaign erfordert die folgenden Informationen von Adobe Analytics:

  • Der Name der oAuth-Anwendung.
  • Die IMSOrgId. Es ist die Kennung des Experience Cloud-Kunden.
  • Die Namen der in Analytics konfigurierten Trigger.
  • Der Name und das Format der Datenfelder, die mit der Marketing-Datenbank abgeglichen werden sollen.

Hinweis:

Teil dieser Konfiguration ist eine benutzerdefinierte Entwicklung. Sie erfordert Folgendes:

  • Ausreichende Kenntnisse über JSON-, XML- und JavaScript-Parsing in Adobe Campaign.
  • Kenntnisse der QueryDef- und Writer-APIs.
  • Kenntnisse der Verschlüsselung und Authentifizierung mit persönlichen Schlüsseln.

Da die Bearbeitung des JS-Codes technische Fähigkeiten erfordert, versuchen Sie es nicht ohne die richtigen Kenntnisse.

Trigger werden in einer Datenbanktabelle gespeichert. Somit können Trigger-Daten von Marketing-Operatoren in Targeting-Workflows sicher verwendet werden.

Authentifizierung und Konfigurationsdateien

Die Authentifizierung ist erforderlich, da Pipeline in der Adobe Experience Cloud gehostet wird.
Wenn der Marketing-Server vor Ort gehostet wird, muss er sich bei der Anmeldung bei Pipeline authentifizieren, um eine sichere Verbindung zu haben.
Es verwendet ein Paar von öffentlichen und privaten Schlüsseln. Dieser Vorgang ist dieselbe Funktion wie ein Benutzer/Kennwort, nur sicherer.

„IMSOrgId“

Die „IMSOrgId“ ist die Kennung des Kunden auf der Adobe Experience Cloud.
Legen Sie ihn in der Dateiinstanz „serverConf.xml“ unter dem „IMSOrgId“-Attribut fest.

Beispiel:

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

Schlüsselgeneration

Der Schlüssel ist ein Dateienpaar. Er liegt im RSA-Format vor und hat eine Größe von 4.096 Bytes. Es kann mit einem Open-Source-Tool wie OpenSSL erzeugt werden. Bei jedem Ausführen des Tools wird ein neuer Schlüssel zufällig generiert.

Der Einfachheit halber werden die Schritte hierfür im Folgenden angezeigt:

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

Beispiel für eine „private_key.pem“-Datei:

 

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

 Beispiel für eine „public_key.pem“-Datei:

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

Hinweis:

Schlüssel sollten nicht von PuttyGen generiert werden, OpenSSL ist die beste Wahl.

oAuth-Client-Erstellung in Adobe Experience Cloud

Eine Anwendung des Typs JWT muss erstellt werden, indem Sie sich bei Adobe Developer Connection anmelden und die folgenden Schritte ausführen:

  1. Wählen Sie das Dienstkonto (JWT Assertion).
  2. Geben Sie den Anwendungsnamen ein.
  3. Registrieren Sie den öffentlichen Schlüssel.
  4. Wählen Sie die Organisation (Administrator-Konto ist obligatorisch).
  5. Wählen Sie die Trigger-Reichweite aus.
worddav742582ccac2fe4e5078ee2804a38addf

Konfiguration der Anwendungs-ID in Adobe Campaign

Die Anwendungs-ID des erstellten oAuth-Clients muss in Adobe Campaign konfiguriert werden. Sie können dies tun, indem Sie die Instanzkonfigurationsdatei im Pipeline-Element bearbeiten, genauer gesagt das appName-Attribut.

Beispiel:

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

Schlüssel-Codierung

Der private Schlüssel muss verschlüsselt sein, um vom Pipeline-Element verwendet zu werden.
Die Verschlüsselung erfolgt mit der JavaScript-Funktion „cryptString“.
Sie muss in der gleichen Instanz wie die Pipeline ausgeführt werden. 
Ein Beispiel für die Codierung eines privatem Schlüssel mit JavaScript finden Sie in den Anhängen.

Schlüsselregistrierung in Adobe Campaign

Der codierte private Schlüssel muss in Adobe Campaign registriert sein. Sie können dies tun, indem Sie die Instanzkonfigurationsdatei im Pipeline-Element bearbeiten, speziell das Attribut „authPrivateKey“.

Beispiel:

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

Pipeline-Prozess startet automatisch

Der durch Pipeline geleitete Prozess muss automatisch gestartet werden.

Setzen Sie dazu das Element in der Konfigurationsdatei auf autostart="true":

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

Neustart des Pipeline-Prozesses

Es kann auch über folgende Befehlszeile manuell gestartet werden:
nlserver start pipelined@instance

Ein Neustart ist erforderlich, damit die Änderungen wirksam werden:
nlserver restart pipelined@instance

Im Falle von Fehlern

Suchen Sie nach Fehlern in der Standardausgabe (wenn manuell gestartet) oder in der Pipeline-Protokolldatei. Weitere Informationen zum Beheben von Problemen finden Sie im Abschnitt Fehlerbehebung in diesem Dokument.

Pipeline-Konfigurationsoptionen

Option Beschreibung
appName Die ID der OAuth-Anwendung, die in Adobe Developer Connection registriert ist (wo der öffentliche Schlüssel hochgeladen wurde).
Siehe https://marketing.adobe.com/developer/de/documentation/authentication-1/auth-service-account-1
authGatewayEndpoint URL zum Abrufen von „gateway tokens“. Standard: https://api.omniture.com
authPrivateKey Der private Schlüssel (öffentlicher Schlüssel wurde in Adobe Developer Connection hochgeladen) ist mit der XtkKey-Option AES-verschlüsselt:
„cryptString“ („PRIVATE_KEY“)
disableAuth Deaktivieren der Authentifizierung (die Verbindung ohne Gateway-Token wird nur von einigen Entwicklungsendpunkten der Pipeline akzeptiert)
discoverPipelineEndpoint URL, um den Pipeline-Endpoint zu erkennen, der für diesen Mandanten verwendet werden soll. Standard: https://producer-pipeline-pnw.adobe.net
dumpStatePeriodSec Zeitraum zwischen 2 Speicherauszügen des prozessinternen Status in „var/INSTANCE/pipelined.json. Der interne Status ist auch bei Verlangen unter „http://INSTANCE:7781/pipelined/status“ verfügbar.
forcedPipelineEndpoint Deaktivieren der Suche nach PipelineServicesEndpoint und Erzwingen der Funktion
monitorServerPort Der durch die Pipeline geleitete Prozess überwacht diesen Port, um den internen Status unter „http://INSTANCE:PORT/pipelined/status“ bereitzustellen. Der Standard ist 7781
pointerFlushMessageCount Wenn diese Anzahl von Nachrichten verarbeitet wird, werden die Offsets in der Datenbank gespeichert. Der Standard ist 1.000
pointerFlushPeriodSec Danach werden die Offsets in der Datenbank gespeichert. Der Standardwert ist 5 (Sek.)
processingJSThreads Anzahl der dedizierten Threads, die Meldungen mit benutzerdefinierten „JS-Connectors“ verarbeiten. Der Standard ist 4
processingThreads Anzahl der dedizierten Threads, die Nachrichten mit integriertem Code verarbeiten. Der Standard ist 4
retryPeriodSec Verzögerung zwischen den Wiederholungen (wenn Verarbeitungsfehler vorliegen). Der Standardwert ist 30 (Sek.)
retryValiditySec Nachricht verwerfen, wenn sie nach diesem Zeitraum nicht erfolgreich verarbeitet wurde (zu viele Versuche). Der Standardwert ist 300 (Sek.)

Pipeline-Option „NmsPipeline_Config“

Sobald die Authentifizierung funktioniert, kann die Pipeline die Ereignisse abrufen und verarbeiten. Sie verarbeitet nur Trigger, die in Adobe Campaign konfiguriert sind, und ignoriert alle anderen. Der Trigger muss von Analytics generiert und vorher an die Pipeline gesendet worden sein.
Die Option kann auch mit einem Platzhalter konfiguriert werden, um alle Trigger unabhängig vom Namen zu erfassen.
Die Konfiguration der Trigger erfolgt in einer Option unter „Administration“ -> „Platform“ -> „Options“. Der Name der Option ist „NmsPipeline_Config“. Der Datentyp ist „long text“. Die Datei liegt im JSON-Format vor.

Beispiel 1

In diesem Beispiel werden zwei Trigger angegeben.

Fügen Sie den JSON-Code aus dieser Vorlage in den Optionswert ein. Stellen Sie sicher, dass Sie Kommentare entfernen.

{
	"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.
				},
			]
		}
	]
}

Beispiel 2

In diesem Beispiel werden alle Trigger erfasst.

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

Hinweis:

Der Trigger-UID-Wert für einen bestimmten Triggernamen in der Analytics-Oberfläche kann innerhalb der URL-Querystring-Parameter in der Triggers-Schnittstelle gefunden werden. Die „triggerType“-UID wird in den Pipeline-Datenstrom übergeben und Code kann in „pipeline.JS“ geschrieben werden, um die Trigger-UID einer benutzerfreundlichen Bezeichnung zuzuordnen, die in der Trigger-Namenspalte im „pipelineEvents“-Schema gespeichert werden kann.

Der Benutzerparameter

Die Pipeline arbeitet mit einem „Hersteller und Benutzer“-Modell. Es kann viele Benutzer in der gleichen Warteschlange geben. Nachrichten werden nur für einen einzelnen Benutzer „konsumiert“. Jeder Benutzer erhält seine eigene „Kopie“ der Nachrichten.


Der „consumer“-Parameter identifiziert die Instanz als einen dieser Benutzer. Es handelt sich um die Identität der Instanz, die die Pipeline aufruft. Sie können sie mit dem Instanznamen füllen. Der Pipeline-Dienst verfolgt die Nachrichten, die von jedem Benutzer abgerufen werden. Die Verwendung verschiedener Konsumenten für verschiedene Instanzen stellt sicher, dass jede Nachricht an jede Instanz gesendet wird.

So konfigurieren Sie die Pipeline-Option

Hinzufügen oder Bearbeiten von Experience Cloud Triggers im „Trigger“-Bereich; Editieren Sie nicht den Rest.
Stellen Sie sicher, dass der JSON gültig ist. Diese Website kann helfen: http://jsonlint.com/

  • „name“ ist die Trigger-Kennung. Der Platzhalter „*“ erfasst alle Trigger.
  • „Consumer“ ist eine eindeutige Zeichenfolge, die die „nlserver“-Instanz eindeutig identifiziert. Normalerweise kann es der Name der Instanz selbst sein. Stellen Sie bei mehreren Umgebungen (dev/stage/prod) sicher, dass alle eindeutig sind, sodass jede Instanz eine Kopie der Nachricht erhält.
  • Der Pipeline-Prozess unterstützt auch das Thema „aliases“.

Starten Sie den Pipeline-Prozess neu, nachdem Sie Änderungen vorgenommen haben.

Verarbeiten von Ereignissen

Verarbeiten von Ereignissen in JavaScript

JS-Datei

Pipeline verwendet eine JavaScript-Funktion zum Verarbeiten jeder Meldung. Diese Funktion ist benutzerdefiniert.

Sie wird in der Option NmsPipeline_Config unter dem Attribut „JSConnector“ konfiguriert. Dieses JavaScript wird jedes Mal aufgerufen, wenn ein Ereignis empfangen wird. Es wird vom Pipeline-Prozess ausgeführt.

Die JS-Beispieldatei lautet „cus:triggers.js“.

JS-Funktion

Das Pipeline-JavaScript muss mit einer spezifischen Funktion beginnen.

Diese Funktion wird einmal für jedes Ereignis aufgerufen:

    function processPipelineMessage(xmlTrigger) {}

Es sollte <undefined/> zurückgeben.

Starten Sie den Pipeline-Prozess nach der Bearbeitung des JS neu.

Trigger-Datenformat

Die Trigger-Daten werden an die JS-Funktion übergeben. Es liegt im XML-Format vor.

  • Das Attribut „@triggerId“ enthält den Namen des Triggers.
  • Das Element „enrichments“ enthält die von Analytics generierten Daten und ist an den Trigger angehängt. Die Datei liegt im JSON-Format vor.
  • „@offset“ ist der „Zeiger“ auf die Meldung. Er gibt die Reihenfolge der Meldung in der Warteschlange an.
  • „@partition“ ist ein Container mit Nachrichten innerhalb der Warteschlange. Das Offset ist relativ zu einer Partition. Es gibt etwa 15 Partitionen in der Warteschlange.

Beispiel:

<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>

Enrichment-Datenformat

Hinweis:

Es handelt sich um ein bestimmtes Beispiel aus verschiedenen möglichen Implementierungen.

Der Inhalt wird in Analytics für jeden Trigger definiert. Die Datei liegt im JSON-Format vor.
Zum Beispiel: In einem Trigger „LogoUpload_uploading_Visits“:

  • „eVar01“ kann die Käufer-ID enthalten, die zur Abstimmung mit Campaign-Empfängern verwendet wird. Es liegt im String-Format vor. Sie muss für die Suche nach der Käufer-Kennung, die den Primärschlüssel darstellt, berichtigt werden.
  • „timeGMT“ kann die Zeit des Triggers auf der Analytics-Seite enthalten. Es ist im UTC-Epochenformat (d.h. Sekunden seit 01/01/1970 UTC).

Beispiel:

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

Reihenfolge der Ereignisverarbeitung

Die Ereignisse werden einzeln nacheinander verarbeitet, in der Reihenfolge der Offsets. Jeder Thread der Pipeline verarbeitet eine andere Partition.

Das „offset“ des letzten abgerufenen Ereignisses wird in der Datenbank gespeichert. Wenn der Prozess beendet wurde, wird er daher von der letzten Nachricht aus neu gestartet. Diese Daten werden im integrierten Schema „xtk:pipelineOffset“ gespeichert.

Dieser Zeiger ist für jede Instanz und jeden Verbraucher spezifisch. Wenn also viele Instanzen auf dieselbe Pipeline mit verschiedenen Benutzern zugreifen, erhalten sie alle jede Nachricht und in derselben Reihenfolge.

Der „consumer“-Parameter der Pipeline-Option identifiziert die aufrufende Instanz. 

Derzeit gibt es keine Möglichkeit, verschiedene Warteschlangen für separate Umgebungen wie „Test“ oder „dev“ zu haben.

Protokollierung und Umgang mit Fehlern

Protokolle wie „logInfo()“ werden an das Pipeline-Protokoll geleitet. Fehler wie „logError()“ werden in das Pipeline-Protokoll geschrieben und bewirken, dass das Ereignis in eine wiederholte Warteschlange versetzt wird.
Fehlerhafte Nachrichten werden solange mehrmals wiederholt, wie es in den Pipeline-Optionen festgelegt ist.
Für das Debuggen und Überwachen werden die vollständigen Triggerdaten in die Triggertabelle geschrieben. Sie befindet sich im „Daten“-Feld im XML-Format. Alternativ dazu dient ein „logInfo()“, der die Trigger-Daten enthält, dem gleichen Zweck.

Datenanalyse

Dieser JS-Beispielcode analysiert das „eVar01“ in den „enrichments“.

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]
 }
 }
 (…)
 }

Seien Sie vorsichtig beim Analysieren, um Fehler zu vermeiden.
Da dieser Code wird für alle Trigger verwendet wird, sind die meisten Daten nicht erforderlich. Daher kann es leer gelassen werden, wenn es nicht vorhanden ist.

Speichern des Triggers

Hinweis:

Es handelt sich um ein bestimmtes Beispiel aus verschiedenen, möglichen Implementierungen.

Dieser JS-Beispielcode speichert den Trigger in der Datenbank.

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/>; 
 }

Einschränkungen

Die Leistung für diesen Code muss optimal sein, da er bei hohen Frequenzen ausgeführt wird. Es gibt potenzielle negative Effekte für andere Marketing-Aktivitäten. Insbesondere bei der Verarbeitung von mehr als einer Million Trigger-Ereignissen pro Stunde auf dem Marketing-Server. Oder wenn er nicht richtig ausgerichtet ist.

Der Kontext dieses JavaScripts ist begrenzt. Nicht alle Funktionen der API sind verfügbar. Beispielsweise funktionieren „getOption()“ oder „getCurrentdate()“ nicht. 

Um eine schnellere Verarbeitung zu ermöglichen, werden mehrere Threads dieses Skripts gleichzeitig ausgeführt. Der Code muss Thread-sicher sein.

Speichern der Ereignisse

Hinweis:

Es handelt sich um ein bestimmtes Beispiel aus verschiedenen möglichen Implementierungen.

Schema der Pipeline-Ereignisse

Ereignisse werden in einer Datenbanktabelle gespeichert. Sie wird von Marketing-Kampagnen verwendet, um Kunden anzusprechen und E-Mails mithilfe von Triggern zu verbessern.
Obwohl jeder Trigger eine unterschiedliche Datenstruktur haben kann, können alle Trigger in einer einzigen Tabelle aufgeführt werden. 
Das „triggerType“-Feld identifiziert, von welchem Trigger die Daten stammen.

Hier ein Schema-Beispielcode für diese Tabelle:

Attribut Geben Sie Kennzeichnung Beschreibung
pipelineEventId Lang Primärschlüssel Der interne Primärschlüssel des Triggers.
data Memo Triggerdaten Der vollständige Inhalt der Triggerdaten liegt im XML-Format vor. Für Debugging- und Audit-Zwecke.
triggerType Zeichenfolge 50 TriggerType Der Name des Triggers. Identifiziert das Verhalten des Kunden auf der Website.
shopper_id Zeichenfolge 32 shopper_id Die interne Kennung des Kunden. Wird vom Abgleichsworkflow festgelegt. Bei null bedeutet dies, dass der Kunde in der Kampagne unbekannt ist.
shopper_key Lang shopper_key Die externe Kennung des Kunden, die von Analytics erfasst wurde.
erstellt Datetime Erstellt am Die Zeit, zu der das Ereignis in der Kampagne erstellt wurde.
lastModified Datetime Letzte Änderung Das letzte Mal, als das Ereignis in Adobe geändert wurde.
timeGMT Datetime Zeiteintrag Die Zeit, zu der das Ereignis in Analytics generiert wurde.

Anzeigen der Ereignisse

Die Ereignisse können basierend auf dem Ereignisschema in einem einfachen Formular angezeigt werden.

image2017-1-13 18_8_3 blur

Verarbeiten der Ereignisse

Abgleichsworkflow

„Reconciliation“ ist der Abgleich des Kunden aus Analytics in Campaign-Datenbank. Zum Beispiel können die Kriterien für den Abgleich die „shopper_id“ sein.

Aus Leistungsgründen muss der Abgleich im Batch-Modus von einem Arbeitsablauf durchgeführt werden. 
Die Frequenz muss auf 15 Minuten eingestellt werden, um die Arbeitsbelastung zu optimieren. Die Verzögerung zwischen einem Ereignisempfang in Adobe Campaign und der Verarbeitung durch einen Marketing-Arbeitsablauf beträgt daher bis zu 15 Minuten.

Optionen für den Einheitenabgleich in JS

Theoretisch ist es möglich, die Abgleichsabfrage für jeden Trigger im JS auszuführen. Dies hat eine höhere Leistung und liefert schnellere Ergebnisse. Es könnte für bestimmte Anwendungsfälle erforderlich sein, wenn Reaktivität benötigt wird. 

Dies kann schwierig sein, wenn auf „shopper_id“ kein Index gesetzt ist. Wenn sich die Kriterien auf einem anderen Datenbankserver als dem Marketing-Server befinden, wird eine Datenbankverbindung verwendet, die eine schlechte Leistung aufweist.

Bereinigungs-Workflow

Trigger werden innerhalb einer Stunde verarbeitet, so dass es keinen Grund gibt, sie für eine lange Zeit zu behalten. Das Volumen kann ungefähr 1 Million Trigger pro Stunde betragen. Dies erklärt, warum ein Bereinigungs-Workflow eingerichtet werden muss. Die Bereinigung löscht alle Trigger, die älter als drei Tage sind. Sie wird einmal pro Tag ausgeführt.

Kampagnen-Workflow

Der Arbeitsablauf des Triggers für die Kampagne ähnelt häufig anderen wiederkehrenden Kampagnen, die verwendet wurden.
Sie können sie zum Beispiel mit einer Abfrage auf die Trigger beginnen, die nach bestimmten Ereignissen während des letzten Tages suchen. Dieses Ziel wird zum Senden der E-Mail verwendet. „Enrichments“ oder Daten können aus dem Trigger stammen. Es kann vom Marketing sicher verwendet werden, da es keine Konfiguration erfordert.

image2017-1-13 18_13_31 blur

Pipeline-Überwachung

Pipeline-Prozessstatus

Der Status-Webdienst der Pipeline gibt Informationen zum Status des Pipeline-Prozesses.

Der Zugriff kann manuell über einen Browser oder automatisch mit einer Überwachungsapplikation erfolgen.

Es liegt im REST-Format vor, das unten beschrieben wird.

image2017-1-10 17-2-30

Kennzeichen

In diesem Abschnitt werden die Indikatoren im Status-Webservice aufgelistet.
Die Indikatoren, deren Überwachung empfohlen wird, werden hervorgehoben.

  • Benutzer: Name des Kunden, der die Trigger auslöst. Wird in der Pipeline-Option konfiguriert.
  • http-Anfrage
    • last-alive-ms-ago: Zeit in msec, seit eine Verbindungsprüfung durchgeführt wurde.
    • last-failed-cnx-ms-ago: Zeit in msec, seit die letzte Verbindungsüberprüfung fehlschlug.
    • pipeline-host: Name des Hosts, von dem die Pipeline-Daten abgerufen werden.
  • Zeiger
    • current-offsets: Wert des Zeigers in der Pipeline pro untergeordnetem Thread.
    • last-flush-ms-ago: Zeit in msec, seit ein Trigger-Batch abgerufen wurde.
    • next-offsets-flush: Zeit bis zum Ende des nächsten Batches, nach Abschluss.
    • processed-since-last-flush: Anzahl der im letzten Batch verarbeiteten Trigger.
  • Routing
    • Trigger: Liste der abgerufenen Trigger. Wird in der Pipeline-Option konfiguriert.
  • Statistiken
    • average-pointer-flush-time-ms: durchschnittliche Verarbeitungszeit für einen Batch von Triggern.
    • average-trigger-processing-time-ms: Durchschnittliche Zeit zum Analysieren der Triggerdaten.
    • bytes-read: Anzahl der in der Warteschlange gelesenen Bytes seit dem Start des Prozesses.
    • Gegenwärtige Mitteilungen: aktuelle Anzahl der ausstehenden Nachrichten, die aus der Warteschlange abgerufen wurden und auf die Verarbeitung warten. Dieser Indikator sollte nahe bei Null liegen.
    • current-retries: Aktuelle Anzahl der Nachrichten, deren Verarbeitung fehlgeschlagen ist und die auf einen erneuten Versuch warten.
    • peak-messages: Maximale Anzahl ausstehender Nachrichten, die der Prozess verarbeitet hat, seit er gestartet wurde.
    • pointer-flushes: Anzahl der Batches von Nachrichten, die seit dem Start verarbeitet wurden.
    • routing-JS-custom: Anzahl der Nachrichten, die vom benutzerdefinierten JS verarbeitet wurden.
    • trigger-discarded: Anzahl der Nachrichten, die nach zu vielen Wiederholungen aufgrund von Verarbeitungsfehlern verworfen wurden.
    • trigger-processed: Anzahl der Nachrichten, die ohne Fehler verarbeitet wurden.
    • trigger-received: Anzahl der aus der Warteschlange empfangenen Nachrichten.

Diese Statistiken werden pro Thread, der verarbeitet wird, angezeigt.

  • average-trigger-processing-time-ms: Durchschnittliche Zeit zum Analysieren der data.
  • is-JS-processor: Der Wert liegt bei „1“, wenn dieser Thread das benutzerdefinierte JS verwendet.
  • trigger-discarded: Anzahl der Nachrichten, die nach zu vielen Wiederholungen aufgrund von Verarbeitungsfehlern verworfen wurden. Diese Indikator sollte null sein.
  • Trigger-Fehler: Anzahl der Verarbeitungsfehler im JS. Dieser Indikator sollte null sein.
  • trigger-received: Anzahl der aus der Warteschlange empfangenen Meldungen. 

 

  • Einstellungen: Sie werden in den Konfigurationsdateien festgelegt.
    • flush-pointer-msg-count: Anzahl der Nachrichten in einem Batch.
    • flush-pointer-period-ms: Zeit zwischen zwei Batches in Millisekunden.
    • processing-threads-JS: Anzahl der Verarbeitungsthreads, die das benutzerdefinierte JS ausführen.
    • retry-period-ms: Zeit zwischen zwei Wiederholungen, wenn ein Verarbeitungsfehler auftritt.
    • retry-validity-duration-ms: Dauer des Zeitraums, in dem die Verarbeitung wiederholt wird, bis die Nachricht verworfen wird.

Pipeline-Nachrichten-Bericht

Dieser Bericht zeigt die Anzahl der Meldungen pro Stunde in den letzten fünf Tagen an.

image2017-1-10 17-3-10

Fehlerbehebung in Pipeline

Die Pipeline schlägt mit dem Fehler „Kein Auftrag entspricht der Maske „pipelined@“ fehl

Ihre Version von AC unterstützt die Pipeline nicht.

  1. Überprüfen Sie, ob das Pipeline-Element in der Konfigurationsdatei vorhanden ist. Ist dies nicht der Fall, wird es nicht unterstützt.
  2. Upgrade auf Version 6.11, Build 8705, oder neuer.

Pipeline scheitert mit „aurait dû commencer par '[' ou '{' (iRc=16384)“

Die Option „NmsPipeline_Config“ ist nicht festgelegt. Es handelt sich tatsächlich um einen JSON-Parsing-Fehler.
Stellen Sie die JSON-Konfiguration in der Option „NmsPipeline_Config“ ein. Siehe „routing option“ auf dieser Seite.

Pipeline schlägt mit „das Subjekt muss eine gültige Organisation oder ein Kunde sein“ fehl

Die „IMSOrgid“-Konfiguration ist nicht gültig.

  1. Überprüfen Sie, dass die „IMSOrgId“ in der „serverConf.xml“ festgelegt ist.
  2. Suchen Sie in der Konfigurationsdatei der Instanz nach einer leeren „IMSOrgId“, die den Standardwert überschreiben kann. Ist dies der Fall, entfernen Sie sie.
  3. Überprüfen Sie, ob die „IMSOrgId“ mit der des Kunden in der „Experience Cloud“ übereinstimmt. 

Pipeline schlägt mit „ungültiger Schlüssel“ fehl

Der Parameter „@authPrivateKey“ der Instanzkonfigurationsdatei ist falsch.

  1. Überprüfen Sie, ob „authPrivateKey“ festgelegt ist.
  2. Überprüfen Sie, ob der „authPrivateKey“ mit „@“ beginnt, mit „=“ endet und etwa 2.600 Zeichen lang ist.
  3. Suchen Sie nach dem ursprünglichen Schlüssel und überprüfen Sie, dass er im RSA-Format vorliegt, 4.096 Bits lang ist und mit „-----BEGIN RSA PRIVATE KEY-----“ beginnt.
    Erstellen Sie bei Bedarf den Schlüssel neu und registrieren Sie ihn auf der Adobe Developer Connection-Website.
  4. Überprüfen Sie, ob der Schlüssel innerhalb derselben Instanz codiert wurde wie in der Pipeline.
    Korrigieren Sie gegebenenfalls die Codierung mithilfe des JavaScript-Beispiels oder des Arbeitsablaufs.

Die Pipeline schlägt fehl, weil „der Token während der Authentifizierung nicht gelesen werden kann“

Der private Schlüssel hat ein ungültiges Format.

  1. Führen Sie die Schritte für die Verschlüsselung auf dieser Seite aus.
  2. Überprüfen Sie, ob der Schlüssel in derselben Instanz verschlüsselt ist.
  3. Überprüfen Sie, ob das „authPrivateKey“-Element in der Konfigurationsdatei mit dem generierten Schlüssel übereinstimmt.
    Stellen Sie sicher, dass Sie „OpenSSL“ zum Erstellen des Schlüsselpaars verwenden. „PuttyGen“ generiert zum Beispiel nicht das richtige Format.

Keine Trigger werden abgerufen

Wenn der Pipeline-Prozess ausgeführt wird und keine Trigger abgerufen werden:

  1. Stellen Sie sicher, dass der Trigger in Analytics aktiv ist und Ereignisse generiert.
  2. Stellen Sie sicher, dass der Pipeline-Prozess ausgeführt wird.
  3. Suchen Sie nach Fehlern im Pipeline-Protokoll.
  4. Suchen Sie auf der Pipeline-Statusseite nach Fehlern. Der Wert von „Trigger verworfen“ und „Trigger-Fehler“ sollte null betragen.
  5. Überprüfen Sie, ob der Name des Triggers in der Option „NmsPipeline_Config“ konfiguriert ist. Verwenden Sie im Zweifel die Wildcard-Option.
  6. Prüfen Sie, ob Analytics einen aktiven Trigger hat und Ereignisse generiert. Es kann eine Verzögerung von einigen Stunden nach der Konfiguration in Analytics geben, bevor die Funktion aktiv ist.

Ereignisse sind nicht mit einem Kunden verbunden

Wenn einige Ereignisse nicht mit einem Kunden verknüpft sind:

  1. Falls zutreffend, überprüfen Sie, ob der Arbeitsablauf ausgeführt wird.
  2. Überprüfen Sie, dass das Ereignis eine Kunden-ID enthält.
  3. Führen Sie mit der Kunden-ID eine Abfrage in der Kundentabelle aus.
  4. Überprüfen Sie die Häufigkeit des Kundenimports. Neue Kunden werden mit einem Workflow in Adobe Campaign importiert.

Latenz bei der Ereignisverarbeitung

Wenn der Analytics-Zeitstempel viel älter ist als das Erstellungsdatum des Ereignisses in Campaign.

Die normale Latenz ist weniger als 15 Minuten. 

  1. Prüfen Sie, ob der Pipeline-Prozess ausgeführt wurde.
  2. Suchen Sie nach Fehlern in „pipelined.log“, die Wiederholungsversuche verursachen können. Beheben Sie gegebenenfalls die Fehler.
  3. Überprüfen Sie die Pipeline-Statusseite auf die Größe der Warteschlange. Wenn die Warteschlange zu groß ist, verbessern Sie die Leistung des JS.
  4. Da eine Verzögerung mit dem Volumen wahrscheinlich zunimmt, konfigurieren Sie die Trigger für Analytics mit weniger Nachrichten.

Anhänge

So verwenden Sie das Schlüsselcodierungs-JavaScript

Führen Sie ein JavaScript aus, um den privaten Schlüssel zu codieren. Er ist für die Pipeline-Konfiguration erforderlich.

Im Folgenden finden Sie ein Codebeispiel, mit dem Sie die „cryptString“-Funktion ausführen können:

/*
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))

Führen Sie auf dem Server das JavaScript aus:

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

Kopieren Sie den codierten Schlüssel und fügen Sie ihn vom Output in die Konsole ein.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie