機械翻訳について
  1. Oracle Content Managementの管理
  2. Oracle Content Managementの移行
  3. レガシー・クラウド・インフラストラクチャからのOracle Content Managementインスタンスの移行

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

非従量制サブスクリプションを使用してレガシー・クラウド・インフラストラクチャでOracle Content Managementインスタンスを実行している場合、Oracleでは、これらのインスタンスを新しい「ネイティブ」 Oracle Cloud Infrastructure (OCI) environment-Gen 2 OCI (Oracle Cloudコンソールを使用してサービス・インスタンスを管理)に移行することをお薦めします。 これにより、Oracleのクラウド・プラットフォームの利点が将来的に進行することになります。

移行を開始するには、移行の前にいくつかのステップを実行し、Oracle Supportと連携して移行をスケジュールする必要があります。

  1. サブスクリプションをユニバーサル・クレジット・サブスクリプションに移行します。 これについては、Oracle Salesの担当者にお問い合せください。
  2. Oracle Cloudコンソールを使用したOCI上のOracle Content Managementの「新規インスタンスを作成」。 これは、データの移行先のターゲット・インスタンスです。 移行が完了するまでこのインスタンスを使用しないでください。
  3. 「従来のクラウド・アカウントからユーザーを移行」 to Oracle Identity Cloud Service (IDCS)アカウント。 ロールおよび権限を移行プロセスの一環として適切に割り当てることができるように、ユーザー名を保持してください。 エクスポートしたCSVファイルでは、ユーザー名のエントリはユーザー・ログインと呼ばれます。 アプリケーション・ロールは、「ユーザー・マッピング」に従って割り当てられます。
  4. 「移行の準備」情報を収集することで、サービス・リクエストおよびステップで必要な統合のリストが作成されるため、移行後に実行する必要があります。
  5. 「移行サービス・リクエストを発行」を使用して、移行の日時を確認します。
  6. 「移行の進行状況を確認」。 サービス・リクエストは移行の進行に伴って更新され、完了したら、新しいインスタンスが想定どおりに動作していることを確認するように求められます。
  7. インスタンスと他のサービスまたはアプリケーションとの統合を移行するために必要なステップを完了して、「移行を完了」します。
  8. 「アセットを含むサイトを移行」をインストールし、多言語に準拠するようにします。
  9. 移行から除外された「アセットの移行」。
  10. 変更をユーザーに通知します。

ユーザー・マッピング

この表では、OCIアプリケーション・ロールへのOracle Content Management権限グループのマッピングについて説明します。

Oracle Content Management権限グループ OCIアプリケーション・ロール
DocumentsServiceUser CECStandardUser
DocumentsServiceAdmin CECServiceAdministrator
SitesServiceVisitor CECSitesVisitor
SitesServiceAdmin CECSitesAdministrator
ContentAdministratorRole CECContentAdministrator
CECSStandardUser CECStandardUser
CECSEnterpriseUser CECEnterpriseUser

ノート:

ターゲットIDCSドメインに、同じユーザー名を持つユーザーがすでに含まれている場合、そのユーザーには、ユーザーOracle Content Management権限グループに対応するOCIアプリケーション・ロールが割り当てられます。

移行の準備

  • 作成した新しいインスタンス(「ターゲット」)のURLを書き留めて移行リクエストに含めます。
  • 古いインスタンスのURL (「ソース」)を書き留めて、移行リクエストに含めます。
  • 古いインスタンスに他のサービスまたはアプリケーションが使用しているすべての統合のインベントリを作成します。これらは直接またはREST APIコールを介して行います。 このような統合がある場合は、移行後にアクションを実行する必要があります。

移行サービス・リクエストの発行

