トリガーは、パイプラインを使用する Adobe Campaign と Adobe Analytics 間の統合です。パイプラインは、Web サイトからのユーザーのアクションまたはトリガーを取得します。カート放棄は、トリガーの一例です。トリガーは Adobe Campaign で処理され、ほぼリアルタイムで電子メールを送信します。
要約 このドキュメントでは、Adobe Campaign で統合を構成するコンポーネントについて説明します。また、一般的な問題や設定を修正する方法についても説明します。
解決策 Adobe Campaign Classic (v6.11,v7)
オーディエンス 管理者、上級ユーザー

上記内容、または Adobe Campaign トピックの何れかに疑問を持っているならば、コミュニティヘお問い合わせください

概要

トリガーは、ユーザーのアクションに従い、短い期間内にマーケティングアクションを実行します。一般的な応答時間は1時間未満です。

構成が最小で第3者が関与しないため、より高度な統合が可能になります。
また、マーケティング活動のパフォーマンスに影響を与えずに高トラフィック量がサポートできます。例として、統合により、1時間当たりでトリガー百万操作することができます。

アーキテクチャ

パイプラインとは何ですか?

パイプラインは、Apache Kafka を使用する Experience Cloud でホストされるメッセージングシステムです。これは、ソリューション間でデータを簡単に渡す方法です。さらに、パイプラインはデータベースではなくメッセージキューです。プロデューサーは、パイプラインのイベントをプッシュし、コンシューマーがフローをリッスンしてイベントで必要なことを処理します。イベントは数日間保持されますが、それ以降は保持されません。目的は 24 時間リッスンし、イベントをすぐに処理することです。

Picture1

パイプラインはどのような仕組みですか?

「パイプライン化された」プロセスは、常に Adobe Campaign マーケティングサーバー上で実行されています。これはパイプラインに接続し、イベントを取得して、すぐに処理します。

Picture2

このパイプライン化されたプロセスは、認証サービスを使用して Experience Cloud にログインし、秘密鍵を送信します。認証サービスはトークンを返します。トークンは、イベントの取得時に認証するために使用されます。トリガーは、単純な GET 要求を使用して REST Web サービスから取得されます。レスポンスは JSON 形式です。要求のパラメーターには、トリガーの名前と、最後に取得したメッセージを示すポインターが含まれます。パイプライン化されたプロセスはこれを自動的に処理します。

用途

注意:

これは、様々な可能な実装の具体的な例です。

パイプラインイベントは自動的にダウンロードされます。これらのイベントはフォームを使用して監視できます。

image2017-1-13 18_8_3 blur

繰り返しのキャンペーンワークフローではトリガーでクエリが行われ、マーケティング条件に一致する場合は、配信が開始されます。

image2017-1-13 18_13_31 blur

パイプラインの設定

概要

顧客 ID、秘密鍵、認証エンドポイントなどの認証パラメーターは、インスタンス設定ファイルで設定されます。
処理されるトリガーの一覧は、オプションで設定されます。JSON 形式にあります。

トリガーは、JavaScript コードを使用して直ちに処理されます。これは、リアルタイムでさらに処理されないデータベーステーブルに保存されます。
トリガーは、電子メールを送信するキャンペーンワークフローによりターゲット設定に使用されます。キャンペーンは、両方のトリガーイベントがある顧客が電子メールを受信するように設定されています。

前提条件

Campaign での Experience Cloud Triggers の使用には、次が必要です。

  • Adobe Campaign バージョン 6.11 ビルド 8705 以降。
  • Adobe Analytics Ultimate、Premium、Foundation、OD、Select、Prime、Mobile Apps、Select、または Standard。

前提条件の設定は、次のとおりです。

  • 秘密鍵ファイルの作成と、そのキーで登録されている oAuth アプリケーションの作成。
  • Adobe Analytics でのトリガーの設定。

