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. 例えば、次のようにエクスポートします。
      • /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 にアップグレードする場合、この再構築はアップグレードプロジェクトの一環として実行する必要があります。そうしない場合、以前の場所にあるスクリプトを参照するワークフローステップを編集して保存すると、ワークフローステップからワークフロースクリプト参照が完全に削除され、スクリプト選択ドロップダウンでは新しい場所にあるワークスクリプトのみが使用できるようになります。

今後のアップグレードの前

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
再構築の手引き インボックスのパージメンテナンスタスクを使用して、必要に応じて以前の場所から古いタスクを削除します。
備考

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

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

Multi-site Manager のブループリント設定

以前の場所 /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

再構築の手引き

新しい翻訳Cloud Servicesは、新しい場所(/apps/conf/globalまたは/conf/<tenant>)に移行する必要があります。

  1. 以前の場所にある既存の設定を新しい場所に移行します。
    • ツール/クラウドサービス/翻訳クラウドサービスの AEM オーサリング UI を使用して、新規の翻訳クラウドサービス設定を手動で再作成します。
      または
    • 新しい翻訳Cloud Servicesの設定を以前の場所から新しい場所(/apps/conf/global/conf/<tenant>)にコピーします。
  2. 該当する AEM 設定を AEM コンテンツ階層と関連付けます。
    1. AEM Sites/ページ/ページのプロパティ/詳細タブ/クラウド設定」を使用した AEM Sites のページ階層。
    2. AEM エクスペリエンスフラグメント/エクスペリエンスフラグメント/プロパティ/クラウドサービスタブ/クラウド設定」を使用した AEM エクスペリエンスフラグメント階層。
    3. AEM エクスペリエンスフラグメント/フォルダー/プロパティ/クラウドサービスタブ/クラウド設定」を使用した AEM エクスペリエンスフラグメントフォルダー階層。
    4. AEM Assets/フォルダー/フォルダーのプロパティ/「Cloud Services」タブ/「設定」を使用したAEM Assetsフォルダー階層。
    5. AEM Projects/Project/Project Properties/Advanced Tab/Cloud Configurationを使用した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>

再構築の手引き

新しいベンダー翻訳コネクタCloud Servicesは、すべて新しい場所(/apps/conf/globalまたは/conf/<tenant>)に移行する必要があります。

  1. 以前の場所にある既存の設定を新しい場所に移行します。
    • ツール/クラウドサービス/翻訳クラウドサービスの AEM オーサリング UI を使用して、新しいベンダー翻訳コネクタクラウドサービス設定を手動で作成します。
      または
    • 新しいベンダー翻訳コネクタCloud Services設定を以前の場所から新しい場所(/apps/conf/global または/conf/<tenant>)にコピーします。
  2. 該当する AEM 設定を AEM コンテンツ階層と関連付けます。
    1. AEM Sites/ページ/ページのプロパティ/詳細タブ/クラウド設定」を使用した AEM Sites のページ階層。
    2. AEM エクスペリエンスフラグメント/エクスペリエンスフラグメント/プロパティ/クラウドサービスタブ/クラウド設定」を使用した AEM エクスペリエンスフラグメント階層。
    3. AEM エクスペリエンスフラグメント/フォルダー/プロパティ/クラウドサービスタブ/クラウド設定」を使用した AEM エクスペリエンスフラグメントフォルダー階層。
    4. AEM Assets/フォルダー/フォルダーのプロパティ/「Cloud Services」タブ/「設定」を使用したAEM Assetsフォルダー階層。
    5. AEM Projects/Project/Project Properties/Advanced Tab/Cloud Configurationを使用した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 コンソールで管理できます。

このページ