Zurich: sys_record_hierarchy テーブルの使用法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: ; } } レコード階層 (sys_record_hierarchy) テーブルにおいて、Yokohama には存在しなかった 4 件のアクティブレコードが Zurich インスタンスに存在していると報告される場合があります。 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: ; } } Zurich Cause<!-- /*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: ; } } レコード階層テーブルにおける差異は、Zurich へのアップグレード時に作成された OOB レコードによるものです。これは、プラグイン com.glide.hierrarchical_record_support が Zurich では利用可能である一方、Yokohama ではパフォーマンスの問題 (PRB1840224) により無効化されていたためです。 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: ; } } 解決策 ServiceNow の sys_record_hierarchy テーブルは、Zurich リリースで導入されたシステムテーブルであり、単一テーブル内のレコードに対する階層関係を明示的に定義および管理するために使用されます。これは複数レベルの階層を正式に定義するのに役立ち、無制限の深さを持つ関連レコードをより容易に管理および照会できるようにします。機能:=========この機能は、「自己参照型」のテーブル向けに設計されています。これは、同じテーブル内のレコードを参照するフィールドを持つことを意味します。例として、cmn_location (ロケーション) テーブルや sys_user (ユーザー) テーブルがあります。これらでは、ロケーションが親ロケーションを持つことができ、またはユーザーが同じくユーザーであるマネージャーを持つことができます。sys_record_hierarchy テーブルでレコード階層が作成されると:対象の自己参照型テーブル上に新しい Hierarchy Path フィールドが自動的に作成されます。このフィールドは階層内におけるレコードの完全なパスを保存します。このパスは、プラットフォームによって階層クエリおよびネイティブ UI コンポーネントを実現するために使用されます。これは、あるテーブルが別のテーブルを拡張する標準的なテーブル拡張階層とは異なります。sys_record_hierarchy テーブルは、単一テーブル内のレコードレベルの親子構造を管理するために特化されています。実用上の利点:=============クエリパフォーマンスの向上: Hierarchy Path フィールド内の事前計算されたパスにより、階層全体を非常に効率的に照会できます。ネイティブ IN_HIERARCHY 演算子: 開発者は、UI クエリおよび GlideRecord クエリの両方で IN_HIERARCHY 演算子を使用して、特定の親またはその子孫に属するすべてのレコードを容易に検索できるようになりました。定義の一元化: これにより、以前は実装が困難であった階層関係を定義および管理するための標準的でサポートされた方法が提供されます。例: ユーザー階層==================説明のために、sys_user テーブルを考えてみます。ユーザーはマネージャーを持つことができ、そのマネージャーも sys_user テーブル内のレコードです。sys_record_hierarchy テーブルが登場する以前は、特定のマネージャー配下のすべての従業員を照会するには、階層を再帰的にたどるカスタムスクリプトが必要でした。sys_user テーブル用に sys_record_hierarchy が構成されると:hierarchy_path フィールドが自動的に維持されます。例えば、top_manager_sys_id/middle_manager_sys_id/employee_sys_id のようになります。manager IN_HIERARCHY top_manager_sys_id のような単一のクエリにより、複雑なスクリプトを記述することなく、すべての配下ユーザーを効率的に取得できるようになります。詳細なユースケースについては、以下の製品ドキュメントを確認してください。https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/table-administration/concept/data-hierarchies.htmlhttps://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/table-administration/task/create-record-hierarchy.html