カスタムアクションのトラブルシューティング troubleshoot-a-custom-action
Journey Optimizer ユーザーインターフェイスの管理セクションから API 呼び出しを送信して、カスタムアクションをテストできます。この機能は、ジャーニーでカスタムアクションを使用する前または使用した後に、カスタムアクションのトラブルシューティングを行うのに役立ちます。
管理者は、テストリクエストを送信機能を使用し、Adobe Journey Optimizer から直接実際の API 呼び出しを行って、カスタムアクション設定を検証します。この機能により、リクエスト構造、ヘッダー、認証およびペイロードがジャーニーで使用される前に正しく書式設定されていることが確保されます。
この機能を使用すると、テストと検証のプロセスが効率化され、カスタムアクションがライブジャーニーで正しく機能することが確保されます。
前提条件 troubleshoot-custom-action-prereq
テストリクエストを送信機能を使用するには、URL、ヘッダーおよび認証設定を使用して カスタムアクション を事前設定する必要があります。
管理者がこの機能を使用するには、次の権限が必要です。
- ユーザーには、Manage journeys events, data sources and actions 権限が必要です。
- この権限は、ジャーニー管理者の役割に含まれます。
- View journeys events の権限だけでは不十分です。
ジャーニーの権限について詳しくは、この節を参照してください。
テストリクエストを送信機能の使用方法 troubleshoot-custom-action-use
カスタムアクションをテストするには、次の手順に従います。
-
アクション設定画面に移動し、カスタムアクションを選択します。
-
アクション設定画面の下部にある「テストリクエストを送信」ボタンをクリックします。
-
ポップアップウィンドウで、リクエストパラメーターを指定できます。
-
カスタムアクションメソッドは GET ですの場合は、ペイロードは必要ありません。
-
カスタムアクションメソッドは POST の場合は、JSON ペイロードを指定する必要があります。
note note NOTE この JSON の構造が正しくない場合は、Adobe Journey Optimizer でエラーが発生しますが、データタイプに不一致がある場合はエラーが発生しません。例えば、文字列を指定する必要があるものに整数パラメーターを使用した場合、エラーは発生しません。 -
認証を定義した場合は、認証の詳細の入力を求めるプロンプトが表示されます。
-
-
「送信」をクリックして、リクエストを実行します。
-
ヘッダーやステータスコードを含む API からの応答がインターフェイスに表示されます。
認証処理 troubleshoot-custom-action-auth
カスタムアクションに認証が含まれる場合、Adobe Journey Optimizer では、テストリクエストごとにユーザーが認証の詳細を入力する必要があります。
- 基本認証：ユーザーは パスワード を入力する必要があります。
- API キー認証：ユーザーは API キー 値 を入力する必要があります。
- カスタム認証：ユーザーはリクエスト bodyParam に認証パラメーターを指定する必要があります。この場合、認証リクエストと 認証応答 の 2 つのセクションが追加されます。
主なメリット troubleshoot-custom-action-benefits
Journey Optimizer 管理者は、外部ツール（Postman など）を使用して、カスタムアクションをテストすることもできます。外部テストと比較した製品内トラブルシューティング機能の主なメリットを次に示します。
-
テストリクエストは、AJO ジャーニーによって実行されます。つまり、次のようになります。
- 正確なリクエスト構造（Adobe Journey Optimizer 固有のヘッダーを含む）が使用されます。
- ソース IP とヘッダーは、ライブジャーニーで使用されるものに一致します。
-
カスタムアクションが既にデプロイされているので、テストリクエストを送信機能は ライブジャーニー のトラブルシューティングに使用できます。
-
この製品内テスト機能により、ツール間で設定の詳細を手動でコピーする必要がなくなり、エラーのリスクが軽減されます。
トラブルシューティング troubleshoot-custom-action-check
リクエストが失敗した場合は、次の項目を確認できます。
- テストに入力された認証資格情報。
- リクエストメソッド（GET と POST）および対応するペイロード。
- カスタムアクションで定義される API エンドポイントとヘッダー。
- 応答データを使用した、潜在的な設定ミスの識別。
破棄イベントとアイドルタイムアウトの処理 handling-discard-events-and-idle-timeouts
1 つのジャーニーのカスタムアクションが、2 番目のジャーニー の開始を目的としたイベントをトリガーにする場合は、2 番目のジャーニーが有効な状態にあり、イベントが認識されることを確認します。 イベントが 2 番目のジャーニーのエントリ条件を満たさない場合、イベントは 破棄 され、notSuitableInitialEvent などのコードと共にログに表示されます。 2 番目のジャーニーの準備が整っていない場合は、アイドルタイムアウトが発生し、ログでイベントが破棄される可能性があります。
一般的な原因：
-
イベントの選定が満たされていません - 2 番目のジャーニーは、選定条件を持つルールベースのイベントを使用しています（例：特定のフィールドの
isNotEmptyなど、必須フィールドは空でない必要があります）。 イベントペイロードがその条件を満たさない場合（例えば、フィールドが空または見つからない場合）、イベントは 受信されますが破棄されます、2 番目のジャーニーはトリガーされません。 これは想定されている動作です。検証条件が満たされない場合、イベントが破棄され、そのプロファイルに対してジャーニーがトリガーされないことがドキュメントとログで確認されています。 カスタムアクションで送信されたペイロードに、2 番目のジャーニーのイベント設定で必要なすべてのフィールドと値が含まれていることを確認します。 ジャーニーの実行で ルールベースのイベントを設定 および イベント受信のトラブルシューティング を行う方法を説明します。 -
2 番目のジャーニーの準備が整っていない -2 番目のジャーニーがまだアクティブでない場合（テストモードではない、ライブでないなど）や、カスタムアクションの実行と 2 番目のジャーニーの受信準備の間にタイミングギャップがある場合に、アイドルタイムアウトが発生することがあります。 カスタムアクションがトリガーされる前に、ターゲットジャーニーが公開されているか、テストモードになっていることを確認します。
-
破棄イベントの診断 - ログに破棄イベントが表示された場合は、ジャーニーログと Splunk トレースを確認して、イベントが受信されたが、選定（ペイロードがルールを満たしていない）またはタイミングが原因で破棄されたかどうかを確認します。 2 番目のジャーニーの開始日と設定が正しいこと、およびジャーニーがアクティブな日付ウィンドウ内にあることを確認します。
カスタムアクションでジャーニーを連結する際にイベントの破棄を避けるには、2 番目のジャーニーのイベントルールに対してイベントペイロードを検証し、ターゲットジャーニーがライブまたはテスト中であり、アクティブな日付ウィンドウ内にあることを確認します。
その他のリソース
カスタムアクションの設定と使用について詳しくは、以下の節を参照してください。
- カスタムアクションの基本を学ぶ - カスタムアクションの概要と、サードパーティシステムへの接続に役立つ仕組みについて説明します。
- カスタムアクションの設定 - カスタムアクションの作成および設定方法について説明します
- カスタムアクションの使用 - ジャーニーでのカスタムアクションの使用方法について説明します
- コレクションをカスタムアクションパラメーターに渡す - 実行時に値が動的に入力されるコレクションをカスタムアクションパラメーターに渡す方法について説明します