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

データプリザーバー

クローン作成対象のインスタンスでデータを保持する必要がある場合があります。たとえば、ターゲットが MID Server の場合、MID Server [ecc_agent] テーブルを上書きしてはなりません。保持されたデータは、クローン作成が開始される前はターゲットインスタンスに保存され、クローン作成後にターゲットインスタンスに復元されます。
警告: ソースインスタンスでデータプリザーバーを定義する必要があります。ターゲットインスタンスで定義しても、データは保持されません。
データプリザーバーは通常、次のようなシステム設定とテーマを保持します。
  • インスタンス固有の認証設定
  • ブックマーク [sys_ui_bookmark]
  • 最近の選択 [sys_ui_recent_selection]
  • ユーザー初期設定 [sys_user_preference]
注: クローンは、データベースビューからのデータの保持をサポートしていません。

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

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

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

SAML のデータプリザーバー

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

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

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

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

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

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

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

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

始める前に

必要なロール：clone_admin または admin

このタスクについて

ターゲットインスタンスの特定のデータを保持することが望ましい場合があります。たとえば、MID Server を使用している場合は、MID Server [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. [新規] をクリックします。
  3. テーブルラベルを [名前] として入力します。たとえば、[sys_user_preference] テーブルの場合は「ユーザー初期設定」です。
    データプリザーバーにはテーブル名が必要です。指定しないと送信できません。
  4. 保持する [テーブル] を選択します。
    データプリザーバーではテーブルを選択する必要があります。指定しないと送信できません。
  5. 保持されるデータが UI プロパティの場合は、[テーマ] チェックボックスをオンにします。
  6. 保持するデータを定義するには、Condition Builder を使用します。
    条件を使用して、クローン中に保持する特定のレコードを定義できます。たとえば、特定のシステムプロパティのみを保持する場合は、保持するプロパティ名ごとに条件を追加できます。
    注: 正規表現に一致する条件 [match regex] はサポートされなくなりました。
    条件付きデータプリザーバー
    警告: バックアップからのクローンが何らかの理由で失敗した場合、クローンプロセスは従来のクローンエンジンにフェイルオーバーします。従来のクローンエンジンは、拡張テーブル、関係、テーブル間の階層、およびドット連結クエリからのデータを保持できません。このような場合は、システムクローンを再スケジュールするか、手動でデータを転送する必要があります。
  7. [送信] をクリックします。
    後でデータプリザーバーを削除する場合は、次のデータプリザーバーレコードを変更または削除しないようにしてください。
    • コアインスタンスのプロパティ
    • セマフォ
    • Email Accounts
    注: 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]
    SAML システムプロパティの保持
    注: インスタンステーマを保持するかどうかに関係なく、これらのプロパティが保持されるように、[テーマ] チェックボックスがオフになっていることを確認します。
  4. [更新] をクリックします。

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

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

始める前に

アプリケーションレコードに対する書き込みアクセス権があることを確認します。

ソースコントロールリポジトリへのアクセス権があることを確認します。

必要なロール：admin

このタスクについて

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

手順

  1. 次のいずれかのアクションを行い、クローンターゲットインスタンスでアプリケーションを保持します。
    表 : 1. インスタンス間のバージョンの差異
    アプリケーションバージョンの状態 実行するアクション
    クローンターゲットインスタンスのアプリケーションバージョンが、ソースインスタンスバージョンと異なります。 クローンターゲットインスタンスから各アプリケーションをエクスポートします。次の選択肢があります。
    • 各アプリケーションをソースコントロールリポジトリにリンクします。
      注: アプリケーションが既にソースコントロールリポジトリにリンクされている場合は、最新のバージョンをコミットします。
    • 各アプリケーションを更新セットに公開します。
    アプリケーションは、クローンターゲットインスタンスでのみ利用できます。
    クローンターゲットインスタンスのアプリケーションバージョンは、ソースインスタンスと同じです。 なし。システムクローン作成プロセスにより、クローン作成中にこのアプリケーションバージョンがターゲットインスタンスにコピーされます。
  2. ターゲットインスタンスに対するソースインスタンスのシステムクローンを要求します。
    たとえば、開発インスタンスに対して本番インスタンスのクローンを作成します。
  3. クローン作成プロセスが終了したら、クローンターゲットインスタンスにログインします。
  4. 各アプリケーションをソースコントロールリポジトリに保存した場合は、次のいずれかのアクションを使用してソースコントロールリポジトリからアプリケーションを取得します。
    表 : 2. ソースコントロールリポジトリからのアプリケーションの取得
    アプリケーションのインストール状態 クローンターゲットで実行するアクション
    アプリケーションは以前にソースインスタンスにインストールされていました。 ソースコントロールリポジトリからリモート変更を適用します。
    アプリケーションはソースインスタンスにインストールされていませんでした。 ソースコントロールリポジトリからアプリケーションをインポートします。
  5. 注: アプリケーションのカスタマイズのクローンの後に起こることについては、「アプリケーションのカスタマイズのクローン後の結果」を参照してください。
    アプリケーションのカスタマイズ内容については、以下のいずれかのアクションを使用してソースコントロールリポジトリから取得します。
    表 : 3. ソースコントロールリポジトリからのアプリケーションの取得
    アプリケーションとカスタマイズのインストール状態 クローンターゲットで実行するアクション
    アプリケーションとカスタマイズ内容は以前にソースインスタンスにインストールされていました。 ソースコントロールリポジトリからリモート変更を適用します。
    アプリケーションは以前にソースインスタンスにインストールされていましたが、カスタマイズ内容はインストールされていませんでした。 ソースコントロールリポジトリからリモート変更を適用します。
    ベースアプリケーションはソースインスタンスにインストールされていませんでした。 リポジトリ構成 (sys_repo_config) を削除し、ソースコントロールリポジトリからカスタマイズをインポートします。
  6. 各アプリケーションを更新セットに保存した場合は、次のいずれかのアクションを行って更新セットからアプリケーションを取得します。
    表 : 4. 更新セットからのアプリケーションの取得
    アプリケーションのインストール状態 クローンターゲットで実行するアクション
    アプリケーションは以前にソースインスタンスにインストールされていました。
    1. ソースインスタンスからクローンされたアプリケーションバージョンを削除します。
    2. 現在のアプリケーションバージョンを含む更新セットをロードします。
    アプリケーションはソースインスタンスにインストールされていませんでした。 現在のアプリケーションバージョンを含む更新セットをロードします。
  7. クローン後に、次のリモート変更を適用できます。
    表 : 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) です。

タスクの結果

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

例: 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 が追加されました。