このページでは、管理者がAdobe Journey Optimizerをサードパーティ APIに接続する外部統合を設定、テスト、アクティベートする方法について説明します。これにより、マーケターはそれらを使用して、アウトバウンドチャネルでパーソナライズされた動的コンテンツを構築できます。
Standardの統合により、Journey Optimizerをサードパーティ APIに直接接続し、外部データやコンテンツをアウトバウンドチャネルに取り込んでパーソナライズできます。
閲覧統合を標準統合のパラメーターにリンクして、マーケターが選択した値をAPI呼び出しに自動的に渡すこともできます。
標準統合の作成 configure
管理者は、次の手順に従って外部統合を設定できます。
統合とリクエストの設定
まず、統合を作成し、外部APIの呼び出し方法を定義します。
-
左側のメニューの「設定」セクションに移動し、統合カードから「管理」をクリックします。
次に、「統合を作成」をクリックして、新しい設定を開始します。
{modal="regular"}
-
オプションで、cURL コマンドをペーストして、URL、HTTP メソッド、ヘッダー、クエリパラメーターを自動入力します。
-
統合の 名前 と 説明 を入力します。
note NOTE 「名前」フィールドにスペースを含めることはできません。 -
API エンドポイント URLを入力します。
パス変数の場合は、URL内のラベルを2つの中括弧で囲みます(例:
https://api.example.com/v1/products/{{productId}})。次に、パスパラメーターに各プレースホルダーを設定します。 -
「参照を有効にする」を選択して、アクティブな参照の統合をリンクします。これにより、応答フィールドをヘッダー、クエリとパスのパラメーター、およびペイロードの変数にマッピングできます。
➡️参照 ブラウジング統合の作成
{modal="regular"}
-
URLに追加したすべてのプレースホルダーに対して、パスパラメーターを 名前 および デフォルト値 で設定します。
名前は、エディターでのみ表示されるマーケター向けのラベルで、API リクエストには送信されないことに注意してください。
{modal="regular"}
-
GET と POST の間で HTTP メソッドを選択します。
-
統合の必要に応じて、「ヘッダーを追加」や「クエリパラメーターを追加」をクリックします。 各パラメーターに対して、次の詳細情報を入力します。
-
パラメーター:API で想定される、実際のヘッダーまたはクエリパラメーターの名前。
-
名前:このパラメーターに対する、マーケターにとって使いやすいラベル。キャンペーンで値をマッピングする際、作成者がこれを選択します。
-
タイプ:固定値の場合は「定数」、動的入力の場合は「変数」を選択します。
-
値:定数の値を直接入力するか、変数のマッピングを選択します。
-
必須:このパラメーターが必須かどうかを指定します。 必須の 変数 パラメーターの場合、実行時に値が解決されず、デフォルト値が指定されていない場合、リクエストの生成はエラーで失敗し、アウトバウンド API 呼び出しは実行されません。
{modal="regular"}
-
リクエストを定義したら、認証、ポリシー、応答ペイロードを設定する準備が整います。
認証、ポリシー、応答の設定
リクエストを定義したら、認証と動作の方法を設定し、パーソナライゼーションに使用する応答を形成します。
-
次の 認証タイプ を選択します。
-
認証なし:資格情報を必要としないオープンな API の場合。
-
API キー:静的 API キーを使用してリクエストを認証します。 API キー名、API キー値を入力し、場所を指定します。
-
基本認証:標準の HTTP 基本認証を使用します。 ユーザー名と パスワード を入力します。
-
OAuth 2.0:OAuth 2.0 プロトコルを使用して認証します。
アイコンをクリックして、ペイロードを設定または更新します。
{modal="regular"}などの認証タイプ オプション
-
-
API リクエストの タイムアウト 期間などの ポリシー設定 を指定し、スロットル、キャッシュ、再試行を有効にすることを選択します。
note NOTE スロットルを有効にすると、サポートされるレートは 50~5000 TPS になります。 制限は、各 API エンドポイントではなく、統合に適用されます。 再試行が有効な場合、その他の失敗についてはデフォルトで 3 回再試行が行われ、試行間隔は 200 ms、400 ms、800 ms となります。 -
POST メソッドの場合、Body typeを選択して Payload を設定します。
-
JSON:
アイコンをクリックし、JSON リクエストペイロードを貼り付けます。 ペイロードで実行する必要がある変数をマッピングします。 -
GraphQL: GraphQL クエリを貼り付けます。 Journey Optimizerは 操作名 を自動的に生成し、対応するクエリ変数をマッピングできます。
生成されたオペレーション名とクエリ変数マッピングを含む
{modal="regular"}
-
-
JSONと HTML の間の 応答タイプ を選択します。
-
「応答ペイロード」フィールドを使用すると、サンプル出力のどのフィールドをメッセージのパーソナライゼーションに使用する必要があるかを決定できます。
アイコンをクリックし、サンプルの JSON 応答ペイロードを貼り付けると、データタイプが自動的に検出されます。 -
パーソナライゼーション用に公開するフィールドを選択し、対応するデータタイプを指定します。
{modal="regular"}
note NOTE 応答ペイロード設定では、オーサリングに期待される応答を、その手順で適用されたスキーマを含めて定義します。 マーケターは公開されたフィールドのみを参照でき、他のパスのトークンはエディターでの検証に失敗します。
認証、ポリシー、応答を設定したら、接続をテストしてからアクティベートします。
接続をテストする connection
テスト接続を送信では、アクティブ化の前にターゲット API に対してエンドポイントURL、認証、リクエスト構造を検証します。これにより、メッセージ処理中のランタイムエラーのリスクが低減されます。
-
URL、HTTPメソッド、ヘッダー、クエリパラメーターを定義したら、「テスト接続を送信」をクリックして接続テストを実行し、設定を確認します。
-
テスト接続を送信ダイアログで、URL パス、ヘッダー、クエリパラメーターに 変数 プレースホルダーのデフォルト値を入力します。
これらの値はテストリクエストに含まれます。 Journey Optimizer は、エンドポイントを呼び出し、接続が成功したか失敗したかを報告します。
{modal="regular"}
-
テストで正常な応答が返された場合は、「応答ペイロードとして使用」を選択して応答本文を「応答ペイロード」フィールドにコピーします。詳しくは、統合の設定の手順 10 を参照してください。ここでは、データタイプの検出や、パーソナライゼーションに使用するフィールドの選択を行うことができます。
{modal="regular"}を使用して、接続の応答をテストしました
-
テストが成功しない場合は、エラードロップダウンを展開して、エラーの詳細を確認し、必要に応じて統合設定を更新して、テスト接続を送信をもう一度実行します。
{modal="regular"}
テストが成功したら、統合設定で「アクティブ化」を選択します。
統合の管理
テストが成功したら、統合をアクティベートし、必要に応じて更新またはアーカイブします。
-
検証が完了したら、「アクティブ化」をクリックします。
-
新しく作成した統合にアクセスして、次の操作を実行します。
-
更新:認証の詳細と ポリシー設定 のみを変更します。 更新は、ライブジャーニーとキャンペーンに適用されます。 変更を保存する前に、参照を探索メニューを使用して、統合が使用される場所を確認します。
-
アーカイブ:統合設定をアーカイブします。
{modal="regular"}
-
-
アクティブ化後、
アイコンをクリックして 参照を探索 メニューにアクセスし、この設定の使用状況(これに依存するジャーニーやキャンペーンを含む)を確認します。 {modal="regular"}
統合が開始されたら、次の送信時の動作を念頭に置いてください。
送信時間の制限と動作 configure-send-time
送信時に、外部 API からの応答は、デフォルトで最大 4 MB になる場合があります。 これを超えるサイズは統合エラーとして処理され、応答サイズによる失敗の場合、再試行は実行されません。
呼び出しには、設定した スロットル レートが適用されます。Journey Optimizer は、外部システムが停止している場合やエラーが返された場合でも、その制限まで試行をスケジュールします。 キャッシュが有効な場合、成功した応答のみが保存され、定義したキャッシュ TTL が期限切れになるまで再利用されます。失敗した応答がキャッシュされることはありません。
キューに追加した各メッセージには、有効期間(TTL)も設定されています。 処理が遅れてメッセージがそのウィンドウを過ぎている場合、システム はそれを破棄し、MessageValidityExclusion イベントを発生するので、古い作業はキューからクリアされ、リソースは引き続き利用できます。
関連項目