Evaluating Limits

The IAlertTaskmanager

The IAlertTaskManager orchestrates the evaluation of limits. The default implementation of this interface can be found in LimitsAlertTaskManager, but you can define your own custom manager by following the general steps in the section on extending the module.

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 i.e. limit evaluations that do not result in a breach or warning. See the Limit Status screen for more information.

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

Scheduled evaluations

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

Properties

Property Value Description
task-scheduler-thread-pool-size 4 Thread pool size for the task scheduler.
sample-rate-cron 0 */5 * * * * Cron expression for the Intraday Alert task’s cron job.

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 task-scheduler-thread-pool-size property value. The default value is 4 threads.

The IAlertTaskManager 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 IAlertTaskManager 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, the default LimitsAlertTaskManager 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 property from the limits-properties file:

Property Value Description
incident.evaluation.parallel.tasks -1 Thread pool size for the evaluation task executors. A negative value indicates that half the available processors will be used.

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:

Property Value Description
limit.evaluation.error.include-stacktrace false true if the stack trace should be available in the evaluation response to the UI.

REST

Evaluation REST endpoints are available for:

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.

note

Triggering an evaluation populates the incidents store and creates or updates the workflow of the resulting incident.

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/{limitKey}
  • Method: Post
  • Example Endpoint: http://localhost:3090/limits/rest/v2/limitEvaluation/limit/evaluate/12345678?asOfDate=2023-01-31
Evaluate multiple limits

note

The limit keys provided do not need to belong to the same limit structure.

  • 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/{limitStructureKey}
  • 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

note

This endpoint is not optimized and may not be performant.

Unschedule tasks from the TaskScheduler

To unschedule a task from the AlertTaskManager, 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"
}