一般的なアーキテクチャ

一般的な Adobe Campaign ソリューションのデプロイメントは、次のコンポーネントで構成されます。

  • パーソナライズされたクライアント環境

    ユーザーがマーケティングオファーを伝え、トラッキングし、キャンペーンを作成し、すべてのマーケティング活動、プログラムとプラン(E メール、ワークフロー、ランディングページを含む)を確認、管理し、顧客プロファイルを作成、管理し、顧客オーディエンスタイプを定義できます。

  • 開発環境

    サーバーサイドのソフトウェア。ユーザーインターフェイスで定義するルールとワークフローに基づき、選択したコミュニケーションチャネル(メール、SMS、プッシュ通知、ダイレクトメール、Web、Social など)を通じてマーケティングキャンペーンを実施できます。

  • データベースコンテナ

    リレーショナルデータベーステクノロジーに基づき、Adobe Campaignデータベースには、顧客の情報、キャンペーンコンポーネント、オファーおよびワークフローのほか、キャンペーンの結果が顧客データベースコンテナに格納されます。

Adobe Campaignは、サービス指向アーキテクチャ (SOA) に基づいており、複数の機能モジュールで構成されています。 これらのモジュールは、拡張性、可用性、サービスの分離に関する制約に応じて、1 つ以上のコンピューターに、1 つまたは複数のインスタンスでデプロイできます。 したがって、展開構成の範囲は非常に広く、1 台の中央コンピュータから複数のサイトにわたる複数の専用サーバを含む構成まで広がります。

メモ

ソフトウェアベンダーは、互換性のあるハードウェアおよびソフトウェアインフラストラクチャを指定します。 ここで示すハードウェア推奨事項は、情報提供のみを目的とし、アドビの経験に基づいています。 Adobeは、その決定に基づいて下された一切の決定に対して責任を負いません。 また、ビジネス・ルールと実践、重要度、必要なパフォーマンス・レベルにも依存します。

注意

特に明示的に記載されていない場合、Adobe Campaignプラットフォームのすべてのコンポーネントのインストール、更新、メンテナンスは、それらをホストするマシン管理者の責任となります。 これには、Adobe Campaignアプリケーションの前提条件の実装や、コンポーネント間の Campaign 互換性マトリックス への準拠が含まれます。

プレゼンテーションレイヤー

アプリケーションには、ユーザーのニーズに応じて、様々な方法でアクセスできます。リッチクライアント、シンクライアント、API 統合。

  • リッチクライアント:アプリケーションのメインユーザーインターフェイスは、リッチなクライアント、つまり、標準のインターネットプロトコル(SOAP、HTTP など)でのみAdobe Campaignアプリケーションサーバーと通信するネイティブアプリケーション (Windows) です。このコンソールは、生産性を高める優れたユーザーフレンドリー性を提供し、(ローカルキャッシュを使用して)帯域幅をほとんど使用せず、簡単にデプロイできるように設計されています。 このコンソールは、インターネットブラウザーからデプロイでき、自動的に更新でき、HTTP(S) トラフィックのみを生成するので、特定のネットワーク設定は必要ありません。
  • シンクライアント:HTMLのユーザーインターフェイスを使用して、簡単な Web ブラウザーでアクセスできます。レポートモジュール、配信承認ステージ、分散型マーケティングモジュール(セントラル/ローカル)の機能、インスタンスの監視などがあります。このモードを使用すると、イントラネットまたはエクストラネットにAdobe Campaign機能を含めることができます。
  • API を使用した統合:場合によっては、SOAP プロトコルで公開された Web サービス API を使用して、システムを外部アプリケーションから呼び出すことができます。

論理アプリケーション層

Adobe Campaign は、さまざまなアプリケーションを備えたプラットフォームです。それらのアプリケーションを組み合わせて、オープンで拡張性の高いアーキテクチャを構築できます。Adobe Campaignプラットフォームは、柔軟なアプリケーションレイヤーで記述され、企業のビジネスニーズに合わせて簡単に設定できます。 これは、企業のニーズの増大を、機能的な観点から、また技術的な観点からも対応します。 分散型のアーキテクチャであるため、メッセージの処理件数を数千から数百万へ拡張するなど、システムを線形的に拡張できます。

Adobe Campaignは、連携して動作する一連のサーバー側プロセスに依存しています。

主なプロセスは次のとおりです。

アプリケーションサーバー(nlserver web)

このプロセスは、Web サービス API(SOAP - HTTP + XML)経由で、Adobe Campaign のさまざまな機能を公開します。また、HTML ベースでアクセスできるよう、Web ページ(レポート、Web フォームなど)を動的に生成します。そのため、このプロセスには Apache Tomcat JSP サーバーが含まれています。 これは、コンソールが接続するプロセスです。

ワークフローエンジン(nlserver wfserver)

このプロセスは、アプリケーションで定義したワークフローを実行します。

次のような、定期的に実行するテクニカルワークフローも処理します。

  • トラッキング:トラッキングログの復元と統合。リダイレクトサーバーからログを取得し、レポートモジュールで使用する集計インジケーターを作成します。
  • クリーンアップ:データベースのクリーニング。 古いレコードを削除し、データベースが加速度的に肥大化するのを防ぎます。
  • 請求:プラットフォームに関するアクティビティレポートの自動送信(データベースサイズ、マーケティングアクションの数、アクティブなプロファイルの数など)

配信サーバー(nlserver mta)

Adobe Campaign には、メールをブロードキャストする機能がネイティブで備わっています。 このプロセスは、SMTP のメール転送エージェント(MTA)として機能します。メッセージを「一対一」でパーソナライズし、物理的に配信します。 配信ジョブを実行し、自動による再試行も処理します。さらに、トラッキングを有効にすると、URL が自動的に置き換えられ、リダイレクトサーバーを指すようになります。

このプロセスでは、SMS、FAX、ダイレクトメール用に、カスタマイズやサードパーティルータへの自動送信を処理できます。

リダイレクトサーバー(nlserver webmdl)

Adobe Campaign では、メールの開封とクリック追跡を自動的に処理できます(Web サイトレベルでのトランザクショントラッキングについては、今後の課題です)。 これを実現するため、メールメッセージに含まれる URL を書き換えて、このモジュールを指すようにします。このモジュールは、目的の URL にリダイレクトされる前に、そのインターネットユーザーが通過したことを登録します。

高可用性を確保するため、このプロセスはデータベースから独立しています。他のサーバープロセスとの通信には、SOAP 呼び出し(HTTP、HTTP(S) および XML)のみを使用します。 技術的には、この機能は HTTP サーバーの拡張モジュール(IIS の ISAPI 拡張、DSO Apache モジュールなど)に実装されており、Windows でのみ使用できます。

その他の技術的なプロセスも利用できます。

バウンスメールの管理(nlserver inMail)

このプロセスは、配信エラーによって返されたバウンスメッセージを、バウンスメッセージ受信用のメールボックスから自動的に取得します。 バウンスメッセージをルールベースで処理して配信エラーの原因(宛先不明、制限超過など)を特定し、データベース内の配信ステータスを更新します。

これらの動作は事前に設定されており、すべて自動でおこなわれます。

SMS 配信ステータス(nlserver sms)

このプロセスは、SMS ルータをポーリングして進行状況のステータスを収集し、データベースを更新します。

ログメッセージの書き込み(nlserver syslogd)

この技術プロセスは、他のプロセスで生成されたログメッセージとトレースを取得して、ハードディスクに書き込みます。 これにより、問題発生時の診断に使える十分な情報を取得します。

トラッキングログの書き込み (nlserver trackinglogd)

このプロセスは、リダイレクトプロセスによって生成されたトラッキングログをディスクに保存します。

受信イベントの書き込み (nlserver interactiond)

このプロセスは、インタラクションのフレームワークで発生するインバウンドイベントをディスクに記録します。

監視モジュール(nlserver watchodg)

このプロセスは、他の子プロセスを生成するメインプロセスとして機能します。 障害発生時には子プロセスの監視や再開を自動的に行うため、システムの稼働時間を最大限に維持できます。

統計サーバー(nlserver stat)

このプロセスは、接続数、送信メッセージ数(送信先メールサーバー別)、接続や送信の制限値(同時接続数の上限、1 時間あたりや 1 接続あたりのメッセージ数の上限)などの統計情報を保持します。同じパブリック IP アドレスを共有している場合は、複数のインスタンスやマシンを統合することもできます。

メモ

Adobe Campaignモジュールの完全なリストは、このドキュメント 🔗 で入手できます。

永続性レイヤー

データベースは永続性レイヤーとして使用され、Adobe Campaignが管理するほとんどすべての情報が含まれています。 これには、機能データ(プロファイル、購読、コンテンツなど)、技術データ(配信ジョブとログ、トラッキングログなど) および作業データ(購入、リード)

データベースの信頼性は最も重要です。Adobe Campaignコンポーネントの大部分は、タスクを実行するためにデータベースへのアクセスが必要です(リダイレクトモジュールの例外が顕著です)。

プラットフォームには、マーケティング中心のデータマートがあらかじめ定義されているか、主要なリレーショナルデータベース管理システム (RDBMS) のいずれかを使用して、既存のデータマートやスキーマの上に簡単に配置できます。 データマート内のすべてのデータは、Adobe Campaignからデータベースへの SQL 呼び出しを通じて、Adobe Campaignプラットフォームによってアクセスされます。 Adobe Campaign には、ETL(抽出、変換、ロード)ツールを補完する機能も備わっており、システムとの間でのデータの読み込みと書き出しを実行することができます。

このページ