現在表示中:

ここでは、AEM インストールの AEM 6.3 へのアップグレードについて説明します。

この手順に出てくる AEM インスタンスをわかりやすく区別するために、以下のように呼ぶことにします。

  • アップグレード元の AEM インスタンスを「ソース」インスタンスと呼びます。
  • アップグレード先のインスタンスを「ターゲット」インスタンスと呼びます。

注意:

アップグレードを実行したら、ContextHub 設定を復元する必要があります。

アップグレードのプランニング

AEM のアップグレードは広範にわたる作業です。デプロイメントの規模に応じて、アップグレードを確実に成功させるためのプランニングが必要になります。詳しくは、アップグレードの計画を参照してください。

JAR ベースインストールのアップグレード手順

注意:

準備手順を開始する前に、まず java -jar aem-quickstart.jar コマンドを使用して、ソースインスタンスを実行します。これは、quickstart.properties ファイルを正しく生成するために必要な手順です。このファイルがないと、アップグレードはうまくいきません。

あるいは、ソースインスタンスのインストールフォルダーの crx-quickstart/conf の下を探して、このファイルが存在するかどうかを確認します。

アップグレード前のメンテナンス最適化

AEM で可能なカスタマイズのレベルにより、通常、アップグレードの実行方法は環境によって異なります。そのため、標準化されたアップグレード手順を作成することは簡単ではありません。

以前のバージョンでは、停止された AEM アップグレードまたは失敗した AEM アップグレードを安全に再開することも困難でした。そのため、完全なアップグレード手順を再度開始する必要があったり、不完全なアップグレードが警告なしでおこなわれたりしました。

これらの問題に対応するために、アドビは複数の拡張機能をアップグレードプロセスに追加して、アップグレードプロセスの回復性を高め、使いやすくしました。以前は手動で実行する必要があったアップグレード前のメンテナンスタスクを最適化および自動化する開発作業がおこなわれています。また、問題を簡単に見つけてプロセスを完全に調べられるように、アップグレード後のレポートが追加されました。

アップグレード前のメンテナンスタスクは、現在、部分的または完全に手動で実行する様々なインターフェイスに別れています。AEM 6.3 に追加されたアップグレード前のメンテナンス最適化では、統一された方法でこれらのタスクをトリガーして、その結果をオンデマンドで調査できます。

アップグレード前の最適化手順に含まれているすべてのタスクは、AEM 6.0 以降のすべてのバージョンと互換性があります。

設定方法

AEM 6.3 では、アップグレード前のメンテナンス最適化タスクはクイックスタートに含まれています。AEM 6 の以前のバージョンの場合は、パッケージマネージャーからダウンロードできる別のパッケージから使用できます。

パッケージは以下の場所にあります。

使用方法

