クローンのヒントとテクニックこの記事では、クローン作成のヒントとコツについて説明します。ATF ジョブの保持、インスタンスの名前変更後の新しいクローンターゲットの作成に関する問題、ユーザー、ロール、グループの除外と保持、含めないテーブル、およびプロファイルの詳細を確認してください。 この記事は、クローンに関する 3 部構成のシリーズの一部です。 クローンの基本 - KB1214608クローンに関する FAQ - KB0715621 .mce-toc { background-color: #f7f7f7; padding: 10px; border-radius: 5px; border: 1px solid #dedede; width: 70%; min-width: 500px; } 目次 ATF ジョブを保持するにはどうすればよいですか？インスタンスの名前を変更したため、新しいクローンターゲットを作成できません。ユーザー、ロール、およびグループを除外して保持するにはどうすればよいですか?除外すべきでないのはどのテーブルですか？プロファイルはどのように機能しますか?システムプロファイルはデフォルトであり、使用する必要がありますか? ATF ジョブを保持するにはどうすればよいですか？ クローン実行中に ATF ジョブを保持する方法について、多くのご要望がありました。ATF はプリザーバーと連携するように設計されておらず、更新セットを介して移動するように設計されているため、ATF を保持することは最適なオプションではありません。 最適なオプションは、更新セットを介して ATF テストを本番環境に移動することです。その後、準本番環境上で本番環境のクローンを作成するときに、ATF テストを使用できます。本番環境で ATF テストをコミットしても、本番環境でテストを実行する必要はありません。クローンの内容を保持する必要がないため、クローン作成が非常に簡単になります。 注:現在準本番環境で ATF ジョブをテストしていて、本番環境にプッシュする準備ができていないがクローンを作成する必要がある場合は、更新セットを介して ATF テストをエクスポートし、ターゲットインスタンスに対してクローンを作成してから、その ATF テストを含む更新セットを再コミットします。 インスタンスの名前を変更したため、新しいクローンターゲットを作成できません。 インスタンスの名前を変更してインスタンスへのログインを試み、インスタンスの新しいクローンターゲットの作成を試みた場合、そのインスタンスは古い名前で既に存在するため、この処理は機能しません。 これを修正するには、KB0550896で詳述されている手順に従います変更後にクローンターゲットを追加できません - KB0550896。 ユーザー、ロール、およびグループを除外して保持するにはどうすればよいですか? 場合によっては、ソースインスタンスからユーザーを引き継がず、ターゲットインスタンスのユーザーのみを保持することがあります。これにはさまざまな理由があり、これを達成する方法はたくさんあります。 方法 1 (推奨):ターゲット内のアクセス権とユーザーを除外せずに保持します。 シンプルなグループとプリザーバーのロジックを使用して、ターゲットインスタンスでアクセスを保持できます。この方法では除外は必要ありません (参照が壊れる可能性があるsys_userやsys_user_roleを除く)。 クローン後も引き続きアクセスできるすべてのユーザーを含むユーザーグループ (「開発者」など) を作成しますクローンソースオーバーターゲットクローン後にアクセス権を必要としないすべてのユーザーアカウントを無効にするクリーンアップスクリプトを作成して、アクセス権を持ち、「開発者」グループに属していないすべてのユーザーをチェックし、見つかった場合は無効にします#1 (sys_user_group、sys_group_has_role、sys_user_grmember) のテーブル専用の保持者を作成しますターゲットインスタンスのロール/グループをさらに保持する必要がある場合は、保持者に追加できます。 クリーンアップスクリプトは、本番環境からコピーされたものの、ターゲットインスタンスにまだレコードがない新しいユーザーを削除します。「開発者」グループにリンクされていないユーザーを検索し、非アクティブに設定します。今後のクローンでは値が false になり、ユーザーの追加/削除を常に処理し続けます。 注:sys_idのユーザーをソースとターゲットの間で一致させるには、ユーザーが異なるかのように機能させる必要があります。一致しない場合は、ターゲットインスタンスで重複が発生します。調整するには、ソースからフル クローンを実行してから、sys_userレコードをクリーンアップすると、この作業が機能します。 方法 2 (推奨):(関連テーブルとインスタンスの機能が破損する可能性があるため、注意して使用してください) データの除外と保持を設定できます。 これはよりトリッキーなソリューションであり、実装すると、テーブルを除外するオプションをオフにしてクローンを作成すると、これは機能せず、このメソッドを使用して将来のクローンが中断されることを意味します。 これを行うには、次の 除外を作成する必要があります。 sys_usersys_user_role**sys_user_has_rolesys_user_groupsys_user_grmembersys_group_has_rolesys_user_role_containscmn_notif_devicecustomer_contact ( カスタマーサービス管理 (CSM) プラグイン がインストールされている場合のみ) これにより、ソースインスタンスからユーザーが引き継がれたり、グループやロールへの参照が引き継がれたりすることはありませんが、ターゲットインスタンスでsys_userを保持する必要があります。多くの人が忘れているのは ロールやグループ、ユーザーからロールやグループへのリンクも保持する必要があるということですこれはよくある間違いで、クローン作成後に admin ロールが欠落してログインできなくなります。これは、ロールへのリンクがないためです。次に、次の 保持者 を作成する必要があります(要件に応じて条件を追加します)。 sys_usersys_user_role**sys_user_groupsys_user_grmembersys_user_has_rolesys_group_has_rolesys_user_role_containscmn_notif_devicecustomer_contact ( カスタマーサービス管理 (CSM) プラグイン がインストールされている場合のみ) これにより、ターゲットインスタンス内のすべてのユーザー、ロール、およびグループが保持されますが、それらのグループおよびロールに対するこれらのユーザーの権限も保持されます。これらをインスタンスに配置すると、クローン作成後のターゲットインスタンスからまったく同じユーザーが存在し、クローン作成元のすべてのアクセス権が保持されます。 **sys_user_roleテーブルは注意して扱ってください。 sys_user_roleテーブルを除外/保持する場合。プラグイン関連のロールは除外/保持できます。プラグインがソースでアクティブステータスであり、ターゲットでアクティブでない場合、プラグインがアクティブステータスになっているターゲットでロールがない可能性があります。プラグインがソースでアクティブではなく、ターゲットでアクティブステータスである場合、sys_user_roleを除外/保持すると、プラグインがアクティブでなくてもターゲットでロールが使用可能になるため、破損した参照が作成されます。sys_user_roleテーブルの名前には一意のインデックスがあるため、ロール名を重複させることはできません。したがって、ソースとターゲットの間でインデックス競合が発生したレコードについては、ターゲットレコードは保持され、ソースは除外されます。(ソースにないターゲットのロールのみを保持することをお勧めします。ソースロールsys_idへのすべての参照が壊れる可能性があるため)例：ロールを保持する場合:TestRoleソース: TestRole - sys_id = 77c8e0a61b88d10739e2f48b04bcbdcターゲット: TestRole - sys_id = 32f4f3t23b42a23425e1f63g12efaseクローン作成後は、ターゲットインスタンスからのロールのみを持ちますが、一意のインデックスでは両方を持つことはできないため、ソースからのロールはありません。 除外すべきでないのはどのテーブルですか？ サポートを通じて提起された問題を確認すると、クローン後に除外され、問題が発生したテーブルが多数あることがわかりました。このテーブルを除外する必要がある場合は、このテーブルも保持するか、そのテーブルからデータの一部を削除してクローンクリーンアップスクリプトを使用することをお勧めします。 除外しないテーブル: sys_properties sys_propertiesは、インスタンスのメタデータと構成を操作するベーステーブルです。除外すると、構成とメタデータが転送されるターゲットインスタンスで関連情報が失われます。保持されている場合、sys_propertiesはターゲットで保持され、関連するメタデータと構成は消去され、ソースデータに置き換えられます。 sys_triggersys_plugins (ターゲットインスタンスがダウンする可能性があります)sys_user (前述のとおりですが、他のテーブルで保持されている場合は問題ありません)ソースからのこれらのテーブルデータはターゲットで除外されるため、sys_* テーブルのカスタム除外は注意して扱う必要があります (アプリケーションがターゲットにインストールされていない場合、E.g. sys_app、sys_store_app、およびsys_scope除外するとモジュールが強制終了される可能性があります) これらを除外すると、ターゲットインスタンスの状態が悪くなる可能性があり、クローンをロールバックして調整し、再度クローンする必要があります。 プロファイルはどのように機能しますか?システムプロファイルはデフォルトであり、使用する必要がありますか? クローンを要求するときにプロファイルを選択できます。選択すると、選択したプロファイル設定がクローン要求に自動入力されます。 ここでは、プロファイルについて詳しく説明します。これらのプロファイルは、異なる環境でクローンを作成する設定が異なっている場合に役立ちます。 クローン要求のクローンプロファイル メモ:ServiceNow では、「システムプロファイル」と呼ばれるプロファイルを 1 つ提供しています。このプロファイルには、OOB で定義された除外テーブルのリスト、データエントリの保存、およびクリーンアップスクリプトのみが含まれます。したがって、これには、デフォルトのクローン用に以前に作成した除外/プリザーバーは含まれません。プロファイルなしでデフォルト設定を引き続き使用する場合は、クローンを要求するときにプロファイルフィールドを空のままにし、システムプロファイルを構成していない限り使用しないでください。 詳細: クローン プロファイル: クローン中にテーブルを除外/保持する動作 - KB0855777