Adobe Analytics の設定は、このドキュメントの範囲外です。
Adobe Campaign には、Adobe Analytics に関する以下の情報が必要になります。

  • oAuth アプリケーションの名前。
  • IMSOrgId。これは、Experience Cloud の顧客の識別子です。
  • Analytics で設定されたトリガーの名前。
  • マーケティングデータベースに準拠するデータフィールドの名前と形式。

注意:

この構成の一部はカスタム開発であり、次が必要です。

  • Adobe Campaign での JSON、XML、および JavaScript の解析に関する実用的な知識。
  • QueryDef および Writer API に関する実用的な知識。
  • 秘密鍵を使用した暗号化と認証に関する実用的な概念。

JS コードを編集するには技術的なスキルが必要なため、適切に理解せずにこれを試みないでください。

トリガーはデータベーステーブルに保存されます。したがって、トリガーデータは、対象のワークフローのマーケティングオペレーターにより安全に使用できます。

認証および設定ファイル

パイプラインは Adobe Experience Cloud でホストされているため、認証が必要です。
マーケティングサーバーがオンプレミスでホストされている場合、パイプラインにログインすると、安全な接続ができるように認証する必要があります。
これは、公開および秘密鍵のペアが使用されます。このプロセスは、ユーザー/パスワードと同じ機能であり、唯一より安全になります。

IMSOrgId

IMSOrgId は、Adobe Experience Cloud の顧客の ID です。
IMSOrgId 属性の下にインスタンス serverConf.xml ファイルを設定します。

次に例を示します。

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

キーの生成

キーは、ファイルのペアです。それは、RSA 形式および 4096 バイトの長さになります。OpenSSL などのオープンソースツールで生成できます。ツールを実行するたびに、新しいキーがランダムに生成されます。

便宜上、手順は以下のようにリストされます。

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

private_key.pem ファイルの例:

 

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

 public_key.pem ファイルの例:

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

注意:

キーは PuttyGen で生成するべきではなく、OpenSSL が最適な方法です。

Adobe Experience Cloud での oAuth クライアントの作成

JWT タイプのアプリケーションは、Adobe Developer Connection にログインして作成する必要があり、次の手順に従います。

  1. 「サービスアカウント(ブローカー)」を選択します。
  2. アプリケーション名を入力します。
  3. 公開鍵を登録します。
  4. 組織(管理者アカウントが必須)を選択します。
  5. トリガーの範囲を選択します。
worddav742582ccac2fe4e5078ee2804a38addf

Adobe Campaign のアプリケーション ID 設定

oAuth クライアントが作成したアプリケーション ID は、Adobe Campaign で設定する必要があります。特にアプリ名属性は、パイプライン要素でインスタンス設定ファイルを編集することにより可能になります。

次に例を示します。

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

鍵の暗号化

パイプラインで使用するには、秘密鍵を暗号化する必要があります。
暗号化は、cryptString JavaScript 関数を使用して行われます。
パイプラインと同じインスタンスで実行される必要があります。
JavaScript で使用する秘密鍵の暗号化のサンプルは、Annex で利用可能です。

Adobe Campaign のキー登録

暗号化された秘密鍵は、Adobe Campaign に登録する必要があります。パイプライン要素でインスタンス設定ファイルを編集、特に authPrivateKey 属性で編集します。

次に例を示します。

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

パイプラインプロセス自動スタート

パイプラインプロセスは、自動で開始する必要があります。

これを行うには、設定ファイル内の要素を autostart="true" に設定します。

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

パイプラインプロセス再開始

また、コマンドラインを使用して手動で起動することができる:
nlserver start pipelined@instance

変更を有効にするために再起動が必要である:
nlserver restart pipelined@instance

エラーの場合

標準出力(手動で開始した場合)またはパイプラインログファイルにエラーを探し出す。問題の解決について詳しくは、このドキュメントの「トラブルシューティング」セクションを参照してください。

パイプライン設定オプション

オプション 説明
appName Adobe Developer Connection(公開キーがアップロードされた場所)に登録されている OAuth アプリケーションの ID である。
https://marketing.adobe.com/developer/ja/documentation/authentication-1/auth-service-account-1を参照してください。
authGatewayEndpoint 「ゲートウェイトークン」を取得する URL。デフォルト: https://api.omniture.com
authPrivateKey プライベートキー(Adobe Developer Connection にアップロードされた公開部分)AES が XtkKey オプションで暗号化されている:
cryptString("PRIVATE_KEY")
disableAuth 認証の無効化(ゲートウェイトークンなしの接続は、一部の開発パイプラインエンドポイントでのみ承認されます)
discoverPipelineEndpoint このテナントに使用するパイプラインサービスエンドポイントを検出する URL。デフォルト: https://producer-pipeline-pnw.adobe.net
dumpStatePeriodSec var/INSTANCE/pipelined.json 内部状態のプロセス内部状態の 2 つのダンプ間の期間には、http://INSTANCE:7781/pipelined/status からオンデマンドでもアクセスできます
forcedPipelineEndpoint PipelineServicesEndpoint の検出を無効にして、それを強制します
monitorServerPort パイプラインプロセスは、このポートをリッスンし、http://INSTANCE:PORT/pipelined/status でプロセス内部ステータスを提供します。デフォルトは 7781 です
pointerFlushMessageCount この数のメッセージが処理されると、オフセットがデータベースに保存されます。デフォルトは、1000 です
pointerFlushPeriodSec この期間、オフセットはデータベースに保存されます。デフォルトは、5(秒)です。
processingJSThreads カスタム JS コネクタを使用した専用スレッド処理メッセージの数。デフォルトが4である。
processingThreads 組み込みコードを使用した専門スレッド処理メッセージの数である。デフォルトは 4 である。
retryPeriodSec 再試行の間の遅延(処理エラーがある場合)。デフォルト値は30(秒)である
retryValiditySec この期間以降に成功に処理されない場合は、メッセージを放棄する(再試行が多い)。デフォルト値は300(秒)である

NmsPipeline_Config パイプラインオプション

認証が完了すると、パイプラインはイベントを取得してそれらを処理できます。Adobe Campaign で設定されたトリガーのみが、他のユーザーを無視します。トリガーは Analytics から生成され、事前にパイプラインにプッシュされる必要があります。
オプションは、名前に関係なくすべてのトリガーを検出できるようにワイルドカードを使用して設定することもできます。
トリガーは、管理 > プラットフォーム > オプションを選択し、1つのオプションに設定します。オプション名は NmsPipeline_Config です。データタイプは「long text」です。JSON 形式にします。

例 1

この例では2つのトリガーを指定しています。

このテンプレートからの JSON コードをオプション値に張り付けます。コメントを確実に削除してください。

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

例 2

この例において、すべてのトリガーを検出します。

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

注意:

Analytics インターフェイスにおける特定のトリガー名のトリガー UID 値は、トリガーインターフェイスにおいて、URL クエリーストリングの一部として表示されます。トリガータイプ UID はデータストリームパイプラインを介して渡し、コードはパイプラインに書き込むことができます。JS はマップへ、トリガー UID はユーザーにわかりやすいラベルへと、パイプライン Events スキーマにおけるトリガー名コラムに格納します

コンサマーパラメーター

パイプラインは、「サプライヤとコンサマー」モデルで使います。同じキューに多くのコンサマーが存在することがあります。メッセージはただ個々のお客様に対して使用される。各お客様が自分のメッセージの「コピー」を取得する。


これらの「顧客」パラメーターは、顧客の1人として、インスタンスを識別する。これは、パイプラインと呼ばれるインスタンスの ID である。インスタンス名が入力できる。パイプラインサービスは、各お客様が取得したメッセージを追跡する。異なるインスタンスに対して異なるコンシューマーを使用すると、各メッセージが各インスタンスに送信されることを確保する。

パイプラインオプションの設定方法

