AEM 6.5 における共通リポジトリの再構築

親ページ（AEM 6.5 のリポジトリ再構築ページ）に記載されているように、AEM 6.5 にアップグレードするユーザーは、このページを使用して、あらゆるソリューションに影響を与える可能性があるリポジトリの変更に関連する作業量を評価する必要があります。一部の変更は AEM 6.5 アップグレードプロセス中に作業が必要ですが、それ以外は今後のアップグレードまで延期できます。

6.5 へのアップグレード時におこなう変更

今後のアップグレードまでにおこなう変更

6.5 へのアップグレード時におこなう変更

ContextHub 設定

AEM 6.4 以降、デフォルトの ContextHub 設定は用意されていません。そのため、サイトのルートレベルで cq:contextHubPathproperty を設定して、どの設定を使用するかを示す必要があります。

  1. サイトのルートに移動します。
  2. ルートページのページのプロパティを開き、「パーソナライズ機能」タブを選択します。
  3. 「ContextHub のパス」フィールドに、独自の ContextHub の設定パスを入力します。

さらに、ContextHub の設定で、sling:resourceType を絶対パスでなく相対パスに更新する必要があります。

  1. CRXDE Lite の ContextHub 設定ノードのプロパティを開きます。例：/apps/settings/cloudsettings/legacy/contexthub
  2. sling:resourceType を /libs/granite/contexthub/cloudsettings/components/baseconfiguration から granite/contexthub/cloudsettings/components/baseconfiguration に変更

ContextHub 設定の sling:resourceType は、絶対パスではなく相対パスであることが必要です。

ワークフローモデル

以前の場所 /etc/workflow/models
新しい場所

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models
再構築の手引き

新規または変更されたワークフローモデルは、/conf/global/workflow/models に移行する必要があります。

  1. 変更したワークフローモデルをローカルの AEM 6.5 開発インスタンスにデプロイし、以前の場所に存在するようにします。
  2. AEM のツール／ワークフロー／モデルで、AEM のワークフローモデルエディターを使用してワークフローモデルを編集します。
  3. 変更された AEM 提供のワークフローモデルを移行する場合
    1. ワークフローモデルエディターを開いて、ブラウザのアドレス URL を変更し、パスセグメント /libs/settings/workflow/models を /etc/workflow/models に置き換えます。
      • 例えば、http://localhost:4502/editor.html/libs/settings/workflow/models/dam/update_asset.html を http://localhost:4502/editor.html/etc/workflow/models/dam/update_asset.html に変更します。
  4. ワークフローモデルエディターで編集モードを有効にします。ワークフローモデル定義が /conf/global/workflow/models にコピーされます。
  5. 「同期」ボタンをタップして、/var/workflow/models 下のランタイムワークフローモデルへの変更を同期します。
  6. ワークフローモデル（/conf/global/workflow/models/<workflow-model>）とランタイムワークフローモデル（/var/workflow/models/<workflow-model>）両方をエクスポートし、AEM プロジェクトに統合します。
    1. 例えば、次のようにエクスポートします。
      • /conf/global/settings/workflow/models/dam/my_workflow_model および
      • /var/workflow/models/dam/my_workflow_model
備考

ワークフローモデルの解決は次の順序でおこなわれます。

  1. /conf/global/settings/workflow/models
  2. /libs/settings/workflow/models
  3. /etc/workflow/models

したがって、以前の場所に保存されていた AEM 提供のワークフローモデルのカスタマイズを保持する場合は /conf/global/settings/workflow/models に移動する必要があります。それ以外の場合は /libs/settings/workflow/models で定義される AEM 提供のワークフローモデルに置き換えられます。

ワークフローインスタンス

以前の場所 /etc/workflow/instances
新しい場所 /var/workflow/instances
再構築の手引き

新しい場所に合わせるための操作は必要ありません。

古いワークフローインスタンスは安全に以前の場所に存在し続け、新しいワークフローインスタンスは新しい場所に作成されます。
備考 custom コード内の以前の場所への明示的なパス参照では、新しい場所も考慮に入れる必要があります。このコードは AEM Workflow API を使用するようにリファクタリングすることをお勧めします。

ワークフローランチャー

