Evaluating Limits

The IEvaluationTaskManager and IEvaluationService

The IEvaluationTaskManager orchestrates the evaluation of limits. The default implementation of this interface can be found in DefaultEvaluationTaskManager. The IEvaluationService contains the logic for evaluating limits. The default implementation of this interface can be found in DefaultEvaluationService. For both of these interfaces, you can define your own implementation - see Adding Custom Evaluation Logic for more information.

When a breach or warning is detected, the Incidents Store is populated, the incident workflow is updated, and an incident*.csv file is generated. For details on the incident*.csv file, see Incidents file.

Optionally, you can also store passes, which are limit evaluations that do not result in a breach or warning. See the Limit Status screen for more information.

Limit evaluations through the IEvaluationService can either be scheduled or executed on-demand.

Scheduled evaluations

The IEvaluationTaskManager automatically schedules future evaluations for limit structures with an Intraday polling frequency. You can configure the Intraday polling frequency using the limits.alert-task.sample-rate-cron property values.

Properties

TaskScheduler

The TaskScheduler Bean allows you to schedule alert tasks, specified by the class AAlertTask, and can be found in the ThreadPoolTaskSchedulerConfig.java class. The quantity of threads allotted to the TaskScheduler can be configured with the limits.task-scheduler.thread-pool-size property value. The default value is 4 threads.

The IEvaluationTaskManager maintains a map of alert tasks, which are keyed by a unique task key. When alert tasks are scheduled, they are added to the map. This allows you to unschedule tasks if needed.

On-demand limit evaluation

The IEvaluationTaskManager is also responsible for evaluating limits on-demand. In general this is done through the UI by evaluating limits, but could also be done programmatically or via REST requests.

When evaluating limits on-demand, DefaultEvaluationService creates two TaskExecutors. One executor is responsible for running the evaluation code relevant to the limit structures and the other deals with the code pertaining to the limits. We use two executors to improve the speed of evaluation.

You can configure the executors to use an arbitrary number of threads using the following Configuration Property:

You can also configure the behavior when errors occur. For example, you can include a stack trace in the response by using the following property from the application.yml file:

REST

Evaluation REST endpoints are available for:

• On-demand limit evaluation
• Unscheduling tasks from the TaskScheduler

For any of the following endpoints that use an asOfDate query parameter, note that the asOfDate is optional. It is included in the examples to demonstrate the syntax, but if not provided, Atoti Limits defaults to the date provided in the as_of_date.csv file. The result of each response is a DTO containing the number of breaches, warnings and passes (if enabled) as well as any errors encountered during evaluation.

At the limit level

For evaluation on a per-limit basis, the following two REST endpoints can be used:

Evaluate a single limit

• Endpoint: /limits/rest/v2/limitEvaluation/limit/evaluate/{limitId}
• Method: Post
• Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/limit/evaluate/12345678?asOfDate=2023-01-31

Evaluate multiple limits

• Endpoint: /limits/rest/v2/limitEvaluation/limit/evaluate
• Method: Post
• Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/limit/evaluate?asOfDate=2023-01-31
• Example Request Body (the limit keys):

[
  12345678,
  -87654321
]

At the limit structure level

To evaluate on a per-limit structure basis, the following two REST endpoints can be used:

Evaluate a single limit structure

• Endpoint: /limits/rest/v2/limitEvaluation/structure/evaluate/{limitStructureId}
• Method: Post
• Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/structure/evaluate/12345678?asOfDate=2023-01-31

Evaluate multiple limit structures

• Endpoint: /limits/rest/v2/limitEvaluation/structure/evaluate
• Method: Post
• Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/structure/evaluate?asOfDate=2023-01-31
• Example Request Body (the limit structure keys):

[
  12345678,
  -87654321
]

Evaluate by KPI

This is equivalent to evaluation per limit structure. To evaluate a KPI against the business cubes, use the following REST endpoint:

• Endpoint: /limits/rest/v2/limitEvaluation
  
• Method: Post
  
• Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/evaluate
  
• Example Request Body:

{
    "kpiName":"SA Book Limit",
    "cubeName":"StandardisedApproachCube",
    "serverName":"FRTB"
}

At the application level

This endpoint evaluates all approved limits:

• Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/evaluate/all
• Method: Post
• Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/evaluate/all

Unschedule tasks from the TaskScheduler

To unschedule a task from the IEvaluationTaskManager, use the following REST endpoint:

• Endpoint: /limits/rest/v2/limitEvaluation/unschedule
• Method: POST
• Example Endpoint: http://localhost:3090/limits/v2/rest/limitEvaluation/unschedule

Example Body:

{
   "serverName":"FRTB",
   "cubeName":"StandardisedApproachCube",
   "kpiName":"SA Book Limit",
   "pollingFrequency":"INTRADAY"
}

Example Response (true if the task is unscheduled successfully, false otherwise):

{
  "true"
}