CMDB フィールドと自動番号フィールドSummary<!-- /*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: block; max-width: ; width: auto; height: auto; } } 自動番号プラットフォーム機能 レコードの番号付け は、一意の番号とプリフィックスを持つレコードに自動的に番号を付ける方法です。これは、タスクテーブルで最も一般的に見られます。タスクテーブルでは、[番号] フィールドがタスククラスに固有のプレフィックスと番号で構成される文字列です。タスクテーブルを拡張するインシデントテーブルまたはケーステーブルの場合は、INT00012324 または CASE0100024 などです。新しいレコードには、シーケンス内の次の番号が付けられます。これらは、タスクテーブルで定義された「番号」フィールドを共有します。sys_number テーブルとsys_number_counterテーブルでプリフィックスを定義し、カウントを追跡します。getNextNumber... メソッドは、新しいレコードのデフォルト値を入力します。 プラットフォームには テーブルごとに 1 つの自動番号フィールドの制限があり、これはテーブルごとに 1 つのプリフィックスを意味します。CMDB のような拡張テーブルの場合、「テーブル」は「クラス」を意味するため、 拡張テーブル階層内の一連のテーブルでは 異なる分岐のテーブルに異なるフィールド/プリフィックスを持つことができます。 拡張クラス/子クラスは、子テーブル/クラスで定義された別のプレフィックスによって上書きされない限り、親テーブルからフィールドとプレフィックスを継承します。たとえば、ビジネスサービス [cmdb_ci_service] のプリフィックスは「BSN」ですが、それを拡張する監視対象サービス [cmdb_ci_service_auto] のプリフィックスは「SNSVC」です。顧客が上位レベル (おそらくcmdb_ciクラス) でカスタムフィールドを追加した場合、そのフィールドの番号付けとプリフィックスは、それらが定義されている階層の分岐のすぐに利用可能なフィールドによって上書きされます。 番号フィールドを作成するときは、「 「自動付番フィールドがまだ存在しない場合..「、するとエラーポップアップが表示されることがあります。このチェックコードの問題は、将来どのプラグインがインストールされるかを予測できないこと、またはベースプラットフォームの将来の変更によって数値フィールドが追加または変更される可能性があることです。そうしないと、カスタムフィールドが無効でサポートできないカスタマイズになり、何かが壊れる可能性があります。 CMDB のすぐに利用可能なフィールド CMDB の場合、サービス CI に関連する番号フィールドの機会は、ServiceNow の歴史の早い段階で初めて利用されました。「サービスポートフォリオ管理」プラグインには、履歴は不明ですが、確かに Jakarta のビジネスサービステーブル [cmdb_ci_service] に番号フィールドがありました。これは、子サービスオファリング [service_offering] テーブルの以前のフィールドからそこに移動された可能性があります。 「アプリケーションポートフォリオ管理」プラグインは、イスタンブールではビジネスアプリケーション [cmdb_ci_business_app] にプリフィックス APM の数値フィールドを追加し、Orland ではすべてのインスタンスに存在するコア CMDB プラグインに移動されました。そのため、Orlando 以降、すべての顧客がこのフィールドを使用できます。 (CSDM) はプラットフォームを使用するすべてのアプリのサービス CI のデータを標準化するという重要な目的を持ち、下位互換性のためにビジネスサービス番号フィールドを継承し、拡張テーブル階層/ツリーのフィールドをビジネスサービス [cmdb_ci_service] テーブルに移行して、その分岐のすべてのサービス CI クラスをカバーしています。これは、辞書では「番号」ですが、一部の場所では「サービス ID」とラベル付け/参照されています。Paris では、ビジネスサービス [cmdb_ci_service] テーブルと監視対象サービス [cmdb_ci_service_auto] テーブルで、このフィールドに対して異なるプリフィックスが追加されました。一意の番号付けを強制するビジネスルールが追加されましたが、これは一般的なプラットフォーム要件ではありません。 その他の数値フィールドは、CMDB ヘルス/監査の修正に関連する機能停止やタスクなど、メインの CMDB 拡張テーブルの一部でもない CMDB 関連テーブルに追加されています。 Xanadu バージョンでは、Paris 以降変更されていませんが、CMDB のすぐに使用できるフィールド、テーブル、プリフィックスは次のとおりです。 敬称テーブルフィールドAPMビジネスアプリケーション [cmdb_ci_business_app]cmdb_ci_business_app.numberBSNのアプリケーションサービス (以前のビジネスサービス) [cmdb_ci_service]さらに拡張テーブル:SLA 構成 [em_sla_configuration]ダイナミック CI グループ (以前のテクニカルサービス) [cmdb_ci_service_technical]サービスオファリング [service_offering]サービスグループ [cmdb_ci_service_group]cmdb_ci_service.numberSNSVC監視対象サービス [cmdb_ci_service_auto]さらに拡張テーブル:アプリケーションサービス [cmdb_ci_service_discovered]テクニカルサービス [cmdb_ci_query_based_service]手動サービス [cmdb_ci_service_manual]アラートグループ [cmdb_ci_alert_group] メインの CMDB CI 拡張テーブル階層の一部ではないスタンドアロン CMDB テーブル: CEXCMDB 統合実行 [sn_cmdb_int_util_cmdb_integration_execution]sn_cmdb_int_util_cmdb_integration_execution.numberCISCMDB 統合実行インポートセット [sn_cmdb_int_util_cmdb_integration_execution_import_set]sn_cmdb_int_util_cmdb_integration_execution_import_set.numberOUT機能停止 [cmdb_ci_outage]cmdb_ci_outage.numberPLCEXECCMDB データ管理ポリシーの実行 [cmdb_data_management_policy_execution]cmdb_data_management_policy_execution.numberTMPRUN(ティムプルン)重複排除テンプレートの実行 [reconcile_duplicate_template_run]reconcile_duplicate_template_run.run_idCMDBWSPRG進捗状況モニター [sn_cmdb_ws_progress_monitor]sn_cmdb_ws_progress_monitor.number CMDB タスクテーブル: CMDBTASKCMDB データ管理タスク [cmdb_data_management_task] 重複重複タスクの修正 [reconcile_duplicate_task]task.numberIPAMIP アドレス管理タスク [sn_cmdb_int_util_ip_address_management_task]オルフ孤立 CI の修復 [orphan_ci_remediation]レコード推奨フィールドの修正 [recommended_field_remediation]RECOMPCMDB マルチソース再計算タスク [cmdb_multisource_recomp_task]REQD必須フィールドの修正 [required_field_remediation]STAL古い CI の修復 [stale_ci_remediation]タスク*後続タスク [cert_follow_on_task] *後続タスク [cert_follow_on_task] によって作成されたレコード CMDB 監査結果の修復ルールは、親タスクテーブルから「TASK」プリフィックスと番号付けを継承します。現在、後続タスクには特定のプリフィックスと番号付けがないため、タスク [task] テーブルレコードや、独自のプリフィックスのない他のタスク拡張テーブルによってカウントが増加するため、番号付けは連番になりません。 Related Links<!-- /*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: block; max-width: ; width: auto; height: auto; } } これらのフィールドによって引き起こされる潜在的な問題: 顧客は、プラグインをインストールする前数値フィールドを追加するバージョンにアップグレードする前に、テーブルあたり 1 フィールドの制限に達することなくカスタマイズを行うことができます。これにより、新しいレコードが挿入されるたびにカウントが 1 ずつ増加したり、CMDB 階層の一部のブランチで番号の順序やプリフィックスが上書きされたりするなどの問題が発生します。OOTB コードはカスタマイズしないでください。OOTB フィールドの追加や変更を元に戻さないでください。このような場合の解決策は、OOTBシステムとは無関係に、同様のカスタム自動番号付けおよびプレフィックスシステムを実装することです。デフォルト値には、getNextNumber の代わりに新しいスクリプトが使用されます... 方式。このスクリプトでは、プリフィックスをハードコードし、追加フィールドに固有の現在のカウントを追跡するためのカスタムテーブルレコードを使用する場合があります。コミュニティ アイデアポータル は、2020年に「テーブルごとに1つ以上の自動番号フィールドを許可する」というアイデアを持っていましたが、それはもうありません。同じテーブルに複数の数値フィールドがあり、それぞれに独自のプレフィックスとカウンターがある場合は、同様のものを追加して賛成票を投じ、そのアイデアフォームにビジネス要件を含むコメントを残すことを検討してください。 PRB1456249 は、顧客に既に数値フィールドがあるケースを追跡するために作成されました。サポートケースをリンクしてください。KB0966591 CSDM の変更の一環として Paris でサービス CI に追加された自動番号プリフィックスでは、テーブルごとに 1 つのフィールドという制限により、番号フィールドに問題が発生します自動付番を使用する CMDB の異なる分岐に「number」という名前のフィールドがいくつかあり、同じ名前であっても基礎となる SQL テーブル内の同じ列ではないため、混乱を招く可能性があります。Paris 以降、ビジネスルール「SN アプリサービス ID の一意性をチェック (Check Unique ness for SN App Service ID)」および「サービス名の一意性をチェック (Check service name uniqueness)」が、ビジネスサービス [cmdb_ci_service] および拡張テーブル CI の挿入/更新時に実行されます。これにより、番号値を持つ別の CI が既に存在する場合、または同じ名前である場合に、挿入または更新が中止される可能性があります。次のエラーが画面に表示されます。 無効な挿入です。SN アプリサービス ID のサービス:BSN0001008既に存在します。 無効な更新 Invalid insert. Service with SN App Service ID: BSN0001008 already exists. Invalid update sys_number_counterレコードのカウントが、既にレコードにある値と同期していない可能性があります。プリフィックスのsys_number_counterレコードを手動で編集して、サービス CI の現在の数フィールドにあるプリフィックスよりも 1 多くします。 ビジネスサービス Big Splash US Central は既に存在します。別の名前を入力してください。無効な更新 Business service Big Splash US Central already exists. Please enter a different name. Invalid update これは正常な動作です。Paris の一意のサービス名が必要です。サービスをコピーする場合は、[Insert & Stay] を選択する前に名前を変更します。 番号が重複しているレコードが既に複数ありますか?このフィールドは辞書で Unique に設定されておらず、設定されるべきではないため、この状況は基になる SQL データベースの観点から許可されます多くの原因が考えられます。 Paris にアップグレードする前 (ビジネスルールが追加されたとき) は、レコードがすでに存在していましたか? ビジネスルールが無効になっていますか? レコードは別のインスタンスからインポートされ、そのインスタンスは別のカウンターにレコードを独自に作成しましたか? クローン設定は、レコードがソースインスタンスからコピーされ、ターゲットインスタンスの既存のレコードも保持されたことを意味しますか? ...そして、もっと多くの潜在的な原因があると確信しています。レコードの作成時刻をアップグレード履歴と現在のカウンターと照合します。 フィルター済みリストの [新規] ボタンをクリックすると、同じフィルターが新しいレコードに自動的に適用されます。たとえば、特定の CI 番号がフィルタリングされている CMDB リストで [新規] をクリックすると、リストが一致していた既存のレコードに番号が設定されたレコードプリセットが開きます。これにより、辞書に設定されたフィールドのデフォルト値が上書きされます。この機能を使用するには、この条件に当てはまる必要がありますが、スクリプト化されたデフォルト値を使用してフォームに入力される次の番号 (自動番号の実装方法) も上書きされます。 フィルターのブレッドクラム機能が特定のフィールドに適用されないようにこの動作を変更するには、辞書属性 ignore_filter_on_new=true を追加します参照: フィルターとブレッドクラム (Rome ドキュメント)この辞書属性は、リストフィルターによって次の番号 (PRB1431792) が上書きされないように、Quebec のメインサービステーブル cmdb_ci_service と cmdb_ci_business_app の OOTB が変更されました。