以前の場所 /etc/workflow/launcher/config
新しい場所

/libs/settings/workflow/launcher/config

/conf/global/settings/workflow/launcher/config
再構築の手引き

新規または変更されたワークフローランチャーはすべて /conf/global/workflow/launcher/config に移行する必要があります。

  1. 新規または変更されたワークフローランチャーの設定を、以前の場所から新しい場所（/conf/global）にコピーします。
備考

ワークフローランチャーの解決は、次の順序でおこなわれます。

  1. /conf/global/settings/workflow/launcher
  2. /libs/settings/workflow/launcher
  3. /etc/workflow/launcher

そのため、以前の場所に保存されていた AEM 提供のワークフローランチャーのカスタマイズは、保持する場合はすべて新しい場所（/conf/global/settings/workflow/launcher）に移動する必要があります。それ以外の場合は、/libs/settings/workflow/launcher にある AEM 提供のワークフローランチャーの定義に置き換えられます。

ワークフロースクリプト

以前の場所 /etc/workflow/scripts
新しい場所

/libs/workflow/scripts

/apps/workflow/scripts
再構築の手引き

新規または変更されたワークフロースクリプトを新しい場所に移行し、新しい場所を反映するように参照先ワークフローモデルを更新する必要があります。

  1. 新規または変更されたワークフロースクリプトを以前の場所から新しい場所にコピーします。
    • /apps/workflow/scripts SCM で維持する必要があります。
  2. ワークフローモデルの以前の場所にある、ワークフロースクリプトへの参照を更新し、新しい場所を指すようにします。
備考

AEM 6.4 SP1 がリリースされると、この再構築は 6.5 まで延期できるようになります upgrade 。

AEM 6.4 SP1 がリリースされる前に AEM 6.4 にアップグレードする場合、この再構築はアップグレードプロジェクトの一環として実行する必要があります。そうしない場合、以前の場所にあるスクリプトを参照するワークフローステップを編集して保存すると、ワークフローステップからワークフロースクリプト参照が完全に削除され、スクリプト選択ドロップダウンでは新しい場所にあるワークスクリプトのみが使用できるようになります。

今後のアップグレードまでにおこなう変更

ContextHub 設定

以前の場所 /etc/cloudsettings
新しい場所

/libs/settings/cloudsettings

/conf/global/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings
再構築の手引き

新規または変更された ContextHub 設定はすべて新しい場所に移行する必要があり、参照元の AEM Sites ページは新しい場所を反映するように更新する必要があります。

  1. 新規または変更された ContextHub 設定を以前の場所から新しい場所にコピーします。
  2. 該当する AEM 設定を AEM コンテンツ階層と関連付けます。
    1. 「AEM Sites／ページ／ページのプロパティ／詳細タブ／クラウド設定」を使用した AEM Sites のページ階層。
  3. 前述の AEM コンテンツ階層から、移行された従来の ContextHub 設定をすべて解除します。
備考 該当なし

クラシッククラウドサービスデザイン

以前の場所 /etc/designs/cloudservices
新しい場所

/libs/settings/wcm/designs/cloudservices

/apps/settings/wcm/designs/cloudservices
再構築の手引き

SCM で管理されており、実行時にデザインダイアログから書き込まれていないデザインの場合：

  1. デザインを以前の場所から新しい場所（/apps）にコピーします。
  2. を使用して、デザイン内の CSS、JavaScript、静的リソースをクライアントライブラリallowProxy = trueに変換します。
  3. の以前の場所への参照を更新 cq ： designPath プロパティ。
  4. 以前の場所を参照しているページを更新して、新規のクライアントライブラリカテゴリを使用します（これにはページ実装コードの更新が必要です）。
  5. /etc.clientlibs/.. プロキシサーブレットを介したクライアントライブラリの提供を許可するように AEM Dispatcher のルールを更新します。

SCM で管理されていない、デザインダイアログでランタイムを変更したデザイン。

  • オーサリング可能なデザインは /etc から移動しないでください。
備考 該当なし

クラシックダッシュボードデザイン

以前の場所 /etc/designs/dashboards
新しい場所

/libs/settings/wcm/designs/dashboards

/apps/settings/wcm/designs/dashboards
再構築の手引き

