タスクレコードの [SLA 期限]、[SLA 締結有無]、および [エスカレーション] フィールドの目的は何ですか?Issue SLA エンジンが導入される前は (「2010 年秋」リリース)、SLA は「エスカレーション」エンジンによって処理され、各タスクレコードを 1 つの SLA に関連付けることができました。[SLA 期限]、[SLA 締結有無]、および [エスカレーション] フィールドは、エスカレーションエンジンによって管理されていました。この従来の SLA エンジンは、現在でも Express インスタンスで使用される唯一のエンジンです。 最新の SLA エンジンは、各タスクレコードに対して複数の SLA を追跡できるように、従来のエンジンから改善されています。ユーザーは、個々のタスク SLA レコードを表示することで、特定のタスク SLA レコードが違反したかどうかを確認できます。2010 年のエンジンでは、[ステージ] フィールドに [違反] と表示され、2011 年のエンジンでは新しい [違反 (Has breached)] フィールドが使用されています。 エスカレーションエンジンは、SLA プラグインを使用している場合でも、滞留アクティビティt_SetAnInactivityMonitorモニターもサポートしているため、システム内で引き続き存在し、実行されています。また、このサーバー側のコードにより、タスクがクローズされたときにmade_slaフィールドの値が変更される可能性があります。 システム内に従来の SLA フィールドが入力された既存のタスクレコードがある場合、それらは以前のリリースで作成された古いレコードである可能性があります。ただし、これは最新の SLA エンジンにはまったく影響しません。従来のフィールドは無視できます。また、その値は予期せず変更される可能性があるため、ユーザーによる使用は意図されていません。 これらの従来のフィールドに値が入力された状態で新しいタスクレコードが作成されている場合は、[com.snc.sla.run_old_sla_engine] システムプロパティを確認して、インスタンスがサービスレベルアグリーメントの従来のエスカレーションエンジンを使用するように構成されているかどうかを確認することで、それらが意図的に使用されているかどうかを確認できます。プロパティが false の場合、(システムによって操作されるため) フィールドは予約済みとなりますが、内容は無視できます。従来のサービスレベルアグリーメント定義テーブル (「sysrule_escalate」) の内容を確認することもできます。このテーブルへのアクセス方法によっては、従来の SLA 定義と滞留アクティビティモニター定義の両方が表示される場合があることに注意してください。