レガシー・クラウド・インフラストラクチャからのOracle Content Managementインスタンスの移行

「cec migrate-site」コマンドは新しいため、OCEツールキットを以前にダウンロードしてインストールしたことがある場合でも、WebクライアントのGitリポジトリからこのツールキットをインストールする必要があります。

サイト・ツールキット・ページの指示に従ってOCEツールキットをダウンロードしてインストールします。

ターゲット・サーバー(サイトの移行先のサーバー)に関する接続詳細を登録します:

> cec register-server <target_server_name>
          -e http://<target_server>:<target_port>
          -u <target_username> -p <target_password>
          -t pod_ec

• <target_server_name>を使用して、ターゲット・エンドポイントを識別します。これは、任意に選択した名前にすることができます。
• <target_server>および<target_port>は、ターゲット・サーバーへのアクセスに使用するURLを構成します。
• 移行時にテンプレートがインポートされるときに権限に関する問題が発生しないように、<target_username>および<target_password>は、ソース・サーバーからサイト・テンプレートをエクスポートする人物のユーザー名とパスワードにする必要があります。
• 値"pod_ec"はターゲット・サーバー・タイプで、インスタンスが構築されているサーバーのタイプを識別するために使用されます。

サイトを移行するには、次の手順を実行します:

1. ソース・サーバーで、アセットが含まれる各サイトからテンプレートを作成します。
2. ソース・サーバーで、各テンプレートをエクスポートします。この手順は、ターゲット・サーバーを登録したときに参照したユーザーとして実行するようにしてください。
3. ターゲット・サーバーに、リポジトリ管理(CECRepositoryAdministratorロールのあるユーザー)としてサインインします。次に、テンプレートとともにインポートされるアセットのリポジトリを作成します。
4. ダウンロードしたテンプレートごとに、次のコマンドを実行します。この場合、<site_name>は、ターゲット・サーバーでサイトに使用する名前に置き換えます:

   > cec migrate-site <site_name> --template <template_path_and_name> 
   --destination <registered_target_server_name> --repository <repository_name>

5. ターゲット・サーバーで、移行したサイトおよびアセットを適切に共有します。

サイトを移行した後、サイトはコンテンツREST v1.1コールを使用して動作します。これにより、サイトが適切に動作する前に解決する必要がある問題が生じる可能性があります。次の各事項を参照し、何を実行する必要があるのか確認してください:

• ContentSDKを使用している場合、v1.1コンテンツRESTコールを使用するようにコールが自動的に更新されます。
• コンテンツ・レイアウトがv1.1をサポートしていることを表明していない場合、ContentSDKは、単純にfieldsエントリ(v1.1)を指し示すdataエントリ(v1.0)もレスポンスに追加し、テンプレートが変更なしで動作し続けるようにします。
• 追加問合せ文字列内でfields.type.equals= v1.0コンテンツREST構文を使用している場合、オラクル社ではこれを解析および変更してv1.1構文にしようと試みていますが、あなたがこれを確認する必要があります。
• (ContentSDKを介すのではなく)コンテンツREST v1.0コールを直接実行する場合、これらのコールは失敗します。カスタム・コードを修正し、これらのコールをアップグレードする必要があります。
• 同様に、fields.type.equals= v1.0構文をq=(type eq "..")にするカスタム・コンテンツ問合せが必要です。
• updateddateとupdatedDate: これはおそらく、CaaSによって修正されていますが、コンテンツREST v1.1 APIが両方の値をサポートするECビルドをオラクル社が取得するまでは、あなたがupdateddate値を変更してcamelCase: updatedDate値にする必要があります。

サイトが適切に動作するようになったら、サイトをMLSに準拠させる必要があります。外部計算サーバーでエンタープライズ・サイトを作成する必要がある場合、デフォルトの言語とローカライゼーション・ポリシーが必要です。サイトはコピーされたものであるため、非MLSサイトです。このため、MLSサイトにアップグレードし、将来の機能をサポートできるようにする必要があります。

次の表は、MLSサイトと非MLSサイト間の違いを示しています。

サイトをMLSサイトに変換する前に、次を実行する必要があります:

• コンテンツREST APIs v1.1をサポートするためにコンテンツ・レイアウト・コンポーネントをすべてアップグレードします
• コンテンツREST API v1.1に準拠するようにサイトのコンテンツ・リスト内の「追加問合せ文字列」をアップグレードします

次に、コンテンツRESTコールを行うカスタム・コンポーネント・コードがある場合は、v1.1コールを行うためにこれらをアップグレードすることも必要です。ほとんどのコンテンツ・コールはコンテンツ・レイアウトから行われるため、これは一般的ではありません。

コンテンツ・レイアウトのアップグレード

サポートされるコンテンツREST APIバージョンの指定

コンテンツ・レイアウトでは、サポートするコンテンツREST APIのバージョンを指定する必要があります。これにより、想定されるレスポンス・データをレイアウトに返すために適切なコンテンツRESTコールが行われるようにします。

バージョン・サポートを指定しない場合、コンテンツ・レイアウトはv1.0をサポートしていると見なされます。

コンソールには、まだv1.0のままのコンテンツ・レイアウトがリストされます。

コンテンツ・レイアウトが他のバージョンをサポートできるようにするには、コンテンツ・レイアウト・オブジェクトにcontentVersionプロパティを追加します。

この例では、v1.0から2.0未満までのすべてのバージョンをサポートすることを表しています(ノート: 2.0は存在しませんが、主要なバージョン変更によって大幅な変更が導入される可能性があります)