SCM で管理されており、実行時にデザインダイアログから書き込まれていないデザインの場合：

  1. デザインを以前の場所から新しい場所（/apps）にコピーします。
  2. を使用して、デザイン内の CSS、JavaScript、静的リソースをクライアントライブラリallowProxy = trueに変換します。
  3. 次の以前の場所への参照を更新 cq ： designPath プロパティ。
  4. 以前の場所を参照しているページを更新して、新規のクライアントライブラリカテゴリを使用します（これにはページ実装コードの更新が必要です）。
  5. /etc.clientlibs/.. プロキシサーブレットを介したクライアントライブラリの提供を許可するように AEM Dispatcher のルールを更新します。

SCM で管理されていない、デザインダイアログでランタイムを変更したデザイン。

  • オーサリング可能なデザインは /etc から移動しないでください。
備考 該当なし

クラシックレポートデザイン

以前の場所 /etc/designs/reports
新しい場所

/libs/settings/wcm/designs/reports

/apps/settings/wcm/designs/reports
再構築の手引き

SCM で管理されており、実行時にデザインダイアログから書き込まれていないデザインの場合：

  1. デザインを以前の場所から新しい場所（/apps）にコピーします。
  2. を使用して、デザイン内の CSS、JavaScript、静的リソースをクライアントライブラリallowProxy = trueに変換します。
  3. 次の以前の場所への参照を更新 cq ： designPath プロパティ。
  4. 以前の場所を参照しているページを更新して、新規のクライアントライブラリカテゴリを使用します（これにはページ実装コードの更新が必要です）。
  5. /etc.clientlibs/.. プロキシサーブレットを介したクライアントライブラリの提供を許可するように AEM Dispatcher のルールを更新します。

SCM で管理されていない、デザインダイアログでランタイムを変更したデザイン。

  • オーサリング可能なデザインは /etc から移動しないでください。
備考 該当なし

デフォルトデザイン

以前の場所 /etc/designs/default
新しい場所

/libs/settings/wcm/designs/default

/apps/settings/wcm/designs/default
再構築の手引き

SCM で管理されており、実行時にデザインダイアログから書き込まれていないデザインの場合：

  1. デザインを以前の場所から新しい場所（/apps）にコピーします。
  2. を使用して、デザイン内の CSS、JavaScript、静的リソースをクライアントライブラリallowProxy = trueに変換します。
  3. 次の以前の場所への参照を更新 cq ： designPath プロパティ。
  4. 以前の場所を参照しているページを更新して、新規のクライアントライブラリカテゴリを使用します（これにはページ実装コードの更新が必要です）。
  5. /etc.clientlibs/.. プロキシサーブレットを介したクライアントライブラリの提供を許可するように AEM Dispatcher のルールを更新します。

SCM で管理されていない、デザインダイアログでランタイムを変更したデザイン。

  • オーサリング可能なデザインは /etc から移動しないでください。
備考 該当なし

Adobe DTM JavaScript エンドポイント

以前の場所 /etc/clientlibs/dtm
新しい場所 /var/cq/dtm/clientlibs
再構築の手引き

アクションは必要ありません。

公開されている以前の場所は、プライベートの新しい場所のプロキシエンドポイントとして機能します。
備考 該当なし

Adobe DTM Web-Hook エンドポイント

以前の場所 /etc/dtm-hook
新しい場所 /var/cq/dtm/web-hook
再構築の手引き

アクションは必要ありません。

公開されている以前の場所は、プライベートの新しい場所のプロキシエンドポイントとして機能します。
備考 該当なし

インボックスタスク

以前の場所 /etc/taskmanagement
新しい場所 /var/taskmanagement
再構築の手引き インボックスのパージメンテナンスタスクを使用して、必要に応じて以前の場所から古いタスクを削除します。
備考

タスクを新しい場所に移行するための操作は必要ありません。

  • 以前の場所にあるタスクは引き続き使用でき、機能します。
  • 新しい場所に新しいタスクが作成されます。

マルチサイトマネージャーのブループリント設定

以前の場所 /etc/blueprints
新しい場所

/libs/msm

