クローンのヒントとテクニック<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } .mce-toc { background-color: #f7f7f7; padding: 10px; border-radius: 5px; border: 1px solid #dedede; width: 70%; min-width: 500px; } この記事では、クローン作成のヒントとコツについて説明します。ATF ジョブの保持、インスタンスの名前変更後の新しいクローンターゲットの作成に関する問題、ユーザー、ロール、グループの除外と保持、含めないテーブル、およびプロファイルの詳細を確認してください。 この記事は、クローンに関する 3 部構成のシリーズの一部です。 クローンの基本 - KB1214608クローンに関する FAQ - KB0715621 目次 ATF ジョブを保持するにはどうすればよいですか？インスタンスの名前を変更したため、新しいクローンターゲットを作成できません。ユーザー、ロール、およびグループを除外して保持するにはどうすればよいですか?除外すべきでないのはどのテーブルですか？プロファイルはどのように機能しますか?システムプロファイルはデフォルトであり、使用する必要がありますか? ATF ジョブを保持するにはどうすればよいですか？ クローン実行中に ATF ジョブを保持する方法について、多くのご要望がありました。ATF はプリザーバーと連携するように設計されておらず、更新セットを介して移動するように設計されているため、ATF を保持することは最適なオプションではありません。 最適なオプションは、更新セットを介して ATF テストを本番環境に移動することです。その後、準本番環境上で本番環境のクローンを作成するときに、ATF テストを使用できます。本番環境で ATF テストをコミットしても、本番環境でテストを実行する必要はありません。クローンの内容を保持する必要がないため、クローン作成が非常に簡単になります。 注:現在準本番環境で ATF ジョブをテストしていて、本番環境にプッシュする準備ができていないがクローンを作成する必要がある場合は、更新セットを介して ATF テストをエクスポートし、ターゲットインスタンスに対してクローンを作成してから、その ATF テストを含む更新セットを再コミットします。 インスタンスの名前を変更したため、新しいクローンターゲットを作成できません。 インスタンスの名前を変更してインスタンスへのログインを試み、インスタンスの新しいクローンターゲットの作成を試みた場合、そのインスタンスは古い名前で既に存在するため、この処理は機能しません。 これを修正するには、KB0550896で詳述されている手順に従います。「変更後にクローンターゲットを追加できません」 - KB0550896 ユーザー、ロール、およびグループを除外して保持するにはどうすればよいですか? 場合によっては、ソースインスタンスからユーザーを引き継がず、ターゲットインスタンスのユーザーのみを保持することがあります。これにはさまざまな理由があり、これを達成する方法はたくさんあります。 推奨される方法:ターゲット内のアクセス権とユーザーを除外せずに保持します。 シンプルなグループとプリザーバーのロジックを使用して、ターゲットインスタンスでアクセスを保持できます。この方法では除外は必要ありません (参照が壊れる可能性があるsys_userやsys_user_roleを除く)。 クローン後も引き続きアクセスできるすべてのユーザーを含むユーザーグループ (「開発者」など) を作成します。ソースからターゲットへクローンします。クローン後にアクセス権を必要としないすべてのユーザーアカウントを無効にします。クリーンアップスクリプトを作成して、アクセス権を持ち、「開発者」グループに属していないすべてのユーザーをチェックし、見つかった場合は無効にします。要求に応じて、#1 のテーブル専用のプレザーバーを作成します。 (sys_user_group, sys_group_has_role, sys_user_grmember, sys_user_role, sys_user_has_role)ターゲットインスタンスのロール/グループをさらに保持する必要がある場合は、保持者に追加できます。 クリーンアップスクリプトは、本番環境からコピーされたものの、ターゲットインスタンスにまだレコードがない新しいユーザーを削除します。「開発者」グループにリンクされていないユーザーを検索し、非アクティブに設定します。今後のクローンでは値が false になり、ユーザーの追加/削除を常に処理し続けます。 注:sys_idのユーザーをソースとターゲットの間で一致させるには、ユーザーが異なるかのように機能させる必要があります。一致しない場合は、ターゲットインスタンスで重複が発生します。調整方法:ソースからフルクローンを実行し、sys_userレコードをクリーンアップすると、この作業がうまくいきます。 従来の方法 :(引き続き使用できますが、関連するテーブルとインスタンスの機能が破損する可能性があります。注意が必要です) データの除外と保持を設定できます。 これはよりトリッキーなソリューションであり、実装すると、テーブルを除外するオプションをオフにしてクローンを作成すると、これは機能せず、このメソッドを使用して将来のクローンが中断されることを意味します。 これを行うには、次の 除外を作成する必要があります。 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除外するとモジュールが強制終了される可能性があります)sys_user_preference テーブルには、インターフェイスのレンダリング方法を指示する「system=true」UI 表示プロパティが格納されます。このテーブルは、フィルターなしで全体が保存される場合 のみ 除外できます。 これらを除外すると、ターゲットインスタンスの状態が悪くなる可能性があり、クローンをロールバックして調整し、再度クローンする必要があります。 プロファイルはどのように機能しますか?システムプロファイルはデフォルトであり、使用する必要がありますか? クローンプロファイルは再利用可能なクローンテンプレートです。異なる環境で異なるクローン結果を得たい場合に役立ちます。様々なクローンシナリオに合わせて、必要な数のクローンプロファイルを作成できます（例：アップグレードテスト用プロファイルとカスタムアプリテスト用プロファイル）。 クローンを要求するときにプロファイルを選択できます。選択すると、選択したプロファイル設定がクローン要求に自動入力されます。 プロフィールに関する詳細情報は次のとおりです。 クローン管理コンソールのクローンリクエストフォームで、クローンプロファイルフィールドが空のまま、または「なし」が選択されている場合、利用可能なすべてのプリザーバ／除外、およびクリーンアップスクリプトがシステムによって取得されます。既存のカスタムプロファイルは簡単に複製できます（クローン管理コンソールで任意のプロファイルを開き、「複製」ボタンをクリックします）。システムプロファイルはOOTBであり、変更できません。新しいクローンプロファイルを作成すると、作成された既存のプリザーバ／除外、およびクリーンアップスクリプトがすべて含まれます。 システムプロファイルに関する注意：ServiceNowは、「システムプロファイル」というプロファイルを1つ提供しています。このプロファイルには、除外テーブル、保存データエントリ、およびクリーンアップスクリプトのOOB定義リストのみが含まれます。ユーザーが作成した除外／保存は含まれません。クローンにカスタムのプリザーバ／除外、およびクリーンアップスクリプトを含めたくない場合にのみ、システムプロファイルを選択してください。