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

注意

AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

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

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

6.5 へのアップグレード前

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

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.4 開発インスタンスにデプロイし、以前の場所に存在するようにします。
  2. AEM/ツール/ワークフロー/モデルで、AEM Workflow Model Editor を使用してワークフローモデルを編集します。
  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>?lang=ja) とランタイムワークフローモデル (/var/workflow/models/<workflow-model>?lang=ja) をクリックし、AEMプロジェクトに統合します。
    1. 例えば、次のように書き出します。
      • /config/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 にアップグレードする場合は、この再構築をアップグレードプロジェクトの一部として実行する必要があります。 これをおこなわない場合は、前の場所でスクリプトを参照するワークフローステップを編集して保存すると、ワークフローステップからワークフロースクリプトの参照が完全に削除され、スクリプトの選択ドロップダウンで使用できるのは新しい場所のワークフロースクリプトのみです。

6.5 へのアップグレード前

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. 移行済みの従来の ContextHub 設定を、前述のAEMコンテンツ階層からすべて関連付け解除します。
備考 該当なし

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

以前の場所 /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?lang=ja) にコピーします。
  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?lang=ja) にコピーします。
  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?lang=ja) にコピーします。
  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( ) で新しい翻訳Cloud Services設定を手動で再作成します。 ツール/Cloud Services/翻訳Cloud Services.
      または
    • 新規の翻訳クラウドサービス設定を、以前の場所から新しい場所（/apps、/conf/global または /conf/<tenant>）にコピーします。
  2. 該当するAEM設定をAEMコンテンツ階層に関連付けます。
    1. AEM Sites経由のページ階層 AEM Sites /ページ/ページのプロパティ/「詳細」タブ/クラウド設定.
    2. を使用したエクスペリエンスフラグメント階層のAEM AEMエクスペリエンスフラグメント/エクスペリエンスフラグメント/プロパティ/Cloud Servicesタブ/クラウド設定.
    3. を使用したエクスペリエンスフラグメントフォルダー階層のAEM AEMエクスペリエンスフラグメント/フォルダー/プロパティ/「Cloud Services」タブ/クラウド設定.
    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

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

SCM で管理されず、デザインダイアログを介して実行時に変更されたすべてのデザイン。

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

ツリー Activation Web コンソール

以前の場所 /etc/replication/treeactivation
新しい場所 /libs/replication/treeactivation
再構築の手引き アクションは不要です。
備考 ツリーアクティベーション 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. 以前の場所の既存の設定を新しい場所に移行します。
    • 新しいベンダー翻訳コネクタCloud Servicesを ツール/Cloud Services/翻訳Cloud ServicesのAEMオーサリング UI.
      または
    • 新規のベンダー翻訳コネクターのクラウドサービス設定を、以前の場所から新しい場所（/apps、/conf/global または /conf/<tenant>）にコピーします。
  2. 該当するAEM設定をAEMコンテンツ階層に関連付けます。
    1. AEM Sites経由のページ階層 AEM Sites /ページ/ページのプロパティ/「詳細」タブ/クラウド設定.
    2. を使用したエクスペリエンスフラグメント階層のAEM AEMエクスペリエンスフラグメント/エクスペリエンスフラグメント/プロパティ/Cloud Servicesタブ/クラウド設定.
    3. を使用したエクスペリエンスフラグメントフォルダー階層のAEM AEMエクスペリエンスフラグメント/フォルダー/プロパティ/「Cloud Services」タブ/クラウド設定.
    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 コンソールで管理できます。

このページ