/apps/msm
再構築の手引き
  1. カスタム設定を /etc/blueprints から /apps/msm にコピーします。
  2. 削除 /etc/blueprints.
備考 該当なし

AEM プロジェクトダッシュボードガジェット設定

以前の場所 /etc/projects/dashboard/gadgets
新しい場所

/libs/cq/core/content/projects/dashboard/gadgets

/apps/cq/core/content/projects/dashboard/gadgets
再構築の手引き

新規または変更された AEM プロジェクトのダッシュボードガジェット設定は、新しい場所（/apps）に移行する必要があります。

  1. 新規または変更された AEM プロジェクトのダッシュボードガジェット設定を、以前の場所から新しい場所（/apps）にコピーします。
    1. 変更されていない AEM プロジェクトのダッシュボードガジェット設定は新しい場所（/libs）に存在するため、コピーしないでください。
  2. 以前の場所を参照する AEM プロジェクトテンプレートを適切な新しい場所を指すように更新します。
備考 AEM 6.4 互換パッケージが適用されている場合は、互換パッケージの削除時にリポジトリ調整アクティビティを実行する必要があります。

レプリケーション通知メールテンプレート

以前の場所 /etc/notification/email/default/com.day.cq.replication
新しい場所

/libs/settings/notification-templates/com.day.cq.replication

/apps/settings/notification-templates/com.day.cq.replication
再構築の手引き

新規または変更されたレプリケーション通知のメールテンプレートは、新しい場所（/apps）に移行する必要があります。

  1. 新規または変更されたレプリケーション通知のメールテンプレートを、以前の場所から新しい場所（/apps）にコピーします。
  2. 移行されたすべてのレプリケーション通知メールテンプレートを以前の場所から削除します。
備考

サポートされている唯一の新規レプリケーション通知電子メールテンプレートは、新しいロケールをサポートするものです。

レプリケーション通知電子メールテンプレートの解決は次の順序でおこなわれます。

  1. /etc/notification/email/default/com.day.cq.replication
  2. /apps/settings/notification-templates/com.day.cq.replication
  3. /libs/settings/notification-templates/com.day.cq.replication

タグ

以前の場所 /etc/tags
新しい場所 /content/cq:tags
再構築の手引き

すべてのタグは /content/cq:tags に移行する必要があります。

  1. 以前の場所から新しい場所にすべてのタグをコピーします。
  2. 以前の場所からすべてのタグを削除します。
  3. AEM web コンソールから、https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging にある Day Communique 5 Tagging OSGi バンドルを再起動し、新しい場所にコンテンツが含まれ、それらを使用する必要があることを AEM が認識できるようにします。
備考

Day Communique Tagging OSGi バンドルを再起動しても、以前の場所が空であれば、新しい場所がタグのルートとして登録されるだけです。

AEM の TagManager API を活用シてタグを解決するすべての機能については、新しい場所に移行した後も、以前の場所への参照は引き続き機能します。

パス /etc/tags を明示的に参照するカスタムコードは、/content/ に更新する必要があります。 cq :tags 、あるいは、この移行と並行して TagManager Java API を活用するように書き直すことをお勧めします。

翻訳 Cloud Services

以前の場所 /etc/cloudservices/translation
新しい場所

/libs/settings/cloudconfigs/translation/translationcfg

/apps/settings/cloudconfigs/translation/translationcfg

/conf/global/settings/cloudconfigs/translation/translationcfg

/conf/<tenant>/settings/cloudconfigs/translation/translationcfg
再構築の手引き