移行の準備が整ったら、移行リクエストを発行してプロセスを開始する必要があります:

  1. Oracle Cloud Supportにサインインします。
  2. 新規サービス・リクエストを作成します。
  3. 「問題タイプ」の場合は、「サービス・インスタンスの移行」を選択してから、「非従量制サブスクリプションからOCI-Gen2」を選択します。
  4. サービス・リクエストに次の情報を入力します:
    • ソース・インスタンス(移行元のインスタンス)のURL
    • ターゲット・インスタンス(移行先のインスタンス)のURL
    • Oracleで提供されるAkamaiを使用している場合、移行後にAkamai構成のURLを更新する時間を調整するようにしてください
  5. 移行を開始する優先日を指定します。 2週間の事前通知をお勧めします。

    ノート:

    リクエスト日に基づいて移行のスケジュールを試みますが、競合する進行中のアクティビティがあると、常に可能とはかぎりません。
  6. サービス・リクエストを発行します。

    Oracle Supportが移行サービス・リクエストを受信すると、移行サービス・リクエストはあなたとOracleで機能する日付を確定するために連携し、サービス・リクエストは移行が開始する日時で更新されます。

  7. 移行の開始日時を承認するサービス・リクエストを確認します。

サービス・リクエストに対して更新が行われ、移行の進行状況が表示されます。 データの移行はバックエンドで実行されます。サービス・リクエストの更新を保持しないという以外の最後にアクションは必要ありません。また、完了後に移行を検証する必要もありません。

移行プロセス

移行時の処理は次のとおりです:

  1. Oracle Supportは、移行の開始時にサービス・リクエストを更新します。

    重要:

    この時点では、古い(ソース)インスタンスを変更しないでください。 移行開始後に行われた変更は、新しいインスタンスに移行されません。
  2. コンテンツおよび構成データが古いインスタンス(「ソース」)からエクスポートされ、新規インスタンス(「ターゲット」)にインポートされます。
  3. 移行が完了すると、Oracle Supportでサービス・リクエストが更新され、すべてが正常に機能していることを確認するために、新しいインスタンスの検証が求められます。
  4. 問題が見つかった場合は、サービス・リクエストでそれをノートします。 Oracle Supportは問題を解決する働きをし、インスタンスの検証準備ができたときにサービス・リクエストを確認します。
  5. すべてを予期したとおりに動作している場合は、移行したインスタンスを受け入れるサービス・リクエストを確認します。

ノート:

古いインスタンスは、検証のために参照して再度参照できるように稼働し続けます。 また、「アセットを使用するサイトの移行」や、移行時に除外された「他のアセットの移行」も必要になります。

移行の確定

元のインスタンスが、直接またはREST APIコールにより他のサービスやアプリケーションと統合または通信されている場合は、移行後タスクを実行する必要があることがあります。

次のアイテムがサービス全体に適用されます:

  • OCIアプリケーション・ロールを確認し、ソース・インスタンスに存在しなかったロール(CECRepositoryAdministratorアプリケーション・ロールなど)を割り当てます。
  • ユーザー資格証明を使用するすべての統合に対するユーザー資格証明を再構成します。 資格証明は移行されません。
  • Oracle Content Management URLパターンが異なるため、使用する統合のURLを更新する必要があります。

    古いURLは次のパターンを使用していました:

    https://<service-name>-<account-name>.<region>.oraclecloud.com/documents

    次のパターンを使用した新しいURL:

    https://<service-name>-<account-name>.<service-type>.ocp.oraclecloud.com/documents

  • CORS設定および「埋込みコンテンツ」設定を再構成します。 ターゲット・サービス設定は移行されません。
  • Standardサイトは移行されますが、エンタープライズ・サイトは移行されません。 エンタープライズ・サイト、各エンタープライズ・サイト用の「テンプレートの作成」によってサイトに関連付けられているデジタル・アセットおよびコンテンツ・アイテム、ソース・インスタンス用の「テンプレートのエクスポート」と「インポート」をターゲット・インスタンスに手動で移行します。
  • 移行されたサイトで使用されているカスタム・コントローラを削除または更新します。
