このページ：実際のテスト API 呼び出しを送信し、カスタムアクション設定を検証します。これにより、ライブジャーニーでこれらに依存する前にエラーを検出できます。
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 この 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 番目のジャーニーのイベントルールに対してイベントペイロードを検証し、ターゲットジャーニーがライブまたはテスト中で、アクティブな日付ウィンドウ内にあることを確認します。
その他のリソース
カスタムアクションの設定と使用について詳しくは、以下の節を参照してください。
- カスタムアクションの基本を学ぶ - カスタムアクションの概要と、サードパーティシステムへの接続に役立つ仕組みについて説明します。
- カスタムアクションの設定 - カスタムアクションの作成および設定方法について説明します
- カスタムアクションの使用 - ジャーニーでのカスタムアクションの使用方法について説明します
- コレクションをカスタムアクションパラメーターに渡す - 実行時に値が動的に入力されるコレクションをカスタムアクションパラメーターに渡す方法について説明します