新規の翻訳クラウドサービスは、すべて新しい場所（/apps、/conf/global または /conf/<tenant>）に移行する必要があります。

  1. 以前の場所にある既存の設定を新しい場所に移行します。
    • ツール／クラウドサービス／翻訳クラウドサービスの AEM オーサリング UI を使用して、新規の翻訳クラウドサービス設定を手動で再作成します。
      または
    • 新規の翻訳クラウドサービス設定を、以前の場所から新しい場所（/apps、/conf/global または /conf/<tenant>）にコピーします。
  2. 該当する AEM 設定を AEM コンテンツ階層と関連付けます。
    1. 「AEM Sites／ページ／ページのプロパティ／詳細タブ／クラウド設定」を使用した AEM Sites のページ階層。
    2. 「AEM エクスペリエンスフラグメント／エクスペリエンスフラグメント／プロパティ／クラウドサービスタブ／クラウド設定」を使用した AEM エクスペリエンスフラグメント階層。
    3. 「AEM エクスペリエンスフラグメント／フォルダー／プロパティ／クラウドサービスタブ／クラウド設定」を使用した AEM エクスペリエンスフラグメントフォルダー階層。
    4. AEM Assets／フォルダー／フォルダーのプロパティ／クラウドサービスタブ／設定を使用した AEM Assets フォルダー階層。
    5. AEM プロジェクト／プロジェクト／プロジェクトのプロパティ／詳細タブ／クラウド設定を使用した AEM プロジェクト。
  3. 前述の AEM コンテンツ階層から、移行された従来の翻訳クラウドサービスとの関連付けをすべて解除します。
備考

翻訳クラウドサービスの解決は次の順序でおこなわれます。

  1. /conf/<tenant>/settings/cloudconfigs/translations/translationcfg
  2. /conf/global/settings/cloudconfigs/translations/translationcfg
  3. /apps/settings/cloudconfigs/translations/translationcfg
  4. /libs/settings/cloudconfigs/translations/translationcfg

移行された翻訳クラウドサービスはAEM 6.4 と互換性がある必要があります。

翻訳言語

以前の場所 /etc/translation/supportedLanguages
新しい場所

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages
再構築の手引き

新規または変更された翻訳言語の定義は、すべての翻訳言語の定義を新しい場所（/apps）に移行する必要があります。

  1. 翻訳言語の定義に追加または変更を加えた場合は、すべての翻訳言語の定義を以前の場所から新しい場所（/apps）にコピーします。
備考

翻訳言語のパス解決は次の順序でおこなわれます。

  1. /etc/translation/supportedLanguages
  2. /apps/settings/translation/supportedLanguage
  3. /libs/settings/translation/supportedLanguages

この解決方法はマージオーバーレイをサポートしていません。つまり、解決されたパスにはすべてのサポート言語が含まれている必要があり、高次の解決方法からサポート言語を継承することはありません。

翻訳ルール

以前の場所 /etc/workflow/models/translation/translation_rules.xml
新しい場所

/libs/settings/translation/rules/translation_rules.xml

/apps/settings/translation/rules/translation_rules.xml

/conf/global/settings/translation/rules/translation_rules.xml
再構築の手引き

変更した翻訳ルールの XML ファイルは、新しい場所（/apps または /conf/global）に移行する必要があります。

1. 変更した 翻訳ルール XML ファイルを以前の場所から新しい場所にコピーします。
備考

レプリケーション翻訳ルール XML の解決は次の順序でおこなわれます。

  1. /conf/global/settings/translation/rules/translation_rules.xml
  2. /apps/settings/translation/rules/translation_rules.xml
  3. /etc/workflow/models/translation/translation_rules.xml
  4. /libs/settings/translation/rules/translation_rules.xml

翻訳 Widget クライアントライブラリ

以前の場所 /etc/designs/translation/translationwidget
新しい場所

/libs/settings/wcm/designs/translation/translationwidget

/apps/settings/wcm/designs/translation/translationwidget
再構築の手引き

SCM で管理されており、実行時にデザインダイアログから書き込まれていないデザインの場合：

  1. デザインを以前の場所から新しい場所（/apps）にコピーします。
  2. を使用して、デザイン内の CSS、JavaScript、静的リソースをクライアントライブラリallowProxy = trueに変換します。
  3. 次の以前の場所への参照を更新 cq ： designPath プロパティ。
  4. 以前の場所を参照しているページを更新して、新規のクライアントライブラリカテゴリを使用します（これにはページ実装コードの更新が必要です）。
  5. /etc.clientlibs/.. プロキシサーブレットを介したクライアントライブラリの提供を許可するように AEM Dispatcher のルールを更新します。

SCM で管理されていない、デザインダイアログでランタイムを変更したデザイン。

  • オーサリング可能なデザインは /etc から移動しないでください。
備考 該当なし

ツリー Activation Web コンソール