「トリガー」アレイの下に Experience Cloud Triggers を追加または編集する;残りを編集しないでください。
JSON が有効であることを確認してください。この Web サイトは、以下の目的に使用できます。http://jsonlint.com/

  • 「name」はトリガー ID です。ワイルドカード「*」はすべてのトリガーを検出します。
  • 「消費者」は、nlserver インスタンスをを一意に識別する一意の文字列です。通常は、インスタンス名自体です。様々な環境(開発/ステージ/製品)において、各インスタンスがメッセージのコピーを取得するには、それぞれ固有であることを確認します。
  • パイプラインは「エイリアス」トピックもサポートしています。

変更後にパイプラインを再起動します。

イベント処理

JavaScript のイベント処理

JS ファイル

パイプラインでは、JavaScript 関数を使用して各メッセージを処理します。この関数はユーザー定義です。

「JSConnector」属性の NmsPipeline_Config オプションで設定されます。この javascript は、イベントが受信されるたびに呼び出されます。パイプライン化プロセスによって実行されます。

サンプル JS ファイルは cus:triggers.js です。

JS 関数

パイプライン JavaScript は特定の関数で開始する必要があります。

この関数は、次の各イベントごとに 1 回呼び出されます。

    function processPipelineMessage(xmlTrigger) {}

これは <undefined/>を返す必要がある。

JS を編集した後にパイプラインを再起動する。

トリガーデータ形式

トリガーデータが JS 関数へ渡す。XML 形式である。

  • @triggerId 属性は、トリガーの名前が含まれている。
  • enrichments エレメントには Analytics で生成されたデータを含み、且つトリガーに付加されている。JSON 形式にします。
  • @offset はメッセージの「ポインター」である。キュー内のメッセージの順序を示す。
  • @partition キュー内のメッセージのコンテナである。オフセットは、パーティションと関係がある。キューに約15のパーティションが含まれている。

次に例を示します。

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

データ形式を豊富させる

注意:

これは、様々の可能な実装の具体的な例である。

コンテンツは、各トリガーの Analytics で定義される。JSON 形式にします。
例えば、トリガー LogoUpload_uploading_Visits に:

  • eVar01 キャンペーン受信者で調整するために使用される買い物客 ID を含めることができる。これは文字列形式である。プライマリキーである、Shopper ID を検索するために紐付けされる必要があります。
  • timeGMT には、Analytics 側でのトリガーの時間を含めることができます。これは UTC エポック形式(1970 年 1 月 1 日 UTC からの秒数)になります。

次に例を示します。

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

イベント処理の順序

イベントは、オフセットの順で、一度に 1 つずつ処理されます。パイプラインの各スレッドは異なるパーティションを処理します。

取得された最後のイベントの「オフセット」はデータベースに格納されます。そのため、プロセスが停止すると、最後のメッセージから再開されます。このデータは、ビルトインスキーマ xtk:pipelineOffset に格納されます。

このポインターは各インスタンスと各顧客に対して特定である。したがって、多数のインスタンスに異なる消費者がいる同じパイプラインにアクセスする場合、それらのインスタンスは同じ順序ですべてのメッセージを取得する。

パイプラインオプションの「顧客」パラメーターは、呼び出されているインスタンスを識別する。

現在、「ステージング」や「デバイス」などの独立な環境に異なるキューを作成する方法はない。

ロギングとエラー処理

logInfo () などのログは、パイプラインログに管理される。logError () などのエラーがパイプラインログに書き込まれ、再試行キューにイベントが投入されたことを引き起こす。
エラーメッセージがデュレーション設定に多回にパイプラインオプションに再試行された。
デバッグと監視の目的は、完全なトリガーデータがトリガーテーブルに書き込まれることである。これは XML 形式の「データ」フィールドにある。また、トリガーデータを含む logInfo () は同じ目的でサービスを提供する。

データの解析

このサンプル JS コードが eVar01 を解析し、且つそれを豊富させる。

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

