下位互換性規格

Adobe Experience Platform のタグ拡張機能のアップデートには、以前のバージョンの拡張機能との下位互換性が必要です。つまり、

• 拡張機能のメインコンポーネントに対する変更には、以前のバージョンとの互換性が必要です。この中には、拡張機能の設定、イベントタイプ、条件のタイプ、アクションのタイプ、データ要素の型、共有モジュールなどが含まれます。
• 古いバージョンの拡張機能でユーザーが作成したコンポーネントは、新しいバージョンで提供されるスキーマに対する検証に合格する必要があります。
• Adobe Experience Platform ユーザーは、更新されたバージョンの拡張機能をインストールすれば、意図的に変更を加えるまで、それまでにおこなったすべての作業がそのまま継続して機能するはずです。

許可されている変更

拡張機能に対して、次のタイプの変更をおこなうことができます。

1. 新しいコンポーネント（イベントタイプ、条件のタイプなど）を追加できます。
2. 拡張機能の設定に、オプションフィールドを新しく追加できます。
3. 必須フィールドを任意のフィールドに変更できます。

禁止されている変更

次のタイプの変更を、拡張機能に加えることはできません。

1. コンポーネントの名前は変更できません。
2. コンポーネントは削除できません。
3. コンポーネントからフィールドを削除することはできません。
4. 任意のフィールドを必須フィールドに変更することはできません。
5. 新しい必須フィールドは追加できません。
6. 既存の共有モジュールの API は変更できません。

これらの変更を加えると、ユーザーがプロパティに拡張機能をインストールした直後に、次のような問題が発生します。

• いずれかのルールコンポーネントが検索しているコンポーネントが存在していないため、ルールが正しく適用されなくなります
• 拡張機能上に存在しないアップストリームリソースがライブラリに含まれているため、すべてのビルドが失敗します
• ライブラリに含まれているリソースの設定が、新しいスキーマに対する検証に失敗したため、すべてのビルドが失敗します

特に、この 2 つ目のケースでは、ユーザーに改善策がなく、再度公開できるようにプロパティを修正することができません。

機能の削除

正当なビジネス上の理由があり、禁止された変更（上記を参照）が必要と思われる状況があります。現在、これらの変更を加えることはできませんが、代わりに次の操作が可能です。

1. コンポーネントを削除する場合 => 新しいコンポーネントを作成し、古いコンポーネントは廃止します
2. コンポーネントからフィールドを削除する場合 => そのフィールドが削除された新しいコンポーネントを作成し、古いコンポーネントは廃止します
3. 任意のフィールドを必須フィールドに変更する場合 => 目的のフィールドを必須にした新しいコンポーネントを作成し、古いコンポーネントは廃止します
4. 共有モジュールの API を変更する場合 => 新しい共有モジュールを作成し、古い共有モジュールは廃止します

共通のスレッドを使用することもできます。それは良いアイデアです。古いコンポーネントを非推奨（廃止予定）にする場合は、それが非推奨（廃止予定）になり、新しいコンポーネントに切り替える必要があることを拡張機能のユーザーに通知します。次に、ユーザーに通知する際のアドバイスをいくつか示します。

• 古いコンポーネントの表示名を更新して、「（非推奨）」の文字列を含めます。
• 古いコンポーネントの表示を更新し、このコンポーネントが廃止されたこと、および新しいコンポーネントに切り替える必要があることを示す警告テキストを大きな赤い文字で示します。
• モジュールコードを更新して、コンソールに廃止の通知を記録します。この内容はエンドユーザーに表示されることに注意してください。このため、一般的な内容を明確に示します。
• CRM システムからわかりやすい電子メールメッセージを送信します。

古い機能が非推奨になっただけでなく、実際にソリューションに存在しなくなった場合は、もう 1 つ手順を実行します。ただし、この手順は、ユーザーに通知し、更新時間を提供した後におこなってください。

• モジュールの内容を更新し、何の処理も実行しないようにします。こうすると、次のビルドでユーザーがデプロイしたライブラリから機能が削除されますが、ルールが破られたり、ビルドが破壊されることがなくなります。

削除された機能の復元

既に機能を削除しており、その結果として問題が発生しているとユーザーから連絡があった場合は、削除したコンポーネントを復元する新しいバージョンの拡張機能をリリースする必要があります。

前述のように、非推奨の状態に復元することに問題ありませんが、コンポーネントは存在する必要があります。

例として、ユーザーが使用しているコンポーネント XYZ を持つ v1.0 について考えてみます。次に、コンポーネント XYZ が存在しない v1.1 をリリースします。拡張機能によってプロパティが壊れたとユーザから連絡があった場合は、拡張機能を修正する必要があります。機能を再度正常に実行するには、コンポーネント XYZ を復元する v1.2 をリリースし（非推奨ステートにするかはご自身で判断してください）、ユーザーに v1.2 へのアップグレードを促す必要があります。