以前の場所 /etc/replication/treeactivation
新しい場所 /libs/replication/treeactivation
再構築の手引き アクションは必要ありません。
備考 ツリー Activation Web コンソールは、ツール／導入／レプリケーション／ツリーをアクティベート​から利用できます。

ベンダー翻訳コネクタクラウドサービス

以前の場所 /etc/cloudservices/<vendor>
新しい場所

/libs/settings/cloudconfigs/translation/<vendor>

/apps/settings/cloudconfigs/translation/<vendor>

/conf/global/settings/cloudconfigs/translation/<vendor>

/conf/<tenant>/settings/cloudconfigs/translation/<vendor>
再構築の手引き

新規のベンダー翻訳コネクターのクラウドサービスは、すべて新しい場所（/apps、/conf/global または /conf/<tenant>）に移行する必要があります。

  1. 以前の場所にある既存の設定を新しい場所に移行します。
    • ツール／クラウドサービス／翻訳クラウドサービスの AEM オーサリング UI を使用して、新しいベンダー翻訳コネクタクラウドサービス設定を手動で作成します。
      または
    • 新規のベンダー翻訳コネクターのクラウドサービス設定を、以前の場所から新しい場所（/apps、/conf/global または /conf/<tenant>）にコピーします。
  2. 該当する AEM 設定を AEM コンテンツ階層と関連付けます。
    1. 「AEM Sites／ページ／ページのプロパティ／詳細タブ／クラウド設定」を使用した AEM Sites のページ階層。
    2. 「AEM エクスペリエンスフラグメント／エクスペリエンスフラグメント／プロパティ／クラウドサービスタブ／クラウド設定」を使用した AEM エクスペリエンスフラグメント階層。
    3. 「AEM エクスペリエンスフラグメント／フォルダー／プロパティ／クラウドサービスタブ／クラウド設定」を使用した AEM エクスペリエンスフラグメントフォルダー階層。
    4. AEM Assets／フォルダー／フォルダーのプロパティ／クラウドサービスタブ／設定を使用した AEM Assets フォルダー階層。
    5. AEM プロジェクト／プロジェクト／プロジェクトのプロパティ／詳細タブ／クラウド設定を使用した AEM プロジェクト。
  3. 前述の AEM コンテンツ階層から、移行された従来の翻訳クラウドサービスとの関連付けをすべて解除します。
備考

翻訳クラウドサービスの解決は次の順序でおこなわれます。

  1. /conf/<tenant>/settings/cloudconfigs/translations/<vendor>
  2. /conf/global/settings/cloudconfigs/translations/<vendor>
  3. /apps/settings/cloudconfigs/translations/<vendor>
  4. /libs/settings/cloudconfigs/translations/<vendor>

ワークフロー通知メールテンプレート

以前の場所 /etc/workflow/notification
新しい場所

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification
再構築の手引き

変更されたワークフロー通知のメールテンプレートは、すべて新しい場所（/conf/global）に移行する必要があります。

  1. 変更されたワークフロー通知電子メールテンプレートを以前の場所から新しい場所にコピーします。
  2. 移行されたワークフロー通知電子メールテンプレートを以前の場所から削除します。
備考

ワークフロー通知メールテンプレートの解決は、次の順序でおこなわれます。

  1. /etc/workflow/notification
  2. /conf/global/settings/workflow/notification
  3. /libs/settings/workflow/notification

ワークフローパッケージ

以前の場所 /etc/workflow/packages
新しい場所 /var/workflow/packages
再構築の手引き

以前の場所にある既存のワークフローパッケージは、新しい場所に移行する必要があります。

  1. 以前の場所にある、他のコンテンツによって参照されていない、または不要なワークフローパッケージを削除します。
  2. 以前の場所にある、他のコンテンツによって参照されていないものの、必要とされているワークフローパッケージを新しい場所に移動します。
  3. 他のコンテンツによって参照されているワークフローパッケージはすべて以前の場所に残します。
備考

クラシック UI の Miscadmin コンソールで作成されたワークフローパッケージは以前の場所に保持されますが、他のものはすべて新しい場所に保持されます。

以前の場所または新しい場所に保存されているワークフローパッケージは、クラシック UI の Miscadmin コンソールで管理できます。

このページ