解析時にエラーを避けるように注意してください。
このコードはすべてのトリガーに用いられるため、ほとんどのデータが要らない。したがって、存在しない場合は空のままにできる。

トリガーの保存

注意:

これは、様々な可能性がある実装からの具体的な例である。

このサンプル JS コードは、トリガーをデータベースに保存する。

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

制約

このコードのパフォーマンスは、高周波数で実行されるため、最適する必要がある。その他のマーケティング活動には、潜在的な悪影響がある。特に、1 時間あたり 100 万回のトリガーイベントをマーケティングサーバー上で処理する場合。または正しくチューンされない場合。

この JavaScript のコンテキストは制限された。API の一部の関数は使用できない。例えば、getOption () または getCurrentdate () は機能しない。

処理を高速化するため、このスクリプトの複数のスレッドが同時に実行される。コードを安全にスレッドする必要がある。

イベントの保存

注意:

これは、様々の可能な実装の具体的な例である。

パイプラインイベントスキーマ

イベントはデータベーステーブルに保存される。マーケティングキャンペーンによって顧客をターゲット化し、トリガーを使用して電子メールを補完するために使用される。
各トリガーがはっきりのデータ構造を持つことができるが、すべてのトリガーを単一の表に含むことができる。
トリガータイプフィールドは、トリガーがデータを生成することから識別する。

このテーブルのサンプルスキーマコードは次のとおりである:

属性 タイプ ラベル 説明
pipelineEventId 長く プライマリキー トリガー内部のプライマリキーである。
data メモ トリガーデータ XML 形式のトリガーデータの完全な内容。デバッグおよび監査の目的で使用する。
triggerType 文字列50 TriggerType トリガーの名前。ウェブサイトの顧客の行動を識別する。
shopper_id 文字列32 shopper_id 商店の内部識別子である。調和されたワークフローによって設定される。0 の場合、キャンペーンに顧客不明であると意味する。
shopper_key 長く shopper_key Analytics によってキャプチャされた商店の外部 ID である。
作成 日時 作成 キャンペーンにイベントが作成された日時である。
lastModified 日時 最終変更日 アドビにイベントが最後に修正された日時。
timeGMT 日時 タイムスタンプ イベントが Analytics に生成された時刻である。

イベントの表示

イベントは、イベントスキーマに基づいて簡単なフォームで表示できる。

image2017-1-13 18_8_3 blur

イベントの処理

Reconciliation ワークフロー

調整は、Analytics から Campaign データベースへの顧客との照合のプロセスです。例えば、照合する条件は shopper_id です。

パフォーマンス上の理由から、ワークフローでは一致する必要があります。
周波数は、ワークロードを最適化するために、15分になります。結果として、Adobe Campaign のイベントを受け取ったときの遅延とマーケティングのワークフローによって処理には最長15分間です。

JS の単位調整のオプション

理論では、JS 内の各トリガーの reconciliation を実行できます。パフォーマンスが向上し、結果が高速になります。反応が必要である場合は、特定の使用事例も必要になる。

インデックスが商店_id に設定されていない場合、この実行が難しくなる。条件がマーケティングサーバーより別のデータベースサーバーのほうにある場合、フォーマンスが低下するデータベースリンクを使用する。

ワークフローのクリア

トリガーは時間内に処理されるので、長い時間に保持する理由はない。ボリュームは1時間あたり約100万のトリガーになれる。ワークフロークリアは必ず正しく配置される理由を説明する。クリアは、3日間より古いトリガーをすべて削除し、且つ 1 日に 1 回運行する。

キャンペーンワークフロー

トリガーキャンペーンワークフローは、他の使用されていた循環キャンペーンと常に類似している。
例えば、トリガーのクエリーで最後の日に特定のイベントを探すことが開始できる。このターゲットは電子メールの送信に使用される。エンリッチメントまたはデータはトリガーから取得できる。マーケティングが設定を必要としないので、安全に使用できる。

image2017-1-13 18_13_31 blur

パイプラインモニタリング

パイプラインプロセスのステータス

