クローンを要求

クローンを要求して、本番インスタンスから非本番インスタンスにデータをコピーしたり、非本番インスタンス間でデータをコピーしたりします。

始める前に

必要なロール:clone_admin

注:

ソースインスタンスの目的が DART (担当トレーニングのデータアクセス) である場合、クローンは有効ではなく、エラーメッセージが表示されます。

手順

1. 移動先 すべて > クローンアドミンコンソール > クローンホーム.
2. [クローンを要求] を選択します。
3. フォームのフィールドに入力します。

   表 : 1. クローン要求フォーム

   フィールド	説明
   ソースインスタンス	データのコピー元の元のデータベース。
   ターゲットインスタンス	データのコピー先の新しい場所。 注: ページを離れることなく、インスタンスを追加したり、既存のインスタンスを選択したりできます。
   クローンプロファイル	以前に作成したクローンプロファイルを適用します。プロファイルに追加したすべての除外、プリザーバー、およびスクリプトがクローン要求に適用されます。 注: クローンプロファイルで デフォルト がオンになっている場合、クローン要求は、クローン要求ページを開くたびにこのプロファイルをロードします (クローンアドミンコンソール v.1.0.18 以降)。
   クローン予定開始時間	インスタンスのクローン作成を開始する時間。
   完了時メール	クローン完了を通知するメールアドレス。
   外部メールアドレス	クローンプロセス中にクローン通知を送信する外部メール。

4. クローンを構成するために次のオプションを選択します。
   注:

   クローン要求に対して追加の設定を構成できますが、一部のオプションを使用するとクローン完了時間が大幅に長くなる可能性があります。

   表 : 2. クローンオプション

   フィールド	説明
   除外リストに指定されたテーブルを除外	次に表示されているソースインスタンスのテーブルからレコードをクローン作成できないようにします。 インスタンスクローン > 除外テーブル. テーブルが除外リストに含まれている場合、クローンではそのテーブルのレコードと子テーブルのレコードが除外されます。 テーブルを除外しても、そのテーブルスキーマと階層は引き続きターゲットインスタンスにクローンされます。その結果、クローンの完了後には空であるが使用可能なテーブルがターゲットインスタンスに存在することになります。 注: ServiceNow の初期設定の除外テーブルは引き続き除外され、この設定による影響は受けません。これには、監査、ライセンス使用状況、ログ記録、および通知を含むテーブルが含まれます。 除外されたテーブルのデータが必要な場合は、この設定を無効にできます。 従来のクローンエンジンはこのオプションをサポートしていません。 デフォルト設定では、除外リストに指定されたテーブルはクローンから除外されます。
   監査およびログデータを除外	ソースインスタンスからの監査レコードおよびログレコードのクローン作成を防止します。これにより、空であるが使用可能な監査テーブルとログテーブルがターゲットインスタンスに作成されます。 注: クローンから監査データとログデータを除外すると、レコードのアクティビティストリームがソースインスタンスと一致しなくなります。これは、Activity Stream は監査テーブルに基づいて履歴を生成するためです。 デフォルト設定では、監査データとログデータはクローンから除外されます。
   添付ファイルデータを除外	次のような特定のファイルのクローン作成を防止します。 動画ファイル 画像ファイル その他の大きなバイナリファイル (sys_attachment テーブルからのもの) 注: ServiceNow のすぐに利用可能な添付ファイルやその他のシステム関連ファイル (カタログアイテムの画像、テーマの画像、アイコンなど) は、この設定の影響を受けません。 次に示す ServiceNow のすぐに利用可能な添付ファイルおよびその他のシステム関連ファイルは、この設定の影響を受けず、クローンから除外されません。 「ZZ_」で始まるテーブル名の値。 テーブル名：sys_certificate、sc_cat_item、sys_upgrade_manifest、ecc_agent_jar、ecc_agent_mib、sys_store_app、または invisible.sys_store_app。 デフォルト設定では、添付ファイルのデータは除外されます。
   テーマを保存	ターゲットインスタンスのテーマと CSS 要素を保持します。その結果、クローン後もターゲットインスタンスのテーマとルックアンドフィールが保持されます。 デフォルト設定では、ターゲットインスタンスでテーマが保持されます。
   このクローン要求に対するロック設定	クローンプロファイルを使用する場合、このオプションはクローン要求時に設定およびオプションをロックします。クローンプロファイルに対するその後の変更は、クローンの実行タイミングに関係なく、クローン要求には影響しません。 このオプションはデフォルトでは選択されていません。
   特定のテーブルからコピーされたデータの量	タスクテーブルとその子テーブル (インシデント、問題、変更のテーブルなど) の履歴データの日数を 90 日間に制限します。 クローン作成時間を短縮するには、大きなテーブルをまとめて除外することを検討してください。テーブルを除外すると、ターゲットインスタンスにはソースインスタンスと同じテーブルスキーマと階層 (つまり、空の使用可能なテーブル) が作成されます。 デフォルト設定では、タスクテーブルとその子テーブルのすべてのデータがターゲットインスタンスにクローンされます。
   進行中の更新セットを保存	グローバルアプリケーションスコープで過去 90 日間分の進行中の更新セットを保存します。このオプションを使用すると、ターゲットインスタンスで過去 90 日以内に作成された進行中のグローバル更新セットを保持できます。 注: このオプションでは、進行中のスコープ対象の更新セットは保持されません。90 日より古い更新セットは保存されません。クローンを作成する前に、更新セットを確認してコミットすることをお勧めします。デフォルトでは、更新セットは保持されません。
   クローン頻度	このオプションを使用すると、ソースからターゲットインスタンスへの繰り返しクローンをスケジュールできます。クローンの頻度と最大発生回数を定義できます。デフォルトでは、クローン頻度は [なし] に設定されています。クローン作成のスケジュールの詳細については、「 定期的なクローンのスケジュール」を参照してください。