統合 移行後に実行するアクション
Oracle Integration
  • 資格証明を再構成します。
  • Oracle Integration CloudのOracle Content Management URLを更新します。
Oracle Commerce Cloud
  • 資格証明を再構成します。
  • Oracle Commerce CloudのOracle Content Management URLを更新します。
Oracle Process Cloud Service
  • 資格証明を再構成します。
Oracle Eloqua Cloud Service
  • 資格証明を再構成します。
Oracle Intelligent Advisor
  • 資格証明を再構成します。
Oracle Cobrowse Cloud Service
  • 資格証明を再構成します。
Responsys
  • 資格証明を再構成します。
Visual Builder Cloud Service (VBCS)
  • 資格証明を再構成します。
  • VBCSコンポーネントのOracle Content Management URLを更新します。
CDN/Akamai
  • Oracleが提供するAkamaiを使用する場合は、Oracle Supportを使用して時間を調整し、Akamai構成のOracle Content Management URLを更新します。 それ以外の場合は、CDN構成のURLを自分で更新する必要があります。
REST APIコール
  • REST APIコールのOracle Content Management URLを更新します。
クライアントのSDK/CLI使用
  • URLがクライアント側でローカルに永続化/キャッシュされている場合は、構成のOracle Content Management URLを更新します。
コネクタ
  • 資格証明を再構成します。

ノート:

古いインスタンスのコンテンツに対するブックマークは、新しいインスタンスのURLが変更されているため、機能しなくなります。

アセットを含むサイトの移行

「しない」にアセットが含まれるサイトは自動的に移行されますが、doにアセットが含まれるサイトでは、新しいOracle Content Managementインスタンスでそれらを機能させるために追加のステップが必要です。

  1. Oracle Content Management Toolkitをインストールします。
  2. ターゲット・サーバーを登録します。
  3. サイトを移行します。
  4. 移行後のステップを実行します。
  5. 移行済サイトを多言語サイト(MLS)に準拠させます。

Oracle Content Management Toolkitのインストール

「cec migrate-site」コマンドは新しいコマンドであるため、以前にダウンロードしてインストールした場合でも、Oracle Content Management Toolkitをwebclient gitリポジトリからインストールする必要があります。

「サイト・ツールキット・ページ」の指示に従って、Oracle Content Management Toolkitをダウンロードしてインストールします。

ターゲット・サーバーの登録

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

> 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. ターゲット・サーバーでは、移行されたサイトおよびアセットを適切に共有します。

移行後のステップ

サイトを移行すると、Content REST v1.1コールを使用してサイトが実行されます。 これにより、サイトが正常に実行される前に解決する必要がある問題が生じる場合があります。 次の内容を確認します:

  • ContentSDKを使用している場合は、v1.1 Content RESTコールを使用するように、コールが自動的に更新されます。
  • コンテンツ・レイアウトでv1.1がサポートされていないと、ContentSDKがレスポンスでデータ・エントリ(v1.0)にも追加されます。これは単にフィールド・エントリ(v1.1)を指すため、テンプレートが変更なしで機能し続ける可能性があります。
  • 追加の問合せ文字列で"fields.type.equals=" v1.0 Content REST構文を使用している場合、これをv1.1構文として解析および変更しようとしますが、検証する必要があります。
  • (ContentSDKではなく)コンテンツREST v1.0コールを行うと、これらは失敗します。 カスタム・コードを修正して、これらのコールをアップグレードする必要があります。
  • 同様に、"fields.type.equals=" v1.0構文を'q ="(type eq "..")'構文にするカスタム・コンテンツ問合せも必要です。
  • "updateddate" vs. "updatedDate": これはCaaSにより修正されるものですが、コンテンツRESTのv1.1 APIが両方の値をサポートするECビルドを得るまで、camelCaseのように任意の更新値を変更する必要があります: "updatedDate" value.

移行済サイトの多言語サイト(MLS)への準拠