// Content Layout
          definition.ContentLayout.prototype = {    // Specify the versions of
          the Content REST API that are supported by the this Content Layout.    // The value for contentVersion follows Semantic Versioning
          syntax.    // This allows applications that use the
          content layout to pass the data through in the expected format.    contentVersion: ">=1.0.0
          <2.0.0",     // Main rendering function:    // - Updates the data to handle any required additional requests and
          support both v1.0 and v1.1 Content REST APIs    // - Expand the Mustache template with the updated data
            // - Appends the expanded template HTML to the
          parentObj DOM element    render: function (parentObj)
          {

v1.1のレスポンス変更の処理

最小限実行可能性があることは、コンテンツREST APIレスポンスのdataからfieldsへの変更を処理することです。これを行う最も簡単な方法は、dataプロパティを追加し戻し、新しいfieldsプロパティを指し示す方法です

render: function (parentObj)
          {    ...    if(!content.data) {        content.data =
          content.fields;    }

より優れたオプションは、コンテンツ・レイアウト全体にわたってv1.1のfields値を使用するよう変更する方法です。これには、JavaScriptとテンプレート・コードの両方の更新が含まれます。

v1.1を完全にサポートするには、v1.0とv1.1の間で次のコンテンツREST APIの変更を処理する必要があります:

"items": [{    "type": "Starter-Blog-Author",    "name": "Alex Read",    "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63",    "fields":
          {        "starter-blog-author_bio": "Alex's bio",        "starter-blog-author_name": "Alex Read"        }    },

"items": [{    "type": "Starter-Blog-Author",    "name": "Alex Read",    "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63",    "data":
          {        "starter-blog-author_bio": "Alex's bio",        "starter-blog-author_name": "Alex Read"        }    },

コンテンツ問合せ文字列のアップグレード

任意のカスタム・コードでコンテンツAPIコールを実行している可能性があるため、コンテンツREST APIコールを実行しているサイトによって使用されているすべてのカスタム・コードを確認する必要があります。

• カスタム・コンポーネント: 次のコンポーネントを確認します:
  • コンテンツ・レイアウト
  • ローカル・コンポーネント
  • セクション・レイアウト
  • リモート・コンポーネント
• テーマ: JavaScript: 可能性は低いですが、カスタム・コンテンツREST APIコールを実行しているJavaScriptがテーマ内に存在する可能性があるため、これらも確認する必要があります。
• サイト・プロパティ: 追加問合せ文字列: コンテンツREST APIコールを実行しているすべてのカスタム・コードをアップグレードしたことを確認したら、サイト内の任意のページ上のコンテンツ・リスト・コンポーネント内の追加問合せ文字列もアップグレードする必要があります。Oracleではこれらをランタイム時に解析および変換しようと試みていますが、サポートを継続するためにこれらをアップグレードしてv1.1コンテンツRESTコールとの互換性を確保する必要があります。

非MLSサイトのMLSサイトへの変換

v1.1コンテンツREST APIを完全にサポートするようサイトを変換したら、MLSサイトに変更することによって言語のサポートを追加できます。

サイト管理UIでサイトを選択すると、translatableコンテンツ・メニュー・オプションが表示されます。このオプションを選択すると、ダイアログが表示され、ローカライゼーション・ポリシー内の必要な言語のリストからサイトのローカライゼーション・ポリシーおよびデフォルト言語を選択するよう求められます。ローカライゼーション・ポリシーが存在しない場合、この手順を完了できず、最初にコンテンツ管理画面に移動し、少なくとも1つの必須言語を使用してローカライゼーション・ポリシーを作成する必要があります。

この手順が完了したら、サイトはデフォルトのロケールでレンダリングされるようになります。また、ローカライゼーション・ポリシーに指定されている他のロケールに切り替えることもできます。

サイトがデフォルトのロケールで想定どおりにレンダリングされることを確認する必要があります。

ソース・サーバーおよびターゲット・サーバーの接続詳細を登録します。

ソース・サーバー(アセットの移行元のサーバー)を登録します:

> cec register-server <source_server_name>
          -e http://<source_server>:<source_port>
          -u <source_username> -p <source_password>
          -t pod_ic

• <source_server_name>を使用して、ソース・エンドポイントを識別します。これは、任意に選択した名前にすることができます。
• <source_server>および<source_port>は、ソース・サーバーへのアクセスに使用するURLを構成します。
• <source_username>および<source_password>は、ソース・サーバー上のアセットにアクセスできる人物のユーザー名とパスワードにする必要があります。
• 値"pod_ic"はソース・サーバー・タイプで、インスタンスが構築されているサーバーのタイプを識別するために使用されます。

ターゲット・サーバー(アセットの移行先のサーバー)を登録します:

> cec-install % cec register-server <target_server_name>
          -e http://<source_server>:<source_port>
          -u <target_username> -p <target_password>
          -t pod_ec

• <target_server_name>を使用して、ターゲット・エンドポイントを識別します。これは、任意に選択した名前にすることができます。
• <target_server>および<target_port>は、ターゲット・サーバーへのアクセスに使用するURLを構成します。
• <target_username>および<target_password>は、ターゲット・サーバー上のアセットを所有する人物のユーザー名とパスワードにする必要があります。
• 値"pod_ec"はターゲット・サーバー・タイプで、インスタンスが構築されているサーバーのタイプを識別するために使用されます。

次のコマンドを実行して、アセットのコレクションを移行します:

> cec migrate-content <source_collection_name> --server  <source_server_name>
      --destination <target_server_name> --repository <target_repository_name> --collection  <target_collection_name> --channel
    <target_channel_name>

アセットは、指定したリポジトリ内のターゲット・サーバー上に作成され、コレクションおよびチャネルに関連付けられます。必要に応じて、コレクションおよびチャネルは自動的に作成されます。すべての移行済アセットのデフォルトの言語が、指定したリポジトリに設定されているデフォルトの言語になります。