5. [Continue (続行)] を選択します。
6. クローン要求のサマリーを確認し、[クローン要求を確認して送信 (Confirm and Submit Clone Request)] を選択します。

クローンの要求 (従来の UI)

クローンを要求して、本番インスタンスから非本番インスタンスにデータをコピーしたり、非本番インスタンス間でデータをコピーしたりします。

始める前に

必要なロール:clone_admin

オーストラリアリリース以降、クローン要求は従来のページで展開、拡張、またはサポートされなくなりました。

注:

従来のページ clone_instance.do を介して開始された要求は、新しいクローンコンソールのホームページには表示されません。ただし、従来のクローン履歴ページ clone_instance_list.do で見つけることができます。

• Oracle データベースを使用するインスタンスについては、「 KB0538884 - Oracle のお客様向けインスタンスクローンのサポート」を参照してください。

• オプションパネルでスケジュール設定することで、繰り返しクローンを設定できます。

クローンを要求する前に、ターゲットインスタンスを構成します。次の操作を実行します。

• に移動します 構成 > インスタンスをクローン.
• [New (新規)] を選択します。
• 新しいクローンインスタンスフォームに入力します。

クローンプロファイルを構成します。次の操作を実行します。

• 移動先 構成 > クローンプロファイル.
• 新しいクローンプロファイルフォームに入力します。
  注:

  複数のクローンプロファイルを作成でき、再利用可能なクローンテンプレートを利用できます。クローンプロファイルを使用すると、クローンの正しい除外とプリザーバーを選択できます。

このタスクについて

ServiceNow AI Platformクローン作成時に、ソースインスタンスの最新の日次バックアップのデータを使用します。クローン作成に使用されるバックアップは、経過時間が 36 時間以内のものです。インスタンスクローンは、使用する最新のバックアップの選択を含む初期準備を、処理の開始がスケジュールされている日時にのみ開始します。

手順

1. クローンを作成するインスタンスにログインします。
   このインスタンスがクローン要求のソースインスタンスになります。
2. クローンデータを受信するターゲットインスタンスごとに クローンターゲット (登録と認証) レコードを構成します。
3. クローン作成から除外されるテーブルのリストを確認し、ターゲットインスタンスから除外するテーブルを追加または削除します。
4. ターゲットインスタンスに保存する、必要なテーブルとシステムプロパティのリストを確認します。

   保存の際にはデータプリザーバーを使用できます。必要に応じて、データプリザーバーを作成または変更することもできます。

5. ターゲットインスタンス上の未公開のアプリケーションを保持します。
6. 移動先 インスタンスクローン > クローンを要求.
7. オプション: 事前定義されたクローンプロファイルを指定します。
   クローンプロファイルには、ターゲットオプションとクローンオプションが格納されます。クローンプロファイルにより、選択したプロファイル設定がクローン要求に自動的に入力されます。「クローン要求のクローンプロファイル」を参照してください。