サイトが正しく稼働している場合、サイトMLS準拠を作成する必要があります。 外部コンピュート・サーバーにエンタープライズ・サイトを作成した場合、デフォルト言語とローカリゼーション・ポリシーが必要です。 サイトが横方向にコピーされた場合、それはMLS以外のサイトであるため、MLSサイトにアップグレードして、将来の機能をサポートできます。

次の表に、MLSサイトと非MLSサイト間の差異を示します。

サイト・オブジェクト MLSサイト 非MLSサイト
コンテンツ・アイテム コンテンツ・アイテムの言語バリアントが表示され、コンテンツ・アイテムはページにドロップされません。 この言語は、サイトのレンダリング時にリクエストされた言語に応じて変更できます。 ページにドロップされたコンテンツ・アイテムは、常に表示されます。
コンテンツ・レイアウト コンテンツ・レイアウトはv1.1 APIをサポートしている必要があります。 コンテンツ・アイテムが表示されない場合は、警告が表示されます。 これは、すべてのv1.1 APIコールに、v1.0 APIでサポートされていないロケールが追加されるためです。 コンテンツ・レイアウトは、v1.0またはv1.1のいずれかです。 コンテンツ・レイアウトがv1.0のみをサポートする場合、ContentSDKは、レスポンスでフィールド・エントリと一致するデータ・エントリを追加します。 他にも問題がある可能性があるため、コンテンツ・レイアウトをアップグレードしない場合は、この問題をサポートされている機能とみなすことはできません。
コンテンツ・リスト リクエストされた言語バリアントで使用可能なコンテンツ・アイテムのみが表示されます。 言語に関係なく、すべてのコンテンツ・アイテムが表示されます。 ユーザーは、コンテンツ・リスト内に、結果を特定の言語に固定するためのオプションを用意しているため、ページに2つのコンテンツ・リストを表示して、異なる言語で結果を表示できます。 この設定パネル・オプションでは、言語をMLSサイトに選択できません。
defaultLocale MLSサイトには、デフォルトのサイト・ロケールがあります。 これは、すべてのコンテンツ問合せが、そのロケール(または翻訳不能)にあるコンテンツ・アイテムのみを返すことを意味します。 非MLSサイトにはデフォルト・ロケールがないため、使用されるコンテンツ問合せは、言語に関係なくすべてのコンテンツ・アイテムを返します。
ローカリゼーション・ポリシー

サイトで使用可能な言語のリストを定義します。 ビルダーにはこれらのドロップダウンがあります。

また、管理UIには、リクエストされた言語でオープン/プレビューできる言語のドロップダウンがあります。

ローカリゼーション・ポリシーがないため、言語を切り替えるドロップダウンはビルダーから削除されます。

管理UIには、デフォルト言語なしを含む言語がリストされていません。 これは、非MLSサイトまたはMLSサイトを管理UIで認識する方法です。

Translation/Translatable 管理UIのコンテキスト・メニューには、翻訳オプションがあります。 これにより、サイトを翻訳する翻訳ジョブを作成できます。

管理UIのコンテキスト・メニューには翻訳可能オプションがあります。 MLS以外は事実上翻訳不能なため、翻訳する前に、翻訳可能(MLS)サイトにしておく必要があります。

これは、MLS以外のサイトからMLSにアップグレードする方法でもあります。

ノート: これは一方向のみです。 翻訳不能にはダウングレードできません。

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

  • すべてのコンテンツ・レイアウト・コンポーネントをアップグレードして、Content REST API v1.1をサポート
  • サイト内のコンテンツ・リスト内の任意の追加問合せ文字列をContent REST API v1.1と互換性があるようにアップグレード

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

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

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

コンテンツ・レイアウトには、サポートするContent 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
          // - Expands 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"プロパティを指すことです。 

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

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

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

コンテンツREST APIの変更 v1.1 v1.0
"fields" vs. "data" 
"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"
        }
    },
camelCaseプロパティ名 "updatedDate" "updateddate"
問合せフォーマット /items?q=(type eq "Starter-Blog-Author") /items?fields.type.equals="Starter-Blog-Author"
APIバージョン /content/management/api/v1.1/items /content/management/api/v1/items
言語固有の問合せ /content/management/api/v1.1/items?q=((type eq "Promo") and (language eq "en-US" or translatable eq "false"))

サポートされていません。

"language"オプションを含めるには、カスタムv1コールをすべて移行する必要があります。

これにより、特定の言語で表示された場合にMLSサイトに返される結果と一致するようになります。

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

コンテンツAPIコールはカスタム・コード内で行うことができるため、コンテンツREST APIコールを実行しているサイトで使用されるすべてのカスタム・コードを検証する必要があります。

  • カスタム・コンポーネント : 次のコンポーネントを確認します:
    • コンテンツ・レイアウト
    • ローカル・コンポーネント
    • セクション・レイアウト
    • リモート・コンポーネント
  • テーマ: JavaScript: あまりないことですが、カスタム・コンテンツのREST APIコールを作成するテーマにJavaScriptがあると、これらも検証されます。
  • サイトのプロパティ: 追加問合せ文字列: コンテンツREST APIコールを作成しているすべてのカスタム・コードをアップグレードしたことを検証したら、サイト内の任意のページのコンテンツ・リスト・コンポーネントで追加問合せ文字列もアップグレードする必要があります。 これらを実行時に解析して変換しようとする一方で、v1.1 Content RESTコールの互換性を維持するようにアップグレードする必要があります。

非MLSサイトのMLSへの変換

サイトをv1.1 Content REST APIを完全にサポートするように変換した後は、MLSサイトに変更することで言語のサポートを追加できます。

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

このステップが完了すると、サイトがデフォルト・ロケールでレンダリングされます。 また、ローカリゼーション・ポリシーで指定されている他のロケールに切り替えることもできます。

デフォルト・ロケールでサイトが正しくレンダリングされることを検証する必要があります。

アセットの移行

サイトに関連付けられているアセットは、サイトを移行するときに移行されますが、サイトに関連付けられていないアセットは個別に移行する必要があります。

移行を開始する前に、次の点を考慮してください:

  • コレクションに関連付けられているアセットのみを移行できます。 コレクションに関連付けられていないアセットを移行する場合は、移行する前にコレクションに追加する必要があります。
  • 非従量制インスタンスはアセットに対する言語をサポートしていないため、アセットを移行するときに、デフォルト言語はリポジトリのデフォルト言語から継承されます。 アセットを移行する前に、リポジトリのデフォルト言語が必要なデフォルト言語に設定されていることを確認してください。
  • 公開された品目のみが移行されます。 移行後にアイテムが欠落している場合は、ソース・インスタンスでアイテムが公開されていることを確認します。
  • 公開済アイテムにドラフト・バージョンがある場合、ドラフト・バージョンはターゲット・インスタンスで公開済バージョンになり、ソース・インスタンスの元の公開済バージョンは失われます。
  • 非従量制バージョンのOracle Content Managementでは、コンテンツ・アイテムを表示するときに、「コンテンツ・レイアウト」ビューまたは「コンテンツ」ビューを選択できます。 「コンテンツ」ビューは、現在のバージョンのOracle Content Managementで「コンテンツ・フォーム・ビュー」に置き換えられ、「コンテンツ・レイアウト」ビューが削除されました。

アセットを移行するには、次のステップを実行します:

  1. 「Oracle Content Management Toolkitのインストール」をまだ実行していない場合。
  2. ソース・サーバーとターゲット・サーバーを登録します。
  3. アセットのコレクションを移行します。

ソース・サーバーおよびターゲット・サーバーを登録

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

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

> 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>

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

ユーザーに対する変更の通信

ユーザーに新しいサービスURLを通知します。 デスクトップおよびモバイル・ユーザーは、新しいアカウントでデバイスを構成し、すべてのコンテンツを再同期する必要があります。