拡張機能の開発の概要

Adobe Experience Platform Launch の主な目標の 1 つは、主要な Platform Launch エンジニアチーム以外のエンジニアが、Platform Launch を通じて追加機能を公開できるオープンなエコシステムを構築することです。 これには、Reactor の拡張機能を使用します。 拡張機能がユーザーによって Platform Launch プロパティにインストールされると、そのプロパティのすべてのユーザーがその拡張機能を使用できるようになります。

このドキュメントでは、様々な拡張機能タイプの主要コンポーネントの概要を示し、拡張機能の開発プロセスについて説明するその他のドキュメントへのリンクを提供しています。

ライブラリモジュール

ライブラリモジュールは、Platform Launch ランタイムライブラリ内で発行される拡張機能によって提供される再利用可能なコードです。 web 拡張機能とエッジ拡張機能のどちらを開発しているかによって、使用できるモジュールのタイプとそのユースケースは異なります。各拡張機能タイプのモジュールの概要については、以下のサブセクションを参照してください。

web 拡張機能のモジュール

web 拡張機能では、ルールはイベントを介してトリガーされます。その後、特定の条件が満たされた場合に、特定のアクションを実行できます。詳しくは、](./web/flow.md)web 拡張機能のモジュールフロー[の概要を参照してください。

アドビが提供するコアモジュールに加えて、web 拡張機能では次のライブラリモジュールタイプを定義できます。

メモ

web 拡張機能にライブラリモジュールを実装するための必要な形式について詳しくは、モジュール形式の概要を参照してください。

イベントタイプ

ルールイベントとは、ルールが起動する前に必要なアクティビティです。

例えば、拡張機能は、特定のマウスまたはタッチジェスチャーが発生するのを監視する「ジェスチャー」イベントタイプを提供できます。 このジェスチャーが発生すると、イベントロジックによってルールが実行されます。

通常、イベントタイプは、(1)Platform Launch アプリケーション内のビュー(ユーザーがイベントの設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、特定のアクティビティが発生するのを監視する)で構成されます。

詳細情報

条件タイプ

ルール条件は、ルールイベントの発生後に評価されます。 ルールの処理を続行するには、すべての条件が true を返す必要があります。 例外として、ユーザーが「例外」バケットに条件を明示的に配置した場合があります。この場合、ルールの処理を続行するには、バケット内のすべての条件が false を返す必要があります。

例えば、拡張機能には「viewport contains」条件タイプを指定できます。この条件タイプでは、Platform Launch のユーザーが CSS セレクターを指定できます。 この条件がクライアントの Web サイトで評価されると、拡張機能は、CSS セレクターに一致する要素を見つけ出し、その要素のいずれかがユーザーのビューポート内に含まれているかどうかを返すことができます。

通常、条件タイプは、(1)Platform Launch アプリケーション内のビュー(ユーザーが条件の設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、条件を評価する)で構成されます。

詳細情報

アクションタイプ

ルールアクションとは、ルールイベントが発生し、条件が評価を渡した後に実行される操作です。

例えば、拡張機能で「show support chat」アクションタイプを提供すると、サポートチャットダイアログを表示して、チェックアウトに苦労しているユーザーを支援できます。

通常、アクションタイプは、(1)Platform Launch アプリケーション内のビュー(ユーザーがアクションの設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、アクションを実行する)で構成されます。

詳細情報

データ要素タイプ

データ要素は、基本的には、クエリ文字列パラメーター、Cookie、DOM 要素などの場所にデータが存在するかどうかに関係なく、ページ上のデータに対するエイリアスです。 データ要素は、ルールから参照でき、これらのデータにアクセスするための抽象型として機能します。 将来的にデータの場所が変化する場合(DOM 要素の innerHTML から JavaScript 変数の値に変化するなど)は、1 つのデータ要素を再設定できますが、そのデータ要素を参照するすべてのルールが変更されない可能性があります。

データ要素タイプを使用すると、ユーザーはデータ要素を設定して、特定の方法でデータにアクセスできます。 例えば、拡張機能には「local storage item」データ要素タイプを指定できます。ここで、Platform Launch のユーザーは、ローカルストレージアイテム名を指定できます。 データ要素がルールで参照される場合、拡張機能では、ユーザーがデータ要素の設定時に指定したローカルストレージアイテム名を使用して、ローカルストレージアイテムの値を検索できます。

通常、データ要素タイプは、(1)Platform Launch アプリケーション内の表示(ユーザーがデータ要素の設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、データを取得する)で構成されます。

詳細情報

共有モジュール

共有モジュールは、1 つの拡張機能によって公開され、別の拡張機能によってアクセスされるモジュールです。 これは、拡張機能間で通信する際に非常に役立つメカニズムです。 例えば、拡張機能 A はデータを非同期的に読み込み、promise を介して拡張機能 B で使用できるようにします。

共有モジュールは、他の拡張機能内から呼び出されることがない場合でもライブラリに含まれます。 ライブラリのサイズを不必要に大きくしないようにするには、共有モジュールとして公開する内容に注意する必要があります。

共有モジュールにはビューコンポーネントはありません。

詳細情報

エッジ拡張機能のモジュール

エッジ拡張機能では、条件チェックを通じてルールがトリガーされ、チェックが合格すると、特定のアクションが実行されます。詳しくは、エッジ拡張機能のモジュールフローの概要を参照してください。

Edge 拡張機能では、独自のライブラリモジュールを定義できます。これらは、次のタイプに分類できます。

メモ

エッジ拡張機能にライブラリモジュールを実装するための必要な形式について詳しくは、モジュール形式の概要に関するページを参照してください。

条件タイプ

ルール条件は、ルールイベントの発生後に評価されます。 ルールの処理を続行するには、すべての条件が true を返す必要があります。 例外として、ユーザーが「例外」バケットに条件を明示的に配置した場合があります。この場合、ルールの処理を続行するには、バケット内のすべての条件が false を返す必要があります。

例えば、拡張機能には「viewport contains」条件タイプを指定できます。この条件タイプでは、Platform Launch のユーザーが CSS セレクターを指定できます。 この条件がクライアントの Web サイトで評価されると、拡張機能は、CSS セレクターに一致する要素を見つけ出し、その要素のいずれかがユーザーのビューポート内に含まれているかどうかを返すことができます。

通常、条件タイプは、(1)Platform Launch アプリケーション内のビュー(ユーザーが条件の設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、条件を評価する)で構成されます。

詳細情報

アクションタイプ

ルールアクションとは、ルール条件が評価を渡した後に実行される操作です。

例えば、拡張機能で「show support chat」アクションタイプを提供すると、サポートチャットダイアログを表示して、チェックアウトに苦労しているユーザーを支援できます。

通常、アクションタイプは、(1)Platform Launch アプリケーション内のビュー(ユーザーがアクションの設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、アクションを実行する)で構成されます。

詳細情報

データ要素タイプ

データ要素は、基本的には、ページ上のデータの断片に対するエイリアスです。サーバーが受信したイベント内のどこにデータがあったかは関係ありません。データ要素は、ルールから参照でき、これらのデータにアクセスするための抽象型として機能します。 将来的にデータの場所が変更された場合(値を含むイベントキーが変更される場合など)は、1 つのデータ要素を再設定すると同時に、そのデータ要素を参照するすべてのルールを変更せず残すことができます。

通常、データ要素タイプは、(1)Platform Launch アプリケーション内の表示(ユーザーがデータ要素の設定を変更できる)と(2)Platform Launch ランタイムライブラリ内で生成されるライブラリモジュール(設定を解釈し、データを取得する)で構成されます。

詳細情報

拡張機能の設定

拡張機能の設定では、ユーザーからグローバル設定を収集する方法を指定します。例えば、ユーザーがビーコン送信アクションを使用してビーコンを送信でき、ビーコンには常にアカウント ID が含まれている必要がある拡張機能があるとします。 「ビーコンを送信」アクションを設定するたびにアカウント ID を尋ねられるという煩わしい体験をユーザーにさせたくはありません。代わりに、拡張機能の設定表示から、アカウント ID を 1 回だけ要求します。ビーコンが送信されるたびに、「ビーコンを送信」アクションのライブラリモジュールで拡張機能設定からアカウント ID を取得し、ビーコンに追加できます。

ユーザーが Platform Launch プロパティに拡張機能をインストールすると、拡張機能の設定表示が表示されます。 拡張機能のインストールを完了するには、拡張機能の設定を完了する必要があります。

拡張機能の設定は、ビューコンポーネントで構成されます。このコンポーネントは、設定を書き出し、Platform Launch ランタイムライブラリ内でプレーンオブジェクトとして生成します。

詳細情報

拡張機能の構造

拡張機能は、ファイルのディレクトリで構成されます。 これらのファイルの構造の概要を次に示します。 ファイルの内容について詳しくは、他の節を参照してください。

extension.json ファイルは、ディレクトリのルートに存在する必要があります。 このファイルは、特に、拡張機能の構成と、特定のファイルを格納するディレクトリ内の場所を記述します。 これは、npmpackage.json ファイルに似ています。

各ライブラリモジュール(Platform Launch ランタイムライブラリ内で生成されるロジック)は、CommonJS モジュール標準に準拠した内容を持つ独自のファイルである必要があります。 例えば、「ビーコンを送信」アクションタイプを作成する場合、ビーコンを送信するロジックを含むファイルが必要です。このファイルの内容は、Platform Launch ランタイムライブラリ内で生成されます。ファイルには、sendBeacon.js などの名前を付けます。extension.json がファイルの場所を記述するため、ディレクトリ内のファイルの場所は重要ではありません。

各表示は、Platform Launch アプリケーション内の iframe に読み込むことができる HTML ファイルである必要があります。 アプリケーションと通信するには、Platform Launch で指定されるスクリプトがビューに含まれ、小さな API に対応している必要があります。ビュー内で使用するライブラリに関して制限はありません。 つまり、jQuery、Underscore、React、Angular、Bootstrap、または他のライブラリを使用できます。 ただし、拡張機能は、アプリケーションと同じようなルックアンドフィールを備えている必要があります。

すべての表示関連ファイル(HTML、CSS、JavaScript)は、ライブラリモジュールファイルから分離された 1 つのサブディレクトリ内に配置することをお勧めします。 extension.json には、このビューサブディレクトリの場所を記述します。 その後、Launch は、Web サーバーからこのサブディレクトリ(このサブディレクトリのみ)を提供します。

このページ

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now