8. [ターゲットインスタンス] フィールドで、クローンされたデータを受け取るターゲットインスタンスを選択します。
   クローンデータを受信するターゲットインスタンスごとに個別のクローン要求を作成します。
9. [クローン予定開始時間] フィールドで、クローン作成を開始する時間を選択します。
   同じソースインスタンスに対して複数のクローン要求をスケジュールできます。たとえば、データを非本番インスタンス A にコピーするクローン要求と、データを非本番インスタンス B にコピーする別のクローン要求を作成します。スケジューリングエンジンは、同じソースインスタンスに対する複数のクローン要求が同時に発生する可能性があるかどうか、またはそれらが連続して発生する必要があるかどうかを判断します。ソースインスタンスが非常に大きい場合は、クローンチェーンをお勧めします。「 インスタンスクローンの詳細のクローンチェーン」を参照してください。
   システムは予定開始時間を確認し、選択した日時値を受け入れるか、使用可能な日時値を提案します。検証プロセスは、同じターゲットインスタンスを使用する他の自動化とのスケジュールの競合を防止します。
10. クローン作成の完了後、キャンセル後、またはエラーが発生した後にアラートを受信できるように、[ 完了時メール (Email on completion )] フィールドにメールアドレスを入力します。
11. [オプション] の矢印をクリックして下向きにします。
12. オプションを入力します。
13. [Submit (送信)] を選択します。
    クローン要求に問題がない場合、[ターゲットを認証 (Authenticate Target)] モーダルが表示されます。
14. [ユーザー名] および [パスワード] フィールドに、ターゲットインスタンスのアドミニストレーターアカウントのユーザー名とパスワードを入力し、[認証] をクリックします。
15. クローン設定を確認し、[OK] をクリックします。
    クローンが完了するか、キャンセルされるか、エラーが発生すると、指定されたアドレスにメールが送信されます。

次のタスク

以下のことを行うことができます。

• 繰り返しクローンをスケジュールします。
• クローン要求をキャンセルする。
• 完了したクローンのクローン履歴を表示します。

クローンターゲット (登録と認証)

クローンターゲットレコードは、クローン作成に使用されるインスタンス URL と認証情報を指定します。

始める前に

• admin ロールを持つユーザーのターゲットインスタンスの認証情報を指定します。LDAP または SSO ユーザーアカウントではなく、ローカルユーザーアカウントを使用します。ターゲットインスタンスの認証情報は、ユーザーレコードまたは LDAP 統合の一部としてユーザー [sys_user] テーブルに存在する必要があります。クローン要求は、認証要求をシングルサインオン ID プロバイダーにリダイレクトできません。
• システムプロパティ glide.db.clone.allow_clone_target が True に設定されていることを確認します。デフォルトでは、このプロパティは、名前が Dev、Test、Stage、UAT、または QA で終わるインスタンスで有効になります。
• ターゲットインスタンスが IP 範囲ベースの認証を使用する場合、IP 範囲 10.0.0.0/10.255.255.255 をローカルネットワーク上で通信できるようにする必要があります。
• 必要なロール:clone_admin

手順

1. 移動先 すべて > システムクローン > クローンターゲット.
2. [New (新規)] を選択します。
3. 受信インスタンス (ターゲット) の URL を入力します。

   インスタンスがクローンターゲットを有効にし、高可用性クローン作成がアクティブであることが検証されます。本番インスタンスとデモインスタンスでは、これらの検証チェックはできません。

   図 : 1. 無効なクローンターゲット

   

4. ターゲットインスタンスの admin ロールを持つユーザーアカウントのベーシック認証情報を入力します。

   

   注:

   1 つのソースから複数のターゲットをクローンするには、ターゲットごとに個別のクローン要求を発生させる必要があります。
   ユーザーの認証情報にターゲットインスタンスへの clone_admin および SOAP アクセス権があることが検証されます。
5. [Submit (送信)] を選択します。
   接続性がチェックされ、ターゲットインスタンスに対するユーザーの認証情報が検証されます。

クローン作成中のターゲットインスタンスからのデータの保持

