SLA 定義のドット連結条件を使用すべきではない理由<!-- /*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: ; } } 多くのユーザーにとって非常に一般的なユースケースは、たとえば、sc_req_itemテーブルのフィールド/変数の値に基づく開始、一時停止、停止、またはリセット条件の少なくとも一部を含む SLA 定義をsc_taskテーブルに用意することです。 これは決して良い考えではなく、ドット連結が使用される SLA 定義に基づくタスク SLA のコア SLA 機能が損なわれます。SLA 定義でドット連結条件を使用しないというこの理論は、上記の例に限ったことではなく、SLA 条件を構築するときにすべてのテーブルのすべてのドット連結フィールドを対象としています。 少なくとも、この種の実装は、関連する親 SLA 定義でドット連結値が使用されているtask_slaレコードの SLA 修理および SLA タイムライン機能が損なわれるためです。たとえば、サンプルの SLA 定義 (sc_task テーブルに基づいていますが、一部の条件の値をsc_req_itemフィールドから取得します) で修理 SLA を使用する場合、SLA 修理を使用すると、ドット連結値の履歴をさかのぼることはありません。SLA エンジンは、現在のレコードとその現在のレコードの監査履歴に対してのみ実行されます。ドット連結フィールドは、レコードの監査履歴のようにウォークスルーされることは決してないため、不正確な結果を提供して SLA 修理と SLA タイムラインの機能が損なわれます。 「SLA の修理」機能は、SLA 開始条件で参照されているフィールドの現在の値が依然として true と評価される場合にのみ、新しいtask_slaを正常に再添付できます。ただし、開始条件で参照されるドット連結フィールドが変更され、SLA 定義を満たさなくなった場合、SLA エンジンはその参照されたレコードの履歴値を評価できません。その結果、開始条件が以前に満たされていたと判断することはできず、task_slaは再添付されません。 例:sc_task テーブルの SLA 定義 ABC の開始条件が「request.request_state = 承認済み」である シナリオ 1： SCTASK123以前は SLA ABC が添付されていました。request.request_stateの現在の値は [承認済み] のままです。 結果：現在の開始条件が依然として true と評価されるため、修理 SLA を実行すると、task_slaが正常に再添付されます。 シナリオ 2： SCTASK123以前は SLA ABC が添付されていました。その後、request.request_state値は [完了してクローズ] に変更されました。 結果：修理 SLA を実行しても、task_slaは再添付されません。開始条件が過去に true であった可能性がありますが、SLA 履歴ウォーカーは、参照されているsc_requestレコードのドット連結フィールドの履歴値を評価できません。現在の値が開始条件を満たさなくなったため、SLA エンジンはtask_slaを再作成できません。SLA 定義を作成し、その中で条件を作成するための 正しい推奨 方法 は、SLA 定義の [テーブル] フィールドで指定されたテーブルのフィールドのみを利用することです。つまり、開始、一時停止、停止、またはリセット条件を他のテーブル値にドット連結しないでください。条件をビルドするときは、実行対象として SLA 定義が作成されているテーブルのフィールドのみを使用します。