CMDB と Auto-Number フィールドSummary<!-- /*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: ; } } Auto-Number プラットフォーム機能 Record Numbering は、一意の番号とプレフィックスを使用してレコードへ自動的に番号を付与する方法です。これは Task テーブルで最も一般的に見られます。Number フィールドは、Task クラスに固有のプレフィックスと番号で構成される文字列です。たとえば、task テーブルを拡張する incident テーブルや case テーブルの場合は、INT00012324またはCASE0100024です。新しいレコードはシーケンス内の次の番号を取得します。これらは task テーブルで定義された 'number' フィールドを共有します。sys_number テーブルおよび sys_number_counter テーブルは、プレフィックスを定義し、カウント値を追跡します。getNextNumber... メソッドが新規レコードのデフォルト値を設定します。 プラットフォームには、テーブルごとに 1 つの auto-number フィールドという制限があります。これは、テーブルごとに 1 つのプレフィックスしか持てないことも意味します。CMDB のような Extended Table では、ここでいう「Table」は「Class」を意味します。そのため、Extended Table 階層内のテーブル群については、異なるブランチのテーブルで異なるフィールドやプレフィックスを持つことが可能です。 拡張テーブルや子クラスは、子テーブル/クラスで別のプレフィックスが定義されていない限り、親テーブルのフィールドとプレフィックスを継承します。例えば、Business Service [cmdb_ci_service] のプリフィックスは「BSN」ですが、それを拡張する Monitored Service [cmdb_ci_service_auto] のプリフィックスは「SNSVC」です。お客様が高位レベルのクラス（例えば cmdb_ci クラス）にカスタムフィールドを追加した場合、そのフィールドの番号付けとプレフィックスは、その階層ブランチで定義されている OOTB フィールドによって上書きされます。 番号フィールドを作成する場合、"If an auto-numbered field does not already exist.." の場合のみ作成できます。既に存在する場合はエラーポップアップが表示されることがあります。このチェックコードの問題は、将来どのプラグインがインストールされるか、また将来のベースプラットフォーム変更によって番号フィールドが追加または変更されるかを予測できないことです。その結果、後になってカスタムフィールドが無効かつサポート対象外のカスタマイズとなり、何らかの機能を破壊する可能性があります。 CMDB の OOTB フィールド CMDB の場合、Service CI に関する番号フィールドの利用機会は ServiceNow の初期の歴史の段階で既に存在していました。"Service Portfolio Management" プラグインには、Jakarta 時点で Business Service テーブル [cmdb_ci_service] 上の番号フィールドが存在していました。このフィールドは、それ以前に子テーブルである Service Offering [service_offering] テーブル上に存在していたものが移動された可能性がありますが、履歴は明確ではありません。 "Application Portfolio Management" プラグインは、Istanbul で Business Application [cmdb_ci_business_app] 上に APM プレフィックス付きの番号フィールドを追加しました。Orlando では、このフィールドはすべてのインスタンスに存在するコア CMDB プラグインへ移動されました。そのため、すべての顧客は Orlando 以降このフィールドを持っています。 Common Service Data Model (CSDM) は、プラットフォームを使用するすべてのアプリケーション向けに Service CI データを標準化するという重要な目的を持っています。後方互換性のために Business Service 番号フィールドを継承し、そのフィールドを Extended Table 階層内で Business Service [cmdb_ci_service] テーブルへ移動しました。これにより、そのブランチに属するすべての Service CI クラスを対象としています。このフィールドは、一部の箇所では "Service ID" と表示または参照されますが、Dictionary では "Number" です。Paris では、Business Service [cmdb_ci_service] テーブルと Monitored Service [cmdb_ci_service_auto] テーブルに対して異なるプレフィックスが追加されました。また、一般的なプラットフォーム要件ではないにもかかわらず、一意な番号を強制する Business Rule も追加されました。 CMDB 関連テーブルには、メインの CMDB Extended Table に属さないその他の Number フィールドも追加されています。例えば Outage や CMDB Health/Audit Remediation に関連する Task テーブルがあります。 Xanadu バージョン時点（Paris 以降変更なし）の OOTB フィールド、テーブル、およびプレフィックスは次のとおりです。 PrefixTableFieldAPMBusiness Application [cmdb_ci_business_app]cmdb_ci_business_app.numberBSNApplication Service (previously Business Service) [cmdb_ci_service]Plus extending tables:SLA Configuration [em_sla_configuration]Dynamic CI Group (previously Technical Service) [cmdb_ci_service_technical]Service Offering [service_offering]Service Group [cmdb_ci_service_group]cmdb_ci_service.numberSNSVCMonitored Service [cmdb_ci_service_auto]Plus extending tables:Application Service [cmdb_ci_service_discovered]Technical Service [cmdb_ci_query_based_service]Manual Service [cmdb_ci_service_manual]Alert Group [cmdb_ci_alert_group] メインの CMDB CI Extended Table 階層に属さないスタンドアロン CMDB テーブル: CEXCMDB Integration Execution [sn_cmdb_int_util_cmdb_integration_execution]sn_cmdb_int_util_cmdb_integration_execution.numberCISCMDB Integration Execution Import Set [sn_cmdb_int_util_cmdb_integration_execution_import_set]sn_cmdb_int_util_cmdb_integration_execution_import_set.numberOUTOutage [cmdb_ci_outage]cmdb_ci_outage.numberPLCEXECCMDB Data Management Policy Execution [cmdb_data_management_policy_execution]cmdb_data_management_policy_execution.numberTMPRUNDe-Duplication Template Run [reconcile_duplicate_template_run]reconcile_duplicate_template_run.run_idCMDBWSPRGProgress Monitor [sn_cmdb_ws_progress_monitor]sn_cmdb_ws_progress_monitor.number CMDB タスクテーブル: CMDBTASKCMDB Data Management Task [cmdb_data_management_task] DUPRemediate Duplicate Task [reconcile_duplicate_task]task.numberIPAMIP Address Management Task [sn_cmdb_int_util_ip_address_management_task]ORPHOrphan CI Remediation [orphan_ci_remediation]RECDRecommended Field Remediation [recommended_field_remediation]RECOMPCMDB Multisource Recompute Task [cmdb_multisource_recomp_task]REQDRequired Field Remediation [required_field_remediation]STALStale CI Remediation [stale_ci_remediation]TASK*Follow On Task [cert_follow_on_task] *CMDB Audit の結果に対する CMDB Remediation Rule によって作成された Follow On Task [cert_follow_on_task] レコードは、親 task テーブルから "TASK" プレフィックスおよび番号付けを継承します。 現在、Follow On Task 専用のプレフィックスおよび番号付けは存在しません。 そのため、Task [task] テーブルのレコードや独自プレフィックスを持たない他の task 拡張テーブルもカウンターを増加させるため、番号は連番にはなりません。 Related Links<!-- /*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: ; } } これらのフィールドによって発生する可能性のある問題 顧客は、番号フィールドを追加するプラグインのインストールやアップグレードを行う前であれば、その時点では 1 フィールド/テーブル制限に抵触せずにカスタマイズを実施できる場合があります。 その場合、次のような問題が発生する可能性があります。 レコード挿入時にカウントが 2 以上増加するCMDB 階層の一部ブランチで番号シーケンスやプレフィックスが上書きされる OOTB コードはカスタマイズすべきではありません。そのため、OOTB フィールド追加や変更を元に戻そうとしないでください。このようなケースでは、OOTB の仕組みとは独立したカスタム Auto-Number とプレフィックスシステムを実装することが解決策となります。デフォルト値には getNextNumber... メソッドではなく新しいスクリプトを使用します。このスクリプトでは、プレフィックスをハードコードし、追加したフィールド専用に現在のカウントを管理するためのカスタムテーブルレコードを使用する場合があります。 Community の Idea Portal には、2020 年に "Allow more than 1 Auto Number field per table" というアイデアがありましたが、現在は存在しません。同一テーブル上で、それぞれ独自のプレフィックスおよびカウンターを持つ複数の Number フィールドが必要であると考える場合は、同様のアイデアを投稿し、その Idea フォームで賛成票（Up-vote）を投じるとともに、ビジネス要件をコメントとして投稿することを検討してください。 PRB1456249 has been created to track cases where customer already had a number field. サポートケースにはこれに関連付けてください。 KB0966591 The auto-number prefixes added in Paris for Service CIs as part of the CSDM changes cause issues with number fields due to the one field per table limitation CMDB の異なるブランチには auto-number を使用する 'number' フィールドが複数存在します。これらは同じ名前ですが、基盤となる SQL テーブル上では同じ列ではないため混乱を招く場合があります。 Paris 以降、Business Rule "Check Uniqueness for SN App Service ID" と "Check service name uniqueness"が Business Service [cmdb_ci_service] およびその拡張テーブル CI に対して insert/update 時に実行されます。 他の CI が既に同じ Number 値または同じ名前を持っている場合、insert や update は中止され、画面には以下のエラーが表示されます。 Invalid insert. Service with SN App Service ID: BSN0001008 already exists.Invalid update sys_number_counter レコードのカウント値が実際のレコード値と同期していない可能性があります。対象プレフィックスの sys_number_counter レコードを手動編集し、現在の Service CI の番号より 1 大きい値に設定してください。 Business service Big Splash US Central already exists. Please enter a different name.Invalid update これは期待される動作です。Paris 以降、Service 名は一意である必要があります。Service をコピーする場合は、Insert & Stay を実行する前に名前を変更してください。 既に重複した番号を持つレコードが複数存在しますか? このフィールドは Dictionary で Unique に設定されておらず、設定すべきでもありません。そのため、基盤 SQL データベースの観点ではこの状況は許容されます。 考えられる原因: Paris へアップグレードする前からレコードが存在していたBusiness Rule が無効化されている異なるカウンターを使用していた別インスタンスからレコードがインポートされたClone 設定により、ソースインスタンスのレコードがコピーされ、かつターゲットインスタンスの既存レコードも保持されたその他にも原因は考えられますレコード作成日時、アップグレード履歴、および現在のカウンター値を確認してください。 フィルター済みリストで New ボタンをクリックすると、同じフィルターが新規レコードへ自動的に適用されます。 例えば、特定の CI Number でフィルターされた CMDB リストから New をクリックすると、その Number フィールドには既存レコードの値が事前設定されます。これは Dictionary のデフォルト値を上書きします。Auto-number はスクリプト化されたデフォルト値で実装されているため、次に採番される番号も上書きされます。 特定フィールドでこの動作を無効化するには、Dictionary 属性: ignore_filter_on_new=true を追加します。 参照: Filters and breadcrumbs (Rome docs) この Dictionary 属性は、リストフィルターによる次番号の上書きを防ぐために、Quebec で cmdb_ci_service および cmdb_ci_business_app に対して OOTB 変更されました。(PRB1431792)