API Gateway 10.15 | Using API Gateway | Implement APIs | Policies | Traffic Monitoring | Traffic Optimization
 
Traffic Optimization
This policy limits the number of API invocations during a specified time interval, and sends alerts to a specified destination when the performance conditions are violated. You can use this policy to avoid overloading the back-end services and their infrastructure, to limit specific clients in terms of resource usage, and so on.
The Traffic optimization policy generates two types of events when the specified limit is breached:
*Policy violation event. Indicates the violations that occur for an API. If there are 100 violations, then 100 policy violation events are generated.
*Monitor event. Controlled by the alert frequency configuration specified in the policy.
The table lists the properties that you can specify for this policy:
Property
Description
Limit Configuration
Rule name
Specifies the name of throttling rule to be applied. By default, the Total Request Count appears as the rule name and you cannot modify this.
Operator
Specifies the operator that connects the rule to the value specified. By default, the Greater Than operator is selected. It indicates that the throttling rule is applied when the Total Request Count for an API is greater than (exceeds the limit specified for) the value specified in the Value field.
Value
Specifies the value of the request count beyond which the policy is violated.
When multiple requests are made at the same time, it might be possible that this limit applied to trigger an alert is not strictly adhered to. There is no loss observed in the invocation counts data, but there might be a minor delay in aggregating the count. The invocation count gets incremented, only when API Gateway receives the response from the native API. For example, if you have set the limit at 5 with an interval alert of 1 minute and if you invoke 5 requests in parallel, out of which for 1 of the request the native API delays sending the response to API Gateway. In such cases, the invocation count would still be 4 as the native API is yet to send the response to API Gateway. There is a minor delay in aggregating the count due to native API response delay. Hence, API Gateway allows additional invocation. However, when the invocation count exceeds 5 an alert is triggered.
Destination
Specifies the destination to log the alerts.
Select the required options:
*API Gateway
*API Portal
*CentraSite
Note:
Applicable only for the APIs published from CentraSite to API Gateway.
*Digital Events
*Elasticsearch
*Email (you can add multiple email addresses by clicking ).
Note:
If an email alias is available, you can type the email alias in the Email Address field with the following syntax, ${emailaliasname}. For example, if test is the email alias, then type ${test}.
*JDBC
*Local Log: You can select the severity of the messages to be logged (logging level) from the Log Level drop-down list. The available log levels are ERROR, INFO, and WARN.
Note: 
*Set the Integration Server Administrator's logging level for API Gateway to match the logging levels specified for the run-time actions (go to Settings > Logging > Server Logger). For example, if a Log Invocation action is set to the logging level of Error, you must also set Integration Server Administrator's logging level for API Gateway to Error. If the action's logging level is set to a low level (Warning-level or Information level), but Integration Server Administrator's logging level for API Gateway is set to a higher level (Error-level), then only the higher-level messages are written to the log file.
*Entries posted to the local log are identified by a product code of YAI and suffixed with the initial alphabet of the logging level selected. For example, for an error level, the entry appears as [YAI.0900.0002E].
*SNMP
*List of destinations configured using the Custom destinations section. For details on publishing to custom destinations, see How Do I Publish API-specific Traffic Monitoring Data to a Custom Destination?.
Alert Interval
Specifies the interval of time for the limit to be reached.
The timer starts once the first API is activated and resets after the configured time interval. If an API is deactivated the interval gets reset, and on API activation the time interval starts afresh.
Unit
Specifies the unit of measurement of the Alert Interval configured, to monitor performance, before sending an alert. For example:
*Minutes
*Hours
*Days
*Calendar Week. The time interval starts on the first day of the week and ends on the last day of the week. By default, the start day of the week is set to Monday.
For example:
*If an API is activated on a Wednesday and Alert Interval is set to 1, the time interval ends on Sunday, that is, 5 days.
*If an API is activated on a Wednesday and Alert Interval is set to 2, the time interval still ends on Sunday, but the period is two calendar weeks, that is 12 days.
You can change the start day of the week using the extended setting startDayOfTheWeek in the Administration > General > Extended settings section. Restart the API Gateway server for the changes to take effect.
*Calendar Month. The time interval starts on the first day of the month and ends on the last day of the month.
For example:
*If an API is activated in the month of August and Alert Interval is set to 1, the time interval ends on the last day of August.
*If an API is activated in the month of August and Alert Interval is set to 2, the time interval ends in two calendar months, that is on the last day of September.
Alert Frequency
Specifies the frequency at which the alerts are issued and the monitor events are logged.
Specify one of the options:
*Only Once. Triggers an alert every time the specified condition is violated and logs a monitor event for the alert interval specified.
*Every Time. Triggers an alert every time the specified condition is violated and logs multiple monitor events based on the number of API invocations.
Alert Message
Specifies the text message to be included in the alert.
Consumer-specific throttling
Specifies whether the configured invocation limit has to apply to all consumer applications together or to each application individually.
Note:
This field is applicable only when you select the required applications from the Consumer Applications field.
Possible values:
*If this option is selected, each application specified in the Consumer Applications field is allowed to invoke the API the specified number of times within the given time limit. For example, consider the following:
You have specified consumer applications Consumer1 and Consumer2 and you allow 100 invocations per minute.
Then, Consumer1 can perform up to 100 invocations per minute and Consumer2 as well can perform the same without policy violation.
*If this option is not selected, the specified invocation limit is applied to all consumer applications together. For example, consider the following:
You have specified consumer applications Consumer1 and Consumer2 and you allow 100 invocations per minute.
Then, both consumer applications together can invoke the API for 100 times per minute without policy violation.
Consumer Applications
Specifies the consumer applications for which the policy is applied. Do one of the following:
*Select the required consumer applications. Type a keyword to find the required application and click + to add it.
*Select an option to apply the configured invocation limit:
*All consumers. To apply the invocation limit to all consumers. All consumer applications - including the registered, global applications, and default applications - to invoke the API the specified number of times within the given time limit. That is, the specified invocation limit is shared by all consumer applications.
For example, if you specify 1000 invocations per minute for an API, then the total number of invocations performed by all consumer applications in a minute cannot exceed 1000.
*All registered consumers. To apply the invocation limit to all registered consumers. Allows all registered consumer applications to invoke the API the specified number of times within the given time limit. That is, the specified invocation limit is shared by all registered consumer applications. The registered consumer applications are the applications that are registered with API to which the policy is applied.
For example. if you specify 1000 invocations per minute for an API, then the total number of invocations performed by all registered consumer applications in a minute cannot exceed 1000.
*All non-registered consumers. To apply the invocation limit to all non-registered consumers. Allows all non-registered consumer applications to invoke the API for the specified number of times within the given time limit. That is, the specified invocation limit is shared by all non-registered application. The non-registered applications are the applications that are not registered with the API to which the policy is applied.
For example, if you specify 1000 invocations per minute for an API, then the total number of invocations performed by all non-registered consumer applications in a minute cannot exceed 1000.
Note:
You can invoke an API using a non-registered consumer application only if the Global applications or Global applications and DefaultApplication option is selected from the Application Lookup Control field of the corresponding Identify & Authorize policy.
*Each consumer. To apply the invocation limit to each consumer. Allows each consumer application to invoke the API the specified number of times within the given time limit. That is, the specified invocation limit is applicable individually for each consumer application.
For example, if you specify 1000 invocations per minute for an API, then each consumer application can perform 1000 invocations in a minute
*Each registered consumer. To apply the invocation limit to each registered consumer. Allows each registered consumer application to invoke the API the specified number of times within the given time limit. That is, the specified invocation limit is applicable individually for each registered consumer application.
For example, if you specify 1000 invocations per minute, then each registered consumer application can perform 1000 invocations in a minute.
*Each non-registered consumer. To apply the invocation limit to each non-registered consumer. Allows each non-registered consumer application to invoke the API the specified number of times within the given time limit. That is, the specified invocation limit is applicable individually for each non-registered consumer application.
For example, if you specify 1000 invocations per minute, then each non-registered consumer application can perform 1000 invocations in a minute.
The invocation limit applied to newly added applications depends on the application type. The time limit starts when the associated API is activated or the application is associated to the policy. For example, consider the following:
API-level Traffic Optimization policy configured with invocation limit as 500 for 5 minutes, for All registered consumers. The available registered consumers are Consumer1 and Consumer2.
When you activate the policy, the two consumers together perform 200 invocations in 2 minutes. Register a new consumer application, Consumer3 to the list after 2 minutes from the start time. Then, all three consumers perform the remaining 300 invocations during the last 3 minutes without violating the policy.
Let us see one more example.
Global Traffic Optimization policy configured with invocation limit as 100 for 15 minutes, for Each consumer. The available consumers are Consumer1 and Consumer2.
When you activate the policy, the each consumer performs 100 invocations in 10 minutes. Add a new consumer application, Consumer3 to the list after 2 minutes from the start time. Then, the new consumer can also perform 100 invocations during the last 5 minutes without violating the policy.
Note:
If you select All consumers or Each consumer from this field and specify Registered applications from the Application Lookup Control field of the corresponding Identify & Authorize policy, then only the registered applications are allowed to invoke the API. In such scenarios, only the registered consumer applications can utilize the specified invocation limit.
You can invoke APIs using non-registered consumer applications only if the Global applications or Global applications and DefaultApplication option is selected from the Application Lookup Control field of the corresponding Identify & Authorize policy.
Traffic Optimization Policy Enforcement Scenarios
You can enforce more than one Traffic Optimization policy for an API based on your requirement. This section lists a sample requirement scenario and the possible solution:
How do I?
*Allow 1000 invocation per minute for each registered consumer application.
*Allow 500 invocation for 15 minutes for all non-registered consumer applications.
Possible solution
Create two Traffic Optimization policies with the following specifications
*Policy 1
*Value. 1000.
*Alert Interval. 1.
*Alert Frequency. minute.
*Consumer Applications. Each registered consumer.
*Policy 2
*Value. 500.
*Alert Interval. 15.
*Alert Frequency. minute.
*Consumer Applications. All non-registered consumers.