パイプラインステータスウエブサービスは、パイプラインプロセスの状態に関する情報を提供する。

ブラウザーを使用して手動でアクセスすることも、監視アプリケーションと共に自動的にアクセスすることもできる。

REST 形式は以下のとおりである:

image2017-1-10 17-2-30

インジケーター

ここでは、ステータス Web サービスのインジケーターを示します。
推奨される監視インジケーターはハイライト表示されます。

  • Consumer:トリガーを取得するクライアントの名前。パイプラインオプションで設定します。
  • HTTP Request
    • last-alive-ms-ago:接続チェックが行われてからの時間(ミリ秒)。
    • last-failed-cnx-ms-ago:接続チェックが最後に失敗してからの時間(ミリ秒)。
    • pipeline-host:パイプラインデータが取得されるホストの名前。
  • ポインター
    • current-offsets:子スレッドごとのパイプラインへのポインターの値です。
    • last-flush-ms-ago:トリガーのバッチが取得されてからの時間(ミリ秒)。
    • next-offsets-flush:終了したときに、次のバッチまで待機する時間です。
    • processed-since-last-flush:最後のバッチで処理されたトリガーの数です。
  • ルーティン
    • trigger:取得されたトリガーのリストです。パイプラインオプションで設定されます。
  • ステータス
    • average-pointer-flush-time-ms:トリガーの1 つのバッチの平均処理時間。
    • average-trigger-processing-time-ms:トリガーデータの分析の平均時間です。
    • 読み取りバイト数:プロセスが起動された後にキューから読み取ったバイト数です。
    • 現在のメッセージ :キューから取得され、処理を待っている保留中のメッセージの現在の数です。このインジケーターがゼロに近づく必要があります.
    • 現在の再試行回数:処理が失敗し、再試行を待っているメッセージの現在の数です。
    • peak-messages:プロセスが開始されてからプロセスが処理された最大保留数。
    • ポインタフラッシュ:起動後に処理されるメッセージのバッチ数です。
    • ルーティング JS カスタム:カスタム JS によって処理されたメッセージの数です。
    • トリガー破棄:処理エラーのため、再試行回数が多すぎると破棄されたメッセージの数です。
    • トリガー処理:エラーなしで処理されたメッセージの数です。
    • トリガー受信:キューから受信されたメッセージの数です。

これらの統計は、処理スレッドごとに表示されます。

  • average-trigger-processing-time-ms:トリガーデータの分析の平均時間です。
  • is-JS プロセッサー:このスレッドがカスタムの JavaScript を使用している場合は、値 "1"。
  • trigger-discarded:処理エラーが発生したために破棄されたメッセージの数です。このインジケーターはゼロを指定する必要があります。
  • トリガーエラー: JS 処理エラーの数です。このインジケーターはゼロを指定する必要があります.
  • trigger-received:キューから受信したメッセージの数です。

 

  • 設定:設定ファイルで設定されます。
    • flush-pointer-msg-count:バッチ内のメッセージの数である。
    • flush-pointer-period-ms:2 つのバッチの間の時間(ミリ秒単位)である。
    • processing-threads-JS:カスタム JS を実行しているスレッドの処理数。
    • retry-period-ms:処理エラーが発生したときの 2 つの再試行の間の時間である。
    • retry-validity-duration-ms:時間処理の持続時間は、メッセージが放棄されるまで再試行された。

パイプラインメッセージレポート

このレポートには、1 時間あたりのメッセージ数が最後に 5 日間表示される。

image2017-1-10 17-3-10

パイプラインのトラブルシューティング

パイプラインフェイルがエラーとともに発生した「マスクに対応するタスクがない」パイプライン@"

お使いのバージョンの AC はパイプラインをサポートしていない。

  1. パイプラインエレメントがコンフィグファイルに存在するかどうかをチェックする。チェックしない場合は、サポートされていないことを意味する。
  2. バージョンにアップグレードする 6.11 ビルド 8705または後

