拡張テーブルレコードを更新してクラスを変更すると何が起きるかIssue この記事は、拡張テーブルレコードのクラス/タスクタイプ [sys_class_name] フィールドを更新し、そのレコードを拡張テーブル階層を持つ別のテーブルに移動すると何が起きるかを説明して、デバッグを支援し、潜在的な問題を回避することを目的としています。 CMDB の観点では、これは CI の再分類と呼ばれ、階層内のレコードの移動先に応じて、クラスはアップグレード、ダウングレード、または変更される可能性があります。 インスタンスには 100 を超える拡張テーブルと、1,000 を超える子テーブルがあります。拡張モデルを理解すると、このフィールド値を変更した場合にレコードがテーブル間で移動されることを理解できます。 一般に、これらの手順は、既存のレコードが新しいクラス値で更新されたときに発生します。 インスタンス内のユーザーまたはスクリプトが、既存のレコードを更新します。sys_class_name 値と、場合によっては他のフィールドが変更されます。以前のクラスに対して更新前のビジネスルールが実行されます。1000 より前のエンジンも実行されます。非同期および後のビジネスルールは実行されません。GlideRecordClassSwitcher switchClass() は次を実行します。 いくつかのチェックを行います。「クラスの変更が検出されました。変更元： <previous.sys_class_name>、変更先： <current.sys_class_name> sys_id：<sys_id>」というログを記録します。 (Change in class detected, switching from: <previous.sys_class_name> to: <current.sys_class_name> sys_id: <sys_id>) 通貨フィールド値など、複数の値フィールドの外部レコードを更新します。すべてのレコード値をメモリに読み取ります。以前のクラステーブルからレコードを削除します。ビジネスルールなどは実行しません。元のレコードの以前の値をすべて使用して、新しいレコードを挿入します。ビジネスルールなどは実行しません。古いレコードに添付ファイルがある場合は、新しいレコードにアサインします。新しく挿入されたレコードを更新します。(これは最初の更新に加えて実行されます。) 新しいクラスに対して更新前のビジネスルールを実行します。更新を監査します。新しいクラスに対して更新後のビジネスルールを実行します。 Related Linksこのプロセスを考慮すると、次のことが起きる理由を説明できます。 「前」のビジネスルールの 2 回実行 ユーザーまたはスクリプトによる最初の更新 ソーステーブルに対する更新前のビジネスルール クラス変更コードによる追加の更新 ターゲットテーブルに対する更新前のビジネスルールターゲットテーブルに対する更新後のビジネスルールターゲットテーブルに対する非同期更新のビジネスルール .setWorkflow(false) によってビジネスルールや監査が実行されなくなることはない このメソッドは、「後続のアクションによって通常トリガーされるビジネスルールの実行を有効または無効にします。パラメーターが false に設定されている場合、挿入/更新は監査されません。監査は、GlideRecord 操作でパラメーターが true に設定されている場合にのみ行われます。」 スクリプトからクラス変更の更新を実行し、.update() の前に setWorkflow(false) を使用した場合、ソーステーブルに対して更新前のビジネスルールのみが実行されなくなります。 これは、クラス変更コードによって新しいレコード挿入後に行われる追加の Update() には影響しません。ターゲットテーブルに対する「前」、「後」、「非同期」のビジネスルールは、引き続きレコードに対して実行されます。それが実行されなくなることはありません。 多数のレコードをバッチ更新する場合は、どのビジネスルールが実行されるのかを (おそらくセッションデバッグを使用して) 分析し、更新の実行中に長時間実行されているビジネスルールや潜在的に問題のあるビジネスルールを無効化できます。 .autoSysFields(false) によって、更新済み、更新者などのフィールドの更新が実行されなくなることはない この機能は、「sys_updated_by、sys_updated_on、sys_mod_count、sys_created_by、および sys_created_on のフィールドへの更新を有効または無効にします。これは、履歴情報を変更せずにレコードのフィールド値を手動で更新するためによく使用されます。」 setWorkflow(false) と同様に、これは最初の更新にのみ適用されます。後続の挿入と更新では、新しい値が入力されます。sys_created_on はこれが実行される時になり、sys_mod_count はゼロに戻ります。 「クラス変更」フィルター条件が実行されても後ビジネスルールがトリガーされない 更新後ビジネスルールが実行されるまでに、挿入に対して更新は実行されており、クラスは変更されていません。これがフィルター条件を混乱させます。しかし、代わりに条件をスクリプト化することで、トリガーされるようになります。 条件：current.sys_class_name.changes(); データ損失：新しいクラスにフィールドが存在しない 以前のクラスに存在していたフィールドが新しいクラスに存在しない場合、それらの値は失われます。たとえば、cmdb_ci_win_server から cmdb_ci_ip_switch への再分類では、cpu_name や host_name などのフィールドが失われます。 データ損失：挿入に失敗した場合、このプロセス中にレコードが削除される可能性がある 上で説明したように、レコードは最初にソーステーブルから削除され、その後ターゲットテーブルに挿入されます。すでに削除が行われた後にさまざまな原因で挿入が行われない可能性があり、その場合はレコードが失われます。 挿入が行われる前に、トランザクションがタイムアウトしたか、ユーザーによってキャンセルされた可能性がある。これは Jakarta 以降でより頻繁に見られましたが、それ以前にも起こりえます。London 以降のバージョンでは、これを防ぐ必要があります。「KB0727782：PRB1242353 UI から多くの CI のクラスを変更すると、トランザクションがキャンセルされ、いくつかのレコードが削除される可能性がある」を参照してください。必須フィールドルールを含むデータポリシーにより挿入ができない可能性がある。 これは既知の製品欠陥です。「KB0727701：PRB631444 レコードの sys_class_name を変更する場合、必須フィールドのデータポリシーによりターゲットテーブルへの挿入ができないと、レコードが削除される可能性がある」を参照してください。 1 つのレコードに長い時間がかかる場合がある 1 つのレコードのクラス変更は 1 秒しかかかりませんが、実行には数分かかることがあります。これは、実行中のビジネスルールが原因である可能性があり、調査すべきルールをセッションデバッグで特定できます。 Jakarta (TPP が使用されたとき) と Kingston では、データベースログを分析すると、このモデルで使用される追加のディクショナリレコードが複数あるために、削除ステップ中にディクショナリと関連テーブルに対して多くのクエリを実行することに大部分の時間が費やされていたことがわかります。 London 以降、これは「KB0681177：PRB1258222 TPP 変更からの cmdb_ci クラス変更中の不要な更新」によって改善されました。 クラス変更前の監査レコードが欠落しているように見えることがある 監査は、その時点のテーブル名でログに記録されます。変更前の sys_audit レコードは、新しいテーブル名に更新されません。履歴セットと行を生成するコードは、これを考慮に入れて機能します。履歴リスト、アクティビティフォーマッター、CMDB タイムライン、CMDB ベースライン差分などの機能も履歴セットを使用するため、機能します。 新しいテーブル名を使用して sys_audit テーブルを直接クエリしている場合は、変更以降のレコードのみが表示されます。sys_id (document_key) のみを使用してください。 以前のクラスまたは現在のクラスのテーブルがディクショナリで監査済みに設定されていない場合、完全な監査履歴も期待できません。