データプリザーバーを使用して、ターゲットインスタンスのデータが上書きされないようにすることができます。カスタムアプリケーションがある場合は、未公開のアプリケーションコンテンツも手動で保持する必要があります。

データプリザーバー

クローン作成対象のインスタンスでデータを保持する必要がある場合があります。たとえば、ターゲットが MID サーバーの場合、MID サーバー [ecc_agent] テーブルを上書きしてはなりません。除外が完了した後、保持されたデータはターゲットインスタンスに再適用されます。

警告:

ソースインスタンスでデータプリザーバーを定義する必要があります。ターゲットインスタンスで定義しても、データは保持されません。

データプリザーバーは通常、次のようなシステム設定とテーマを保持します。

• インスタンス固有の認証設定
• ブックマーク [sys_ui_bookmark]
• 最近の選択 [sys_ui_recent_selection]
• ユーザー設定 [sys_user_preference]

注:

クローンは、データベースビューからのデータの保持をサポートしていません。

データプリザーバーを使用して、ユーザーグループなどの大量のデータを転送しないでください。ユーザー、グループ、ロールなどのテーブルデータを保持する必要がある場合は、クローン作成後にレコードをファイルにエクスポートすることを検討してください。

マルチ SSO のデータプリザーバー

複数プロバイダーのシングルサインオン統合をアクティブにすると、クローン作成に必要なデータプリザーバーが自動的に作成されます。

名前	テーブル	条件
証明書	X.509 証明書 [sys_certificate]	なし
コアインスタンスのプロパティ	システムプロパティ [sys_properties]	[または] [名前] [は次のいずれか] [glide.authenticate.external, glide.authenticate.external.logout_redirect] [または] [名前] [次で始まる] [com.snc.integration.saml_esig] [または] [名前] [は次のいずれか] [glide.smtp.port、glide.smtp.auth、glide.smtp.encryption] [または] [名前] [は次の値で始まる] [glide.authenticate.multisso] [または] [名前] [次の値に等しい] [glide.authenticate.sso.redirect.idp] 注: プロパティ glide.smtp.port、 glide.smtp.auth、および glide.smtp.encryption は廃止されました。
ダイジェストプロパティ	ダイジェストプロパティ [digest_properties]	なし
ID プロバイダー	ID プロバイダー [sso_properties]	なし
SAML2 Update1 プロパティ	SAML2 Update1 プロパティ [saml2_update1_properties]	なし

注:

これらのデータプリザーバーは変更できますが、変更しないことをお勧めします。複数のソースの シングルサインオン (SSO) が正しく機能するには、ダイジェストプロパティ [digest_properties]、ID プロバイダー [sso_properties]、および SAML2 Update1 プロパティ [saml2_update1_properties] テーブルが必要です。ターゲットインスタンスで複数のソースの シングルサインオン が無効になっている場合は、3 つのデータプリザーバーをすべて安全に削除できます。これらのテーブルのうち 1 つまたは 2 つが保持された状態でクローンを作成しようとすると、エラーメッセージが表示されてクローンが終了するため、それらを同時に削除します。

SAML のデータプリザーバー

SAML SSO 関連の設定を保持すると、ターゲットインスタンスが IdP への認証要求を行うときに間違った発行者と対象者のパラメーターを使用するのを防ぐことができます。SAML 設定を保持するには、次のテーブルのデータプリザーバーを作成します。

• システムプロパティ [sys_properties]：SAML プロパティを保持します。
• X.509 証明書 [sys_certificate]：SAML 証明書を保持します。
• ユーザー [sys_user]：SAML ユーザーを保持します。

SAML に関連するプロパティとユーザーも保持する必要があります。

未公開アプリケーションの保持

データプリザーバーを使用して未公開のアプリケーションを保存することはできません。代わりに、アプリケーション開発者は未公開のアプリケーションを保持する方法を選択する必要があります。

クローン作成プロセスでは、開発中のアプリケーションのバージョンの差異は保存されません。その代わりに、システムクローンでは、ソースインスタンスにインストールされているアプリケーションバージョンのみが、ターゲットインスタンスにコピーされます。ターゲットインスタンスに同じアプリケーションの開発バージョンがある場合、そのアプリケーションはクローン作成後に編集可能になりますが、ソースインスタンスにインストールされているバージョンになります。アプリケーションがソースインスタンスから失われていた場合は、クローン作成プロセスによりターゲットインスタンスからアプリケーションが削除されます。

