クローン作成時の TPC テーブルでの除外とデータプリザーバーの操作Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この記事では、拡張可能な TPC テーブルのクローン作成時に孤立レコードが作成されないようにするために、お客様/管理者が実行できる手順について詳しく説明します。まず、TPC テーブルは、データベースに物理的に存在するテーブルです。 概要 提供されている手順を実行する前に、データプリザーバーと除外は、構成データで構成されるテーブルでのみ構成する必要があることに注意してください。これは、「アプリケーションファイル」(sys_metadata) 階層内にある任意のテーブルを意味します。データプリザーバーと除外は構成タイプのデータのみを対象としています。お客様/アドミンの裁量によるこれ以外の構成は、望ましくない結果をもたらす可能性があります。 テーブル図の例: テーブル 拡張可能な>親テーブル テーブル B >テーブル A の子 テーブル C >テーブル A の子 上の図では、ソースインスタンスとターゲットインスタンスの両方に一連のテーブルが存在することがわかります。インスタンス 1 からインスタンス 2 へのクローンがスケジュールされている場合、インスタンス 1 のテーブル A、B、C のすべてのデータによって、インスタンス 2 のテーブル A、B、C のデータが上書きされることが想定されます。 シナリオ 1:インスタンス 2 のテーブル A のすべてのデータを保持する必要がある このタスクを実行するには、データプリザーバー/除外を使用する必要がありますが、最初に除外とデータプリザーバーの仕組みを確認する必要があります。 データプリザーバー :構成データにのみ使用され、後で再適用するテーブル上のすべてのデータの XML コピーを取得するプロセスが含まれます。 除外構成データにのみ使用し、ソースからターゲットにテーブルのスキーマをコピーしますが、テーブルからデータをコピーしません。 これを実現するためにほとんどのユーザー/アドミンが実装する一般的な構成は、インスタンス 1 のテーブル A にデータプリザーバーを作成することですが、これを行う前に、テーブル A、B、および C のデータ/テーブル構造を理解することが重要です。 テーブルの構造を見ると、テーブル B と C は A の子テーブルであるため、テーブル B またはテーブル C に存在するレコードもテーブル A にエントリがあります。別の見方をすると、テーブル B と C は実際にはメインの親テーブルであるテーブル A のクラスであるということです。 データプリザーバーがテーブル A に対してのみ作成されている場合、実際に保持されるレコードはクラス「IS A」のレコードのみです (A12345)。レコード B23456、B23457、および C56789 のエントリはありますが、これらのレコードはインスタンス 1 のテーブル A のソースインスタンスからのものです。簡単に言うと、テーブル A にデータプリザーバーが構成されている場合、ユーザー/管理者は、テーブル A にもテーブル B とテーブル C のすべてのレコードが含まれていることに注意する必要があります。したがって、テーブル A 階層内のすべてのテーブルに対してもプリザーバーを作成する必要があります (テーブル B とテーブル C にはプリザーバーが必要です)。 上記の例では、sys_id観点から見たデータがインスタンス 1 とインスタンス 2 のレコード B23456 で同じであるが、インスタンス 2 に存在するレコードに追加の変更 (データ追加) があったと仮定します。クローンが実行されると、ターゲットインスタンスのレコードは保持することが想定されますが、同じレコードがソースに存在する場合は、データプリザーバーが構成されていても、ターゲット内のデータが上書きされます。ターゲットレコードが確実に保持されるようにするには、テーブル A 階層 (A-C) 内のすべてのテーブルに対してデータプリザーバーと除外を作成する必要があります。これにより、ターゲットのデータが保持され、除外によりソースからターゲットにデータがコピーされなくなります。 孤立データ/ゴーストレコード 上記のロジックを使用すると、テーブル拡張を持つ TPC テーブルのデータプリザーバー/除外を不適切に構成すると、正しい構成が行われていない場合、孤立したデータ/ゴーストレコードが簡単に発生する可能性があります。 例: For for the purpose of our example we will going to having the records in Instance 1 and Instance 2 have different sys_ids because is really kind when there there are orphaned records after a clone.(例のために、インスタンス 1 とインスタンス 2 のレコードは、クローン後に孤立したレコードがある場合に実際に起こることなので、が異なると仮定します。 テーブル A のデータプリザーバーと除外をユーザーが作成しました (sys_idsが異なる場合) 結果:ソースインスタンスのレコードのsys_idsがターゲットと同じではないため、テーブル B と C のすべてのレコードが孤立 (子レコードが孤立) レコードになります。これが本当にであることを確認するには、ユーザー/アドミンはテーブル A リストビューでテーブル B と C のレコードを開いて、「レコードが見つかりません」ことを示すメッセージを見つけようとします。また、テーブル B とテーブル C のレコードのsys_idが異なるため、テーブル A のこれらのレコードの親レコードが存在しないため、テーブル B と C のレコードも孤立します。 ターゲットインスタンスでデータを保持しようとしたときにデータが孤立しないようにするには、ユーザー/アドミニストレーターはデータプリザーバーを作成し、テーブル階層内のすべてのテーブルから除外する必要があります。損傷が発生した場合は、問題を解決するための 2 つのオプションがあります。 再度クローンを作成し、正しいデータプリザーバーとデータ除外が適切に構成されていることを確認しますこの代替案は、上記の例のコンテキストにあります。クラスフィールドを使用して、システムをだます簡単なスクリプトを実際に記述し、レコードをAのクラスとして再分類できます。画像に孤立したデータがなくなったため、これが完了すると、ユーザー/アドミニストレーターはレコードを削除できます。データが別のインスタンスに存在する場合は、データをターゲットインスタンスにインポートできます。 スクリプト例： //This script will only work for records which are orphaned at the parent level where the child record did not carry over. If this is a reverse orphan situation where the child exist but the parent is not available please contact support as these would need to be handled from the database. The easier option is to clone again with the correct configuration. findOrphans('A'); function findOrphans(table) { var gr = new GlideRecord(table); gr.query(); while(gr.next()) { if(isOrphan(gr)) { gs.info("Updating orphan from " + table + ": " + gr.sys_id); gr.sys_class_name = table; gr.setWorkflow(false); gr.autoSysFields(false); gr.update(); } } } function isOrphan(gr) { if(gr.sys_class_name == null) return false; var childClass = new GlideRecord(gr.sys_class_name); childClass.get(gr.sys_id); return !childClass.isValidRecord(); } (The code provided here should always be tested before executing on any instance. The provide code is in the context of the example provided as there may not be a class field available to users/admin) //This code essentially changes the class of the records in Table B and C in the example above which now no longer makes them orphaned. Once this is done the record can then be deleted and the user/admin can import the data from another instance. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } }