/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

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

1. 変更したワークフローモデルをローカルの AEM 6.5 開発インスタンスにデプロイし、以前の場所に存在するようにします。
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. 例えば、次のように書き出します。
      • /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提供のワークフローモデル定義に置き換えられます。

新しい位置に合わせるためのアクションは必要ありません。

過去のワークフローインスタンスは、以前の場所に安全に存在し続けることができ、新しいワークフローインスタンスは新しい場所に作成されます。

/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 提供のワークフローランチャーの定義に置き換えられます。

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

/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コンテンツ階層からすべて関連付け解除します。

/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 から移動しないでください。

/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 から移動しないでください。

/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 から移動しないでください。

/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 から移動しないでください。

アクションは不要です。

パブリックの以前の場所は、プライベートの新しい場所のプロキシエンドポイントとして機能します。

アクションは不要です。

パブリックの以前の場所は、プライベートの新しい場所のプロキシエンドポイントとして機能します。

タスクを新しい場所に移行する際に必要なアクションはありません。

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

/libs/msm

/apps/msm

1. カスタム設定を /etc/blueprints から /apps/msm にコピーします。
2. 削除 /etc/blueprints.

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

/apps/cq/core/content/projects/dashboard/gadgets

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

1. 新規または変更された AEM プロジェクトのダッシュボードガジェット設定を、以前の場所から新しい場所（/apps）にコピーします。
   1. 変更されていない AEM プロジェクトのダッシュボードガジェット設定は新しい場所（/libs）に存在するため、コピーしないでください。
2. 以前の場所を参照する AEM プロジェクトテンプレートを適切な新しい場所を指すように更新します。

/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

すべてのタグは /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 を使用するように書き直すことをお勧めします。

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

/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

この解決方法では、オーバーレイの結合はサポートされません。つまり、解決されたパスにはすべてのサポート対象言語が含まれている必要があり、上位の解像度からサポート対象言語が継承されません。

/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

/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 から移動しないでください。

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

/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

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

1. 以前の場所にある、他のコンテンツで参照されていない、それ以外の必要のないワークフローパッケージを削除します。
2. 他のコンテンツで参照されていないが、別の場所で必要な以前の場所に、ワークフローパッケージを移動します。
3. 他のコンテンツによって参照されているワークフローパッケージは、前の場所に残します。

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

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