PreUpgradeTasksMBean OSGI コンポーネントは、アップグレード前のメンテナンスタスクのリストで事前設定されており、それらのすべてのタスクを一度に実行できます。以下の手順に従ってタスクを設定できます。

  1. Web コンソールに移動します(http://serveraddress:serverport/system/console/configMgr)。
  2. 「preupgradetasks」を検索し、最初に一致したコンポーネントをクリックします。コンポーネントのフルネームは、com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl です。
  3. 次に示すように、実行する必要のあるメンテナンスタスクのリストを変更します。
chlimage_1

タスクリストは、インスタンスを開始するために使用する実行モードによって異なります。各メンテナンスタスクの設計対象の実行モードの説明を次に示します。

タスク 実行モード OSGi 設定
TarIndexMergeTask crx2 -
DataStoreGarbageCollectionTask crx2 -
WorkflowPurgeTask crx2/crx3 Adobe Granite のワークフローのパージ設定
ConsistencyCheckTask crx2 -
RevisionCleanupTask crx3 -
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 監査ログのパージスケジューラー
GenerateBundlesListFileTask crx2/crx3
-

警告:

DataStoreGarbageCollectionTask を使用した場合、マークアンドスイープフェーズを含むデータストアガベージコレクション操作が呼び出されます。共有データストアを使用するデプロイメントでは、別のインスタンスによって参照される項目が削除されないように、再設定するかインスタンスを適切に準備します。そのためには、このアップグレード前のタスクをトリガーする前に、すべてのインスタンスに対してマークフェーズを手動で実行する必要がある場合があります。

WorkflowPurgeTask および com.day.cq.audit.impl.AuditLogMaintenanceTask タスクには設定が必要であり、設定がないと機能しません。これらのタスクが失敗した場合、最も可能性がある原因は設定がないことです。

したがって、これらのタスクの OSGI 設定を追加するか、これらのタスクを実行しない場合はアップグレード前の最適化タスクのリストから削除します。

アップグレード前のヘルスチェックのデフォルトの設定

PreUpgradeTasksMBeanImpl OSGI コンポーネントは、runAllPreUpgradeHealthChecks メソッドが呼び出されたときに実行されるアップグレード前のヘルスチェックタグのリストで事前設定されています。

  • system - Granite のメンテナンスヘルスチェックで使用するタグです。
  • pre-upgrade - アップグレード前に実行するように設定できるすべてのヘルスチェックに追加できるカスタムタグです。

このリストは編集できます。タグの横のプラス(+)ボタンとマイナス(-)ボタンを使用して、カスタムタグを追加したり、デフォルトのタグを削除したりすることができます。

MBean メソッド

マネージド Bean 機能には、JMX コンソールを使用してアクセスできます。

以下の手順で MBean にアクセスできます。

  1. JMX コンソール(http://serveraddress:serverport/system/console/jmx)に移動します。
  2. PreUpgradeTasks を検索して結果をクリックします。
  3. Operations」セクションからメソッドを選択し、次のウィンドウで「Invoke」を選択します。

PreUpgradeTasksMBeanImpl によって公開されている使用可能なすべてのメソッドのリストを以下に示します。

メソッド名 タイプ 説明
getAvailablePreUpgradeTasksNames() INFO 使用可能なアップグレード前のメンテナンスタスク名のリストを表示します。
getAvailablePreUpgradeHealthChecksTagNames() INFO アップグレード前のヘルスチェックタグ名のリストを表示します。
runAllPreUpgradeTasks() ACTION リストにあるすべてのアップグレード前のメンテナンスタスクを実行します。
runPreUpgradeTask(preUpgradeTaskName) ACTION パラメーターとして指定された名前のアップグレード前のメンテナンスタスクを実行します。
isRunAllPreUpgradeTaskRunning() ACTION_INFO runAllPreUpgradeTasks メンテナンスタスクが現在実行中かどうかをチェックします。
getAnyPreUpgradeTaskRunning() ACTION_INFO アップグレード前のメンテナンスタスクが現在実行中かどうかをチェックし、現在実行中のタスクの名前が含まれた配列を返します。
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) ACTION パラメーターとして指定された名前のアップグレード前のメンテナンスタスクの正確な実行時間を表示します。
getPreUpgradeTaskLastRunState(preUpgradeTaskName) ACTION パラメーターとして指定された名前のアップグレード前のメンテナンスタスクの最後の実行状態を表示します。
runAllPreUpgradeHealthChecks(shutDownOnSuccess) ACTION

すべてのアップグレード前のヘルスチェックを実行し、それらのステータスを sling ホームパスにある preUpgradeHCStatus.properties という名前のファイルに保存します。shutDownOnSuccess パラメーターに true が設定されていると、AEM インスタンスはシャットダウンされますが、これはすべてのアップグレード前のヘルスチェックのステータスが OK の場合のみです。


properties ファイルは今後のアップグレードの前提条件として使用され、アップグレード前のヘルスチェック実行が失敗した場合は、アップグレードプロセスが停止されます。アップグレード前のヘルスチェックの結果を無視してアップグレードを開始する場合は、このファイルを削除できます。

detectUsageOfUnavailableAPI(aemVersion) ACTION 読み込まれたパッケージで、指定された AEM バージョンへのアップグレード時に適合しなくなるものをすべてリストします。ターゲットの AEM バージョンは、パラメーターとして指定する必要があります。

注意:

MBean メソッドは、以下から呼び出すことができます。

  • JMX コンソール
  • JMX に接続する外部アプリケーション
  • cURL

アップグレード前の互換性チェック

アップグレード前の互換性チェックでは、6.3 と互換性がなくアップグレード後に動作しない可能性がある使用中の API を検出することによって、既存の AEM インスタンスがアップグレード可能かどうかをチェックできます。これにより、次のバージョンへの移行に必要となる可能性がある開発作業を評価できます。

この機能を使用するには、アップグレード元のインスタンスに最新バージョンの pre-upgrade-tasks-content コンテンツパッケージをインストールする必要があります。

AEM 6 バージョンのパッケージは、この節に示されているリンクにアクセスすることによってダウンロードできます。

チェックは、前述の PreUpgradeTasksMBean MBean を使用して呼び出すことができます。

chlimage_1

アップグレード前の互換性チェックのために呼び出すメソッドは detectUsageOfUnavailableAPI であり、次に示すようにチェック対象のバージョンがパラメーターとして渡されます。

chlimage_1

互換性のない API を使用していて、アップグレード後は使用できなくなる読み込み済みのパッケージおよびバンドルのリストが、以下に示すように応答で返されます。結果は upgrade.log にも追加されます。

その他の準備手順

6.3 では、アップグレードプロセスは多数のアップグレード前のタスクの自動化によってできるだけ簡単になるように設計されていますが、実稼動環境のアップグレードは重要なタスクであり、手動で実行するいくつかの準備手順も必要となります。具体的には、このチェックリストにある項目を実行してからアップグレードに進むことをお勧めします。

  1. アップグレードしようとするインスタンスの完全バックアップを作成します。方法については、バックアップと復元を参照してください。

  2. アップグレード中にアンインストールされる廃止されたバンドルの一覧を確認します。カスタムアプリケーションがこれらのバンドルのいずれかを利用している場合は、Adobe サポートに連絡し、影響を受ける領域の互換性パッケージを要求してください。

  3. インスタンス(カスタムアプリケーションを含む)を検証するテストスイートを実行します。インスタンスとテストスイートの検証後、アップグレードプロセスの後の段階で、アップグレードを検証する目的でこのテストスイートを再利用できます。

  4. /etc/map でのホスト名ベースのマッピング(およびその他の同様の設定)が、アップグレード後のインスタンスをテストする環境と互換性を持っていることを確認します。

  5. カスタム認証メカニズムをすべて無効にします。この方法については、カスタムログインモジュールの無効化を参照してください。

  6. カスタムアプリケーションのためにアップグレードのカスタマイズが必要になる場合は、その準備をします。

    注意:

    アセットコンテンツをカスタマイズした場合は、カスタマイズされているアセットのアップグレード準備を参照してください。

  7. アップグレード用にクリーンなログを取得するために、crx-quickstart/logs にあるログファイルをアーカイブした後、削除します。

カスタムログインモジュールの無効化

注意:

この手順は、AEM 5 バージョンからアップグレードする場合にのみ必要です。以前の AEM 6 バージョンからのアップグレードの場合は、完全にスキップできます。

Apache Oak では、リポジトリレベルで認証をおこなうためのカスタムの LoginModule の設定方法が大きく変わっています。

CRX2 を使用していた旧バージョンの AEM では、repository.xml ファイルで設定をおこないましたが、AEM 6 以降では、Web コンソールを使用して、Apache Felix JAAS Configuration Factory サービスで設定をおこないます。

そのため、既存の設定を無効にして、アップグレード後、Apache Oak 用に再作成する必要があります。

repository.xml の JAAS 設定で定義したカスタムモジュールを無効にするには、次の例のようにデフォルトの LoginModule を利用するように設定を変更する必要があります。

<Security>
            ....
         <!--
                Use LoginModule authenticating against repository itself
                -->
                <LoginModule class="com.day.crx.core.CRXLoginModule">
                    <param name="anonymousId" value="anonymous"/>
                    <param name="adminId" value="admin"/>
                    <param name="disableNTLMAuth" value="true"/>
                    <param name="tokenExpiration" value="43200000"/>
                    <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/ -->
                </LoginModule>
        </Security>

注意:

詳しくは、外部ログインモジュールによる認証を参照してください。

AEM 6 での LoginModule 設定例については、AEM 6 での LDAP の設定を参照してください。

AEM Quickstart jar ファイルの準備

新しい AEM jar ファイルをダウンロードし、それを使用して crx-quistart フォルダー内の古いファイルを置き換えます。

次に、Java 仮想マシン(JVM)とそのパラメーターが、この新しい quickstart jar に適しているかを確認します。要件やデプロイメントのタイプに応じて、旧バージョンの CQ または AEM で使用していたものとは異なるバージョンの JVM を実行したり、異なる JVM パラメーターを使用したりする必要があります。

コンテンツリポジトリの移行およびアップグレード

アドビは、リポジトリを AEM 6.3 で使用される新しいバージョンの Oak Segment Tar に移行するためのツールを提供しています。このツールは、クイックスタートパッケージに含まれています。

この手順は、古いバージョンの TarMK からアップグレードする場合、または別のタイプの格納機能から新しい Segment Tar に切り替える場合に必須です。新しい Segment Tar のメリットについて詳しくは、Oak Segment Tar への移行に関する FAQ を参照してください。

実際の移行は、標準の AEM 6.3 クイックスタート jar ファイルを使用しておこないます。この jar ファイルは、新しい -x crx2oak オプションを指定して実行します。このオプションによって crx2oak ツールが実行され、アップグレードがより容易で堅牢になります。

移行の前に満たす必要のある前提条件がいくつかあります。

移行の前提条件

  • Java バージョンの最小要件:移行ツールは、Java バージョン 7 以降でのみ動作します。
  • アップグレード対象のインスタンス:アップグレード対象のインスタンスのバージョンが 5.4 よりも古い場合は、前述の手順を実行して、AEM 6.0 へのインプレースアップグレードを事前におこなってください。詳しくは、アップグレードに関するドキュメントの 6.0 バージョンを参照してください。

これらの条件を満たしたら、次の手順をこのとおりに実行します。

  1. 最初に、インスタンスが実行中の場合は停止します。

  2. 古いクイックスタート jar ファイルを削除し、新しい 6.3 のファイルに置き換えます。

  3. 次のコマンドを実行して新しいクイックスタート jar を解凍します。

    java -Xmx4096m -jar aem-quickstart.jar -unpack
  4. リポジトリ移行を開始します。実行する必要があるコマンドは、使用する移行パスによって異なります。すべての移行の組み合わせと、それらに関連付けられたコマンドのリストを以下に示します。

    警告:

    Java メモリマップが正しく処理されない Windows システムでアップグレードを実行する場合は、--disable-mmap パラメーターを以下のコマンドに追加してください。

    AEM 5.6.x から TarMK へ:

    java -Xmx4096m -XX:MaxPermSize=2048m -jar aem-quickstart.jar -v -x crx2oak -xargs -- --load-profile segment-fds

    AEM 5.6.x から MongoMK へ:

    java -Xmx4096m -XX:MaxPermSize=2048m -jar aem-quickstart.jar -v -x crx2oak -xargs -- --load-profile mongo-from-crx2 -T mongo-uri=mongodb://mongo-host:mongo-port -T mongo-db=mongo-database-name

    ここで、

    • mongo-host は、MongoDB サーバーの IP です(例:127.0.0.1)。
    • mongo-port は、MongoDB サーバーのポートです(例:27017)。
    • mongo-database-name は、データベースの名前です(例:aem-author)。

    TarMK とファイルデータストアを使用する AEM 6.x から:

    java -Xmx4096m -XX:MaxPermSize=2048m -jar aem-quickstart.jar -v -x crx2oak -xargs -- --load-profile segment-fds

    TarMK とカスタムデータストアを使用する AEM 6.x から:

    java -Xmx4096m -XX:MaxPermSize=2048m -jar aem-quickstart.jar -v -x crx2oak -xargs -- --load-profile segment-custom-ds

    データストアがない TarMK を使用する AEM 6.x から:

    java -Xmx4096m -XX:MaxPermSize=2048m -jar aem-quickstart.jar -v -x crx2oak -xargs -- --load-profile segment-no-ds

    Amazon S3 データストアを使用するインスタンスの移行については、この記事を参照してください。

  5. AEM インストールディレクトリの crx-quickstart/logs にある upgrade.log ファイルで WARN および ERROR メッセージを調査して、移行が正常に終了したことを確認します。

    注意:

    リポジトリの install フォルダー内にあるパッケージは、アップグレード後に再インストールされます。 

    そのため、アップグレードの前に、インスタンスに対してこのフォルダー内のパッケージと重複する可能性のある変更はおこなわないようにしてください。

  6. AEM を起動して対象インスタンスを起動することによって、インプレースアップグレードを実行します。

    java -Xmx4096m -XX:MaxPermSize=2048m -jar aem-quickstart.jar 

    注意:

    アップグレードプロセスにより、移行プロファイルに従って正しい実行モード(インストールオプション)が自動的に引き継がれ、一方で古い有効な実行モードも維持されます。したがって、アップグレード後にインスタンスを起動するときにインストールオプションをチェーニングする必要はありませんが、カスタム実行モードは以前と同様に渡す必要があります。

  7. AEM インストールディレクトリの crx-quickstart/logs にある upgrade.log ファイルで WARN および ERROR メッセージを再度調査して、インプレースアップグレードが正常に終了したことを確認します。

ヘルパー JAR の手動更新

crx2oak のヘルパー JAR は、必要に応じて手動でアップグレードできます。そのためには、クイックスタートを解凍した後、手動で新しいバージョンに置き換えます。AEM インストールフォルダー内のヘルパー JAR ファイルの場所は次のとおりです。

  • <aem-install>/crx-quickstart/opt/extensions/crx2oak.jar

最新バージョンの CRX2Oak 移行ツールは、次の場所にある Adobe リポジトリからダウンロードして入手できます。

crx2oak-quickstart-extension.jar を実行すると、バージョンと SHA-1 チェックサムが表示されます。これらは、crx2oak.jar と同じ情報です。これらの JAR を手動でアップグレードしており、リポジトリ移行に関するバグを報告する場合は、使用したファイルのバージョンと SHA-1 チェックサムをサポートにお知らせください。

アップグレード後のチェックの自動化

以前は、インスタンスのアップグレード後の状態を調査するには、様々なログファイル、およびリポジトリと起動パッドの各部を注意深く調査する必要がありました。アップグレード後のレポートを生成すると、不具合があるアップグレードを稼動前に検出できることがあります。

この機能の主な目的は、アップグレードの成功を確認するために必要な、手動による解釈や複数のエンドポイントにわたる複雑な解析ロジックの必要性を減らすことです。このソリューションの目的は、更新の成功または確認された失敗に反応する外部の自動化システムに明確な情報を提供することです。

具体的には、次のことがおこなわれます。

  • アップグレードフレームワークによって検出されたアップグレードの失敗が単一のアップグレードレポートにまとめて報告されます。
  • アップグレードレポートには、手動で対応する必要がある事項が記載されています。

これに対応するために、upgrade.log ファイルにログを生成する方法が変更されました。

アップグレード中にエラーが発生しなかったことを示すサンプルレポートを次に示します。

chlimage_1

アップグレードプロセスでインストールされなかったバンドルを示すサンプルレポートを次に示します。

chlimage_1

アプリケーションサーバーインストールのアップグレード手順

ここでは、アプリケーションサーバーインストール用の AEM を更新するために必要になる手順を説明します。

この手順では、どの例でも JBoss をアプリケーションサーバーとして使用し、有効な AEM のバージョンが既にデプロイされているものとします。ここでは、AEM バージョン 5.6 から 6.3 へのアップグレードについて説明します。

  1. 最初に、JBoss を起動します。ほとんどの状況で、standalone.sh 起動スクリプトを実行することで起動できます。そのためには、ターミナルから次のコマンドを実行します。

    jboss-install-folder/bin/standalone.sh

    注意:

    JBoss のタスクについて詳しくは、このドキュメントページを参照してください。

  2. AEM 5.6 が既にデプロイされている場合は、次のコマンドを実行してバンドルが正常に動作していることを確認します。

    wget http://<serveraddress:port>/cq/system/console/bundles
  3. 次に、AEM 5.6 のデプロイを解除します。

    rm jboss-install-folder/standalone/deployments/cq.war
  4. JBoss を停止します。

  5. 次に、crx2oak 移行ツールを使用してリポジトリを移行します。

    java -jar crx2oak.jar crx-quickstart/repository/ crx-quickstart/oak-repository

    注意:

    この例の oak-repository は、新しく変換されたリポジトリが配置される一時ディレクトリです。

    この手順を実行する前に、crx2oak.jar が最新バージョンであることを確認してください。

  6. 次の操作をおこなって、sling.properties ファイル内の必要なプロパティを削除します。

    1. crx-quickstart/launchpad/sling.properties ファイルを開きます。
    2. 次のプロパティを削除してファイルを保存します。
    sling.installer.dir
    felix.cm.dir
    granite.product.version
    org.osgi.framework.system.packages
    osgi-core-packages
    osgi-compendium-services
    jre-*
    sling.run.mode.install.options
  7. 不要なファイルとフォルダーを削除します。具体的に削除する必要のある項目は次のとおりです。

    • launchpad/startup フォルダー。ターミナルで次のコマンドを実行して削除できます。
    rm -rf crx-quickstart/launchpad/startup
    • base.jar ファイル:
    find crx-quickstart/launchpad -type f -name "org.apache.sling.launchpad.base.jar*" -exec rm -f {} \;

    BootstrapCommandFile_timestamp.txt ファイル:

    rm -f crx-quickstart/launchpad/felix/bundle0/BootstrapCommandFile_timestamp.txt
  8. 新しく移行された segmentstore を適切な場所にコピーします。

    mv crx-quickstart/oak-repository/segmentstore crx-quickstart/repository/segmentstore
  9. datastore もコピーします。

    mv crx-quickstart/repository/repository/datastore crx-quickstart/repository/datastore
  10. 次に、アップグレード後の新しいインスタンスで使用する OSGi 設定を格納するためのフォルダーを作成する必要があります。

    具体的には、install というフォルダーを crx-quickstart の下に作成する必要があります。

  11. 次に、AEM 6.3 で使用されるノードストアとデータストアを作成します。

    そのために、次の名前を持つ 2 つのファイルを crx-quickstart\install の下に作成します。

    • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
    • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    これら 2 つのファイルにより AEM が TarMK ノードストアと File データストアを使用するように設定されます。

  12. 設定ファイルを編集し、使用できる状態にします。具体的には、次のように編集します。

    org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config に次の行を追加します。

    customBlobStore=B"true"

    org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config に次の行を追加します。

    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"4096"
  13. 次のコマンドを実行して crx2 実行モードを削除します。

    find crx-quickstart/launchpad -type f -name "sling.options.file" -exec rm -rf {} \;
  14. 今度は、AEM 6.3 war ファイル内の実行モードを変更する必要があります。変更するには、まず AEM 6.3 war を格納する一時フォルダーを作成します。次の例のフォルダー名は、temp です。

    war ファイルをコピーしたら、temp フォルダー内で次のコマンドを実行して、内容を抽出します。

    jar xvf aem-quickstart-6.3.0.war
  15. 内容を抽出したら、WEB-INF フォルダーに移動して web.xml ファイルを編集し、実行モードを変更します。

    XML での実行モードの設定場所を探すには、sling.run.modes 文字列を検索します。見つかったら、コードの次の行で実行モードを変更します。デフォルトでは、author に設定されています。

    <param-value>author</param-value>

    この author という値を変更して、次の実行モードを設定します。

    author,crx3,crx3tar

    最終的なコードブロックは次のようになります。

    <init-param>
    <param-name>sling.run.modes</param-name>
    <param-value>author,crx3,crx3tar</param-value>
    </init-param>
    <load-on-startup>100</load-on-startup>
    </servlet>
  16. 編集後の内容で jar を再作成します。

    jar cvf aem62.war
  17. 最後に、新しい war ファイルをデプロイします。

    cp temp/aem62.war jboss-install-folder/standalone/deployments/aem61.war

アセットのアップグレード

ここでは、以前のバージョンの AEM からアセットをアップグレードする方法を説明します。

注意:

InDesign スクリプトをカスタマイズした場合、それらはアップグレードの際に維持されません

カスタマイズされているアセットのアップグレード準備

注意:

この手順は、AEM 6.2 よりも前のバージョンからのアップグレードにのみ必要です。

カスタマイズされたアセットデプロイメントを含んでいるインスタンスを、アップグレード用に準備する必要があります。これは、カスタマイズされたすべてのコンテンツに 6.3 の新しいノード構造との互換性を持たせるために必要な作業です。

アセットコンテンツを準備するには、以下の手順を実行します。

  1. アップグレードする必要があるインスタンス上で、http://server:port/crx/de/index.jsp に移動して CRXDE Lite を開きます。

  2. 次のノードに移動します。

    • /apps/dam/content
  3. content ノードの名前を content_backup に変更します。ウィンドウ左側のエクスプローラーパネルを右クリックし、「名前を変更」を選択することによって、変更できます。

  4. ノードの名前を変更したら、content という名前の新しいノードを /apps/dam の下に作成し、ノードタイプを sling:Folder に設定します。

  5. content_backup のすべての子ノードを、新しく作成された content ノードに移動します。そのためには、エクスプローラーパネルで個々の子ノードを右クリックし、「移動」を選択します。

  6. content_backup ノードを削除します。

既存アセットのアセット ID の生成

既存のアセットのアセット ID を生成するには、AEM 6.3 を実行するように AEM インスタンスをアップグレードする際にアセットをアップグレードします。これは、アセットインサイト機能を有効にするために必要な手順です。詳しくは、埋め込みコードの追加を参照してください。

アセットをアップグレードするには、JMX コンソールで Associate Asset IDs パッケージを設定します。リポジトリ内のアセットの数によっては、migrateAllAssets に長い時間がかかることがあります(TarMK に 125k のアセットがある場合は、約 1 時間)。

chlimage_1

アセット全体のサブセットに対してアセット ID が必要な場合は、migrateAssetsAtPath API を使用します。

その他すべての目的には、migrateAllAssets() API を使用してください。

カスタム検索フォームのアップグレード

カスタム検索フォームを正しく機能させるには、アップグレード後に手動での変更が必要です。詳しくは、カスタム検索フォームのアップグレードを参照してください。

アップグレードによる問題の分析

ここでは、AEM 6.3 へのアップグレード手順で発生する可能性のある問題のシナリオを説明します。

これらのシナリオは、アップグレードに関連する問題の根本原因を追跡するのに役立ちます。また、プロジェクトや製品に固有の問題を識別するためにも役立ちます。

リポジトリ移行の失敗

CRX2 から Oak へのデータ移行は、CQ 5.4 ベースのソースインスタンスから開始されるすべてのシナリオで実現可能です。repository.xml の準備を含むこのドキュメントのアップグレード手順に正確に従っていること、JAAS 経由でカスタム認証を起動していないこと、および移行を始める前にインスタンスに不整合がないかをチェックしていることを確認してください。

それでも移行が失敗する場合は、upgrade.log を調査して根本原因を解明することができます。未知の問題の場合は、カスタマーサポートに報告してください。

パッケージとバンドルを更新できない

アップグレード中にパッケージがインストールされなかった場合は、パッケージに含まれるバンドルも更新されません。

このような問題は、通常はデータストアの設定の誤りが原因です。また、この問題は、error.logERROR および WARN メッセージとして表示されます。

通常、この問題が起きているときはデフォルトのログインが動作しないので、直接 CRXDE を使用して設定の問題を調査、解明することになります。

一部の AEM バンドルがアクティブな状態に切り替わらない

バンドルが起動しない場合は、未解決の依存関係がないかを確認してください。

パッケージのインストールが失敗したせいでバンドルがアップグレードされず、その結果、新しいバージョンとの互換性がないと見なされ、この問題につながっている可能性もあります。このトラブルシューティングの方法について詳しくは、前述のパッケージとバンドルを更新できないを参照してください。

また、新規 AEM 6.3 インスタンスのバンドル一覧とアップグレード後のバンドル一覧を比較して、アップグレードされていないバンドルを検出することを推奨します。この比較によって、error.log で検索すべき問題を絞り込むことができます。

カスタムバンドルがアクティブな状態に切り替わらない

カスタムバンドルがアクティブな状態に切り替わらない場合は、変更後の API をインポートしていないコードが存在する可能性が疑われます。これは多くの場合、未解決の依存関係につながります。

削除された API は、以前のいずれかのリリースで廃止対象としてマークされているはずです。このような廃止の注記に、コードの直接的な移行に関する指示が含まれている場合があります。アドビはバージョン番号にできる限り意味を持たせるようにしており、バージョンが変わるときは互換性を破る変更がおこなわれている可能性があります。

また、問題の原因となった変更点が本当に必要であるかを確認し、不要なものであればその変更を元に戻すことをお勧めします。パッケージのエクスポートのバージョンが必要以上に増えていないかを確認し、厳密な意味のあるバージョン定義をおこなってください。

プラットフォーム UI の異常

アップグレード後に特定の UI 機能が正しく動作していない場合は、まずインターフェイスのカスタムオーバーレイを確認します。一部の構造が変更され、オーバーレイを更新する必要があるか、オーバーレイが古くなっている可能性があります。

次に、クライアントライブラリにフックされているカスタムの追加拡張にまで追跡可能な JavaScript エラーが発生していないかを確認します。AEM レイアウトの問題を引き起こしている可能性があるカスタム CSS についても、同様の確認をおこないます。

最後に、JavaScript では対処できない設定の誤りがないかを確認します。これは通常、不適切にアクティベート解除された拡張により発生する問題です。

カスタムコンポーネント、テンプレートまたは UI 拡張の異常

ほとんどの場合、これらの問題の根本原因は、起動されていないバンドルやインストールされていないパッケージによる問題と同じですが、異なる点は、問題が最初にコンポーネントを使用した時点で発生することです。

問題のあるカスタムコードへの対処方法としては、まず原因を特定するためのスモークテストを実行します。問題を特定したら、この記事にある推奨事項を参照して、問題の修正方法を確認します。

error.log と upgrade.log の分析

ほとんどの状況では、問題の原因を特定するために、ログにエラーがないかを確認する必要があります。ただし、アップグレードの場合は、古いバンドルが適切にアップグレードされていない場合があるので、依存関係の問題を監視する必要もあります。

そのための最適な方法は、現在発生している問題には関係がないと思われるメッセージをすべて削除して、error.log の情報を削ることです。次のように grep などのツールを使用して実行できます。

grep -v UnrelatedErrorString

即座に内容がわからないエラーメッセージもあります。その場合は、そのエラーメッセージが発生しているコンテキストを確認すると、エラーの発生場所の理解に役立ちます。以下のように使用してエラーを区別することができます。

  • grep -B(エラーの前の行を追加)

      または

  • grep -A(エラーの後の行を追加)

場合によっては、警告メッセージの中にエラーが見つかることもあります。妥当なケースが警告の状態につながることもあり、それが実際にエラーであるかどうかをアプリケーションが常に判断できるとは限りません。これらの警告メッセージについても確認してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー