非 CMDB テーブルの調整ルールの作成
非 CMDB テーブルの静的または動的 CI 調整ルールを作成します。
静的調整ルール、動的調整ルール、および調整ルールに関連するその他のプリンシパルの詳細については、「調整ルール」を参照してください。
同じレコード属性に静的調整ルールと動的調整ルールの両方が存在する場合、動的ルールが優先されます。
非 CMDB テーブルの静的調整ルールの作成
静的調整ルールは、データソースに更新する権限があるクラス属性を指定し、権限のないデータソースが属性の値を上書きするのを防止します。静的調整ルールでは、複数のデータソース間の優先順位付けも指定します。静的調整ルールがない場合、データソースは互いの属性値の更新を上書きできます。
始める前に
このタスクについて
静的調整ルールは、データ更新ルールと組み合わせて使用され、レコードの調整ステップを決定します。これらのルールは、レコードを更新できるかどうか、いつ、どのデータソースが更新するかを決定します。複数のデータソースが同じ属性の更新を許可されている場合、これらのデータソースそれぞれに対して優先度をアサインし、互いの更新が上書きされるのを防ぎます。
- 優先度の低いソースがレコードを更新する最初のソースである。
- クラスのデータ更新ルールに基づいて、レコードが古くなった。
- 特定の属性用に構成されたルールは、(優先度値に関係なく) [すべての属性に適用] で設定されたルールよりも優先されます。
- 同じ属性の 2 つのルール間、または [すべての属性に適用] で設定された 2 つのルール間では、クラスに直接指定されたルールが派生ルールよりも優先されます。
- 同じ属性の 2 つのルール間、または [すべての属性に適用] で設定された同じクラスレベルの 2 つのルール間では、優先度はルールの優先度によって決定されます。
各属性を更新する最後のディスカバリーソースに関する情報は、データソース履歴 [cmdb_datasource_last_update] テーブルに格納されますが、それは調整ルールを有効にした後です。そのため、ルールを有効にした後、最も優先度の高いデータソースが CI を更新するまで、予期しない更新が発生する可能性があります。
静的調整ルールは、古い属性の調整に影響します。調整中に、データソース履歴テーブルの情報が CI のクラスのデータ更新ルールとともに考慮され、CI 属性が古くなっているかどうかが判断されます。ある期間内に CI を更新するために最新のディスカバリーソースによって更新されなかった場合、CI 属性は古くなっていると判断されます。この期間は、ディスカバリーソースのクラスのデータ更新ルールの有効期間によって指定されます。この場合、優先度の低い別の許可されたディスカバリーソースが古い CI 属性を更新しようとすると、更新が許可されます。
同じレコード属性に静的調整ルールと動的調整ルールの両方が存在する場合、動的ルールが優先されます。
手順
非 CMDB テーブルの動的調整ルールの作成
非 CMDB テーブルの動的調整ルールは、CMDB 360 データを使用して、報告される最大値などの値を選択し、レコードを更新します。
始める前に
必要なロール:sn_cmdb_editor と itil には読み取りアクセス権があり、sn_cmdb_admin と itil_admin (一番上) にはフルアクセス権があります
このタスクについて
同じ CI 属性に静的調整ルールと動的調整ルールの両方が存在する場合、動的調整ルールが優先されます。
動的調整ルールは、報告された最大値や最も報告された値など、いくつかのルールタイプをサポートしています。動的調整ルールを適用する場合、IRE は現在のペイロードを処理し、CMDB 360 データストアを調べて、CMDB を更新する値を選択します。動的調整ルールのタイプによっては、適切な値の選択がすぐに確定しない場合があります。たとえば、最も報告された値が 1 つも存在しない場合や、値によっては、最後に検出されたタイムスタンプが報告されない場合があります。そのため IRE は必要に応じてフォールバックし、最後に報告された値、最後に検出された値、最後に更新された値などの追加の詳細を調べて、最も適切な値を選択します。