Traffic Optimization

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 webMethods 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 webMethods API Gateway. In such cases, the invocation count would still be 4 as the native API is yet to send the response to webMethods API Gateway. There is a minor delay in aggregating the count due to native API response delay. Hence, webMethods API Gateway allows additional invocation. However, when the invocation count exceeds 5 an alert is triggered.

Select the required options:

• API Gateway
• API Portal

• CentraSite

  Note: Applicable only for the APIs published from CentraSite to webMethods API Gateway.
• External 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 webMethods 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 webMethods 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 webMethods 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?.

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.

• 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 webMethods 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.

• 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.