データプリザーバーの作成

データプリザーバーは、指定されたデータをターゲットインスタンスで維持します。

始める前に

必要なロール:clone_admin

このタスクについて

ターゲットインスタンスの特定のデータを保持することが望ましい場合があります。たとえば、MID サーバーを使用している場合は、MID サーバー [ecc_agent] テーブルの上書きを回避できます。保持されたデータは、クローンの前にターゲットインスタンスで動的に生成されたリストに保存され、クローンの完了後にターゲットインスタンスで復元されます。ソースインスタンスでデータプリザーバーを定義します。

データプリザーバーは、主にインスタンス固有の認証設定などのシステム設定とテーマを保持することを目的としています。データプリザーバーを使用して、ユーザーグループなどの大量のデータを転送しないでください。ユーザー、グループ、ロールなどのテーブルデータを保持する必要がある場合は、レコードをファイルにエクスポートし、クローンの完了後にインポートすることを検討してください。

次のテーブルのデータを保持するかどうかを検討してください。

• ブックマーク [sys_ui_bookmark]
• 最近の選択 [sys_ui_recent_selection]
• ユーザー設定 [sys_user_preference]

ソースインスタンスがターゲットインスタンスよりも多くのレコードを持つテーブルにデータプリザーバーを設定した場合、ターゲットインスタンスに保持されるデータにはソースインスタンスの追加レコードも含まれます。

たとえば、データプリザーバーが既に配置されているとします。

• ソースインスタンスでは、sys_temp テーブルに 100 のレコードが含まれています。
• ターゲットインスタンスでは、sys_temp テーブルに 20 のレコードが含まれています。

クローンの後、ターゲットインスタンスの sys_temp テーブルには 100 のレコードが含まれます。

• ターゲットの sys_temp テーブル内の 20 のレコードは正常に保持されます (データプリザーバーの仕様に準拠)。これらのレコードは、ソースの sys_temp テーブルの 100 のレコードの一部でした。
• ソースの sys_temp テーブルは、残りの 80 のレコードをターゲットの sys_temp テーブルに渡します。

この問題を解決し、ターゲットテーブルのレコードのみを保持するには、ソーステーブルでデータプリザーバーを設定することに加えて、ターゲットテーブルの除外テーブルレコードを作成します。

重要:

ソースインスタンスでプリザーバーを設定します。

手順

1. ソースインスタンスで、次の場所に移動します: システムクローン > データを保存.
2. [New (新規)] を選択します。
3. テーブルラベルを [名前] として入力します。たとえば、[sys_user_preference] テーブルの場合は「ユーザー設定」です。
   データプリザーバーにはテーブル名が必要です。指定しないと送信できません。
4. 保持する [テーブル] を選択します。
   データプリザーバーではテーブルを選択する必要があります。指定しないと送信できません。
5. 保持されるデータが UI プロパティの場合は、[テーマ] チェックボックスをオンにします。
6. 保持するデータを定義するには、条件ビルダーを使用します。
   条件を使用して、クローン中に保持する特定のレコードを定義できます。たとえば、特定のシステムプロパティのみを保持する場合は、保持するプロパティ名ごとに条件を追加できます。

   注:

   正規表現に一致する条件 [match regex] はサポートされなくなりました。

   

7. [Submit (送信)] を選択します。
   後でデータプリザーバーを削除する場合は、次のデータプリザーバーレコードを変更または削除しないようにしてください。

   • コアインスタンスのプロパティ
   • セマフォ
   • メールアカウント

   注:

   DB ビューは保持できません。

   プリザーバーを空にすることはできません。プリザーバーが空の場合、ユーザーはクローンを送信できません。

SAML プロパティの保持

クローンターゲットインスタンスで既存の SAML 統合を維持する場合は、[コアインスタンスのプロパティ] データプリザーバーを編集して SAML プロパティを含める必要があります。

始める前に

必要なロール：admin

手順