パイプラインは「aurait dû commencer par '[' ou '{' (iRc=16384)」で失敗した

NmsPipeline_Config オプションは設定されていない。これは確かに JSON 解析エラーである。
オプションに JSON コンフィグを設定する NmsPipeline_Config。このページの「ルーティングオプション」を参照してください。

パイプラインは「サブジェクトが必ず合法的な組織や顧客であること」で失敗した

IMSOrgid 設定が無効である。

  1. serverConf.xml で IMSOrgId が設定されていることを確認する。
  2. デフォルトをオーバーライドすることができるインスタンスコンフィグファイルに空の IMSOrgId を探す。そして、削除してください。
  3. Experience Cloud で顧客との IMSOrgId が一致することを確認する。

失敗したパイプライン「無効なキー」

インスタンスコンフィグファイルの @authPrivateKey パラメーターが正しくない。

  1. authPrivateKey は設定されたかチェックする。
  2. authPrivateKey を確認する:@で始まり、,=で終わり、2600の文字がある。
  3. 元のキーを探し出し、それをチェックする:RSA 形式、4096ビットの長さ、-----BEGIN RSA PRIVATE KEY-----で開始する。
    必要に応じて、キーを再作成し、Adobe Developer Connection に登録する。
  4. パイプラインされた同じインスタンス内でキーがエンコードされたことを確認する。
    必要に応じて、サンプルの JavaScript やワークフローを使用してエンコーディングを再度実行する。

パイプラインは「授権期間にトークンが読めない」で失敗した。

プライベートキーの形式が無効である。

  1. このページにキーの暗号化手順を実行する。
  2. 同じインスタンスでキーが暗号化されていることを確認する。
  3. コンフィグファイルの authPrivateKey が生成されたキーと一致することを確認する。
    OpenSSL を利用してキーペアを生成することを確保する。例えば、PuttyGen は適切なフォーマットを生成しない。

トリガーは取得されない

パイプラインプロセスが実行中であり、トリガーが取得されない場合:

  1. トリガーが Analytics に活躍で、イベントを生成していることを確認する。
  2. パイプラインプロセスが実行中であることを確認する。
  3. パイプラインログにエラーを探す。
  4. 「パイプラインステータス」ページにエラーを探す。トリガー除去、トリガー失敗はゼロになる必要がある。
  5. トリガーの名前が NmsPipeline_Config オプショに設定されたことをチェックする。疑わしい場合は、ワイルドカードオプションを使用する。
  6. Analytics にアクティブなトリガーを持ち、イベントを生成していることを確認する。アクティブ前に Analytics に設定が行われてから、数時間の遅延が発生することがある。

イベントは、お客様にリンクされていない

一部のイベントが顧客にリンクされていない場合:

  1. 必要に応じて、調和のワークフローが実行中であることを確認する。
  2. イベントに顧客 ID が含まれていることを確認する。
  3. 顧客 ID を使用して顧客テーブルにクエリーを行う。
  4. 顧客読み込みの頻度を確認する。新規顧客は、ワークフローで Adobe Campaign に読み込まれる。

イベント処理の遅延

Analytics タイムスタンプが、Campaign のイベントの作成日よりもっと古い場合。

通常の遅延は15分未満である。

  1. パイプラインプロセスが実行されているかどうかを確認する。
  2. パイプライン.ログの再試行を引き起こす原因になるエラーを探す。該当する場合は、エラーを修正する。
  3. キューサイズのためにパイプラインステータスページをチェックする。キューサイズが大きい場合は、JS のパフォーマンスを改善する。
  4. 遅延はボリュームとともに増加することがあるので、少数のメッセージを使用して、Analytics のトリガーを設定する。

付加

キー暗号化 JavaScript の使用方法

JavaScript を実行してプライベートキーを暗号化する。これは、パイプラインの設定に必要である。

次に、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))

サーバー上で、JavaScript を実行する。

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

エンコードされたキーを出力からコンソールにコピー&ペーストする。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー