影響
Campaign API のステージングメカニズム
Campaign Cloud データベースでは、パフォーマンス(待ち時間および同時実行性)に関して、単一呼び出しのブラストはお勧めしません。 非常に少量を送信する場合を除き、最適な API パフォーマンスを保証するには、バッチ操作を使用する必要があります。 パフォーマンスを向上させるために、取り込み API はローカルデータベースにリダイレクトされます。 Campaign API のステージングメカニズムについて詳しくはこちらを参照
新しい API
Campaign ローカルデータベースと Cloud データベース間のデータ同期を管理する新しい API をご利用いただけます。また、待ち時間の発生を回避し、全体的なパフォーマンスを向上させるために、ローカルデータベースレベルで API 呼び出しを処理する新しいメカニズムが導入されました。
新しい API について詳しくは、このページを参照してください。
データのレプリケーション
Campaign のローカルデータベースとクラウドデータベースの両側に存在する必要があるテーブルは、特定のテクニカルワークフローでレプリケーションを処理します。このワークフローは 1 時間ごとにトリガーされ、新規のビルトイン JavaScript ライブラリを活用します。
テーブルの中には、リアルタイムで複製されるものと、1 時間単位で複製されるものがあります。テーブルには、増分更新をおこなうものと、完全に更新されるものがあります。
ID 管理
Campaign v8 オブジェクトは、UUID(ユニバーサルに一意の ID) を使用するようになりました。これにより、一意の値(無制限)でデータを識別できます。
この ID は文字列で、連続していません。Campaign v8 ではプライマリキーは数値ではないため、スキーマで autouuid 属性と autopk 属性を使用する必要があります。
Campaign Classic v7 以前のバージョンでは、スキーマ(テーブルなど)のキーの単一性はデータベースエンジンのレベルで処理されます。一般的に、従来のデータベースエンジン(PostgreSQL、Oracle、SQL Server など)では、プライマリキーや一意のインデックスの列を使用して、重複行を挿入しないようにするためのメカニズムをネイティブで備えています。適切なインデックスとプライマリキーがデータベースレベルで設定されている限り、これらのバージョンでは ID の重複は発生しません。
Adobe Campaign v8 には、コアデータベースとして Snowflake が付属しています。クエリの規模が大幅に拡大するため、Snowflake データベースの分散アーキテクチャでは、テーブル内のキーの単一性を強制するそのようなメカニズムは提供されません。そのため、Adobe Campaign v8 では、重複したキーがテーブルに取り込まれるのを防ぐことはできません。エンドユーザーは、Adobe Campaign データベース内のキーの一貫性を確保する責任を負うようになりました。詳細情報
機能の可用性
Campaign の Enterprise(FFDA)デプロイメントのコンテキストでは、次のような一部の機能は利用できません。
- マーケティングリソース管理
- クーポン
- Web トラッキング
- 調査
関連トピック