1. 移動先 すべて > システムクローン > データを保存.
2. [コアインスタンスのプロパティ] を選択します。
3. 次の [条件] を追加します。
   • [または] [名前] [は次のいずれか] [glide.authenticate.external、glide.authenticate.external.logout_redirect、glide.authenticate.failed_requirement_redirect]
   • [または] [名前] [は次の値で始まる] [glide.authenticate.sso.saml2]
   • [または] [名前] [次で始まる] [com.snc.integration.saml_esig]

   

   注:

   インスタンステーマを保持するかどうかに関係なく、これらのプロパティが保持されるように、[テーマ] チェックボックスがオフになっていることを確認します。
4. [更新] をクリックします。

システムクローン中の開発におけるアプリケーションとカスタマイズの保持

アプリケーションバージョンをターゲット (開発) インスタンスにクローンする前に、現在開発中の各アプリケーションとカスタマイズ内容のコピーを手動で保持します。

始める前に

必要なロール：admin

アプリケーションレコードへの書き込みアクセス権とソースコントロールリポジトリへのアクセス権があることを確認します。

このタスクについて

クローン作成プロセスでは、開発中のアプリケーションとアプリのカスタマイズのバージョンの違いは保持されません。代わりに、システムでは、ソースインスタンスにインストールされているアプリケーションとアプリのカスタマイズのバージョンのコピーのみを、ターゲットインスタンスにクローンします。ターゲットインスタンスに同じアプリケーションの開発バージョンがある場合、そのアプリケーションはクローン作成後に編集可能になりますが、そのバージョンはソースインスタンスにインストールされているものと同じになります。アプリケーションがソースインスタンスから失われていた場合は、クローン作成プロセスによりターゲットインスタンスからアプリケーションが削除されます。

手順

1. 次のいずれかのアクションを行い、クローンターゲットインスタンスでアプリケーションを保持します。

   表 : 3. インスタンス間のバージョンの差異

   アプリケーションバージョンの状態	実行するアクション
   クローンターゲットインスタンスのアプリケーションバージョンが、ソースインスタンスバージョンと異なります。	クローンターゲットインスタンスから各アプリケーションをエクスポートします。次の選択肢があります。 各アプリケーションをソースコントロールリポジトリにリンクします。 注: アプリケーションが既にソースコントロールリポジトリにリンクされている場合は、最新のバージョンをコミットします。 各アプリケーションを更新セットに公開します。
   アプリケーションは、クローンターゲットインスタンスでのみ利用できます。
   クローンターゲットインスタンスのアプリケーションバージョンは、ソースインスタンスと同じです。	なし。システムクローン作成プロセスにより、クローン作成中にこのアプリケーションバージョンがターゲットインスタンスにコピーされます。

2. ターゲットインスタンスに対するソースインスタンスのシステムクローンを要求します。
   たとえば、開発インスタンスに対して本番インスタンスのクローンを作成します。
3. クローン作成プロセスが終了したら、クローンターゲットインスタンスにログインします。
4. 注:

   ソースコントロールがリンクされている場合、クローン後に、プラットフォームはアプリケーションとカスタマイズされたアプリケーションを自動的に取得します。これが glide.source_control.post_clone_import_enabled で無効になっている場合は、次の手順を使用して手動で取得する必要があります。
   各アプリケーションをソースコントロールリポジトリに保存した場合は、次のいずれかのアクションを使用してソースコントロールリポジトリからアプリケーションを取得します。
   注:

   アプリケーションのカスタマイズのクローンの後に起こることについては、「アプリケーションのカスタマイズのクローン後の結果」を参照してください。

   表 : 4. ソースコントロールリポジトリからのアプリケーションの取得

   アプリケーションのインストール状態	クローンターゲットで実行するアクション
   アプリケーションとカスタマイズ内容は以前にソースインスタンスにインストールされていました。	ソースコントロールリポジトリからリモート変更を適用します。
   アプリケーションはソースインスタンスにインストールされていませんでした。	リポジトリ構成 (sys_repo_config) を削除し、ソースコントロールリポジトリからカスタマイズをインポートします。

   表 : 5. クローン後のリモート変更

   フィールド	説明
   glide.source_control.post_clone_import_enabled	リモート変更の適用の自動化を無効にするには、False に設定します。デフォルト値は True です。
   glide.source_control.post_clone_import_delay_time_sec	キューの処理を遅延させる遅延時間を指定するには、値を指定します。デフォルト値は 0 です。
   glide.source_control.post_clone_import_pause_refresh_time_sec	リポジトリのリフレッシュジョブを実行しない間隔を指定するには、値を指定します。デフォルトは 3 時間 (10800) です。

5. 各アプリケーションを更新セットに保存した場合は、次のいずれかのアクションを行って更新セットからアプリケーションを取得します。

   表 : 6. 更新セットからのアプリケーションの取得

   アプリケーションのインストール状態	クローンターゲットで実行するアクション
   アプリケーションは以前にソースインスタンスにインストールされていました。	ソースインスタンスからクローンされたアプリケーションバージョンを削除します。 現在のアプリケーションバージョンを含む更新セットをロードします。
   アプリケーションはソースインスタンスにインストールされていませんでした。	現在のアプリケーションバージョンを含む更新セットをロードします。

タスクの結果

以前に開発していたアプリケーションを利用して、クローンターゲットインスタンスでさらに開発を進めることができます。

Marketing Events アプリケーションの保存

あなたの会社が、以前に Marketing Events という名前のカスタムアプリケーションのバージョン 1.0 を作成していたとします。Marketing Events アプリケーションのバージョン 1.0 をアプリケーションリポジトリに既に公開していて、本番インスタンスにインストールしています。

時間の経過とともに、ユーザーからアプリケーションの拡張の要求が提出され、この要求に対処するために、非本番インスタンスで Marketing Events アプリケーションのバージョン 2.0 を開発することに決めました。開発が完了に近づくと、包括的なテストのために、非本番インスタンスを最新の本番環境のコピーに更新する必要が生じました。

以前にソースコントロール統合を使用して Marketing Events アプリケーションのバージョン 1.0 を開発していたため、既に Marketing Events アプリケーションをソースコントロールリポジトリにリンクしています。Marketing Events アプリケーションのバージョン 2.0 をソースコントロールリポジトリにコミットします。

開発インスタンスに対する本番インスタンスのクローン作成をスケジュール設定します。完了したら、開発インスタンスにログインし、Marketing Events アプリケーションのバージョン 1.0 があることを確認します。このバージョンが、ソースインスタンスにインストールされたバージョンのためです。

アプリケーションが既にソースインスタンスにインストールされているため、ソースコントロールリポジトリからリモート変更を適用して、最新のアプリケーションバージョンを受信します。開発インスタンスに、今後の開発とテストに利用できる Marketing Events アプリケーションのバージョン 2.0 が追加されました。

クローン要求のクローンプロファイル

クローンプロファイルを使用すると、事前定義されたターゲットとクローンのオプションを保存できます。クローンプロファイルにより、選択したプロファイル設定がクローン要求に自動的に入力されます。

クローンプロファイル

移動先 システムクローン > クローンプロファイル をクリックしてクローンプロファイルを表示します。クローンプロファイルでは、次のことができます。

• 特定のターゲットインスタンスとオプションの設定、除外するテーブル、保持するデータ、および実行するクリーンアップスクリプトを使用してプロファイルを作成する
• クローンプロファイルからクローン要求を直接作成する
• クローン要求へのクローンプロファイルの適用
• プロファイルのクローンを作成して、既存のプロファイルと同じ権限と設定で新しいプロファイルを作成できます。

[クローンプロファイル] ビューからクローンプロファイルを作成、編集、削除できます。システムプロファイルは、削除できない読み取り専用のクローンプロファイルです。テーブル除外、データプリザーバー、およびクリーンアップスクリプトの事前定義されたリストが表示されます。このリストは、インスタンスに含まれるプラグインに基づいています。

クローンを要求するときに使用するデフォルトプロファイルとして新しいクローンプロファイルを設定するには、[デフォルトを作成] オプションを選択します。要求しているクローンシナリオに使用する正しいクローンプロファイルであることを確認します。

新しいデータプリザーバー、除外、またはクリーンアップスクリプトを作成しても、クローンプロファイルには自動的に追加されません。保持者、除外、またはクリーンアップスクリプトを追加するには、クローンプロファイルを開き、 他のアクション > 構成 > フォームレイアウトをクリックし、新しいプリザーバーを [選択済み] リストに移動します。

オプションですが、クローンプロファイルを使用することをお勧めします。クローンをスケジュールするときに [クローンプロファイル] フィールドを空のままにすると、システムで構成されたすべての除外テーブル、データプリザーバー、およびクリーンアップスクリプトが使用されます システムクローン > クローン定義.