Authentication assertion
Group membership assertion
Throughput quota: maximum "x" per "y"
Routing assertion

Authentication assertion
At least one assertion must evaluate to true
  All assertions must evaluate to true
    Group membership A
    Throughput quota: maximum "x" per "y"
  All assertions must evaluate to true
    Group membership B
    Throughput quota: maximum "z" per "k"
Routing assertion

Do one of the following:
To add the assertion to the Policy Development window, see Add an Assertion.
To change the configuration of an existing assertion, proceed to step 2 below.
When adding the assertion, the Throughput Quota Properties automatically appear; when modifying the assertion, right-click 
Apply Throughput Quota 
in the policy window and choose 
Throughput Quota Properties
 or double-click the assertion in the policy window. The assertion properties are displayed. 
Configure the properties as follows.
Setting	Description
Quota
Max	Enter a request limit. The value can be any integer between 1 and 2147483647. You may specify a context variable, which allows the maximum value to be set at run time.
per	Choose a time period from the drop-down list. These periods are time based, and are not based on the first request. For example, if you choose a quota of 1000 requests per hour, then the Gateway enforces a limit of 1000 requests between the start and end of each hour of the day. This means: - 1000 requests are allowed between 12:00-12:59:59 - 1000 requests are allowed between 1:00-1:59:59 You cannot shift the intervals for the quotas. For example: - NOT supported: allow 1000 requests between 12:30-1:29:59. - NOT supported: allow 500 requests between 15:00:00 on January 1st to 14:59:59 on January 2nd Since the counters are time based, it is very important that your Gateway nodes are time synchronized. To configure time synchronization, see "Option 1 - Configure Networking and System Time Settings" in Gateway System Settings (Appliance).
Limit each	This quota is enforced on different types of "requestor" entities.Choose the method for limiting the quota from one of the following: Authenticated user: The quota is applied separately to each authenticated user. An authenticated user is an individual user who has been authenticated to an identity provider. This is the default. Example: UserA can make 1000 requests per hour; UserB can also make 1000 requests per hour. Client IP: The quota is applied separately to each client IP. Example: Client IP 10.10.10.10 can make 1000 requests per hour, and 11.11.11.11 can also make 1000 requests per hour. SOAP operation: The quota is applied separately to each SOAP operation. Example: 1000 requests per hour can be made for operation "listProduct", and 1000 requests per hour can be made for operation "listBrands". SOAP namespace: The quota is applied separately to each SOAP namespace. Example: 1000 requests per hour can be made for namespace "http://warehouse.acme.com/ws", and 1000 requests per hour can be made for namespace "http://playerstatsws.mycompany.com". Gateway cluster: The quota is applied across all Gateways within a cluster. Example: A cluster with 3 Gateways would allow a combined total of 1000 requests per hour, no matter which Gateway services the requests. Custom: The quota is applied to a custom entity that you specify in the Counter ID field. Use this option if none of the predefined counters meet your needs. Example: A custom request parameter "color" could be used and 1000 requests per hour can be made for each possible color (as specified by the administrator). Do this by setting the Counter ID to be based on the "color" request parameter value (for example, colorCounter.${request.http.parameter.colour}).
Log Only	This check box controls what the assertion does when the quota is exceeded. Select this check box to have the assertion log an audit message when the quota is exceeded. The assertion does not fail. Clear this check box to have the assertion fail if the quota is exceeded. The Log Only check box is available only when one of the "increment" options is selected below.
Counter
Counter ID	This section shows which counter is used to enforce the quota. The counters are prepopulated based on the Limit each option that was chosen. The Counter ID is not editable, except when Custom was selected. The Gateway uses the following identifiers for each counter: Authenticated user: <uuid>-${request.authenticateduser.id}-${request.authenticateduser.providerid} Client IP: <uuid>-${request.tcp.remoteAddress} SOAP operation: <uuid>-${request.soap.operation} SOAP namespace: <uuid>-${request.soap.namespace} Gateway cluster : <uuid> Custom: Enter your own string into the Counter ID field. You may reference context variables. If you need to modify one of the present Counter IDs, select the Custom option under Limit each . This makes the Counter ID field editable, while preserving the entry from the preset counter. Modifying an existing Counter ID is a quick way to create a custom counter. Example : You wish to limit the number of requests per hour to 1000 per client IP. To do this, enter "1000" for "Max" and then choose "Client IP" for Limit each . When this assertion is run, a counter is created for each requester coming from a different IP address. If more than 1000 requests per hour are sent from the same IP address, the assertion blocks that requester. Since a counter can only be incremented once within a single request context, the same counter can be used for different Apply Throughput Quota assertions within the same policy. In other words, regardless of the number of Apply Throughput Quota assertions in a policy, the Gateway only counts each request once towards the quota when the assertions use the same counter. The <uuid> is an 8-digit hex string, which consists of the last 8 digits of a full UUID string. Each Apply Throughput Quota assertion generates a different <uuid>. This means the <uuid> can be used to achieve different quota counters with the same quota settings, across different policies.
counter increment/ decrement options	Always increment: Always increment the counter before determining whether the quota limit has been reached. By default, the increment value is 1 unless overridden in the "by value" field. If the resulting counter value exceeds the quota, the assertion may fail, depending on the "Scalability" setting below. Increment only when still within quota: Only increment the counter if the resulting value does not exceed the quota. By default, the increment value is 1 unless overridden in the "by value" field. If the quota limit has not been reached, then the request is counted and the assertion succeeds. If the quota limit has been reached, the assertion may fail, depending on the "Scalability" setting below. The initiating request is not counted towards the quota. Decrement: Decrement the counter by a single count. By default, the decrement value is 1 unless overridden in the "by value" field. This option is typically used to ensure that service processing errors or incomplete transactions from the downstream service do not count towards the quota. The Decrement option works only if it follows one of the "increment" options ("Always increment" or "Increment only when still within quota"). To do this, add multiple instances of this assertion in the policy. If no increment has occurred, then the Decrement option does not change the counter value. Note that the Quota settings are disabled when you use the Decrement option. Reset: Reset all counter values to zero (seconds, minutes, hours, days, months). The Quota and Scalability settings are disabled. By value: This option is available for all settings, except for "Reset". Use it to specify the increment/decrement behavior: Select this check box to increment or decrement the counter by a specific integer value. You may reference context variables. Clear this check box to increment or decrement by 1. One good use of the "By value" setting is when bandwidth quotas are in effect. Simply set the "By value" increment to ${response.size} . This will increment the counter by the actual size of each response message, giving you an accurate indication of the bandwidth being used.
Scalability	Set the slider to your preferred mix of consistency versus scalability: Move the slider to Consistency have the Gateway enforce the quota restrictions, without exception. This may not provide optimal performance in situations where brief bursts of messages occur. This setting is the default. Move the slider to the midpoint to improve scalability and performance, permitting brief quota overflows under rare conditions. Technical explanation behind "rare" conditions... In the midpoint setting, writes are asynchronous, while reads go straight through to the database. The counter updates are placed in a queue, which is serviced on a default timed delay of 0.5 seconds to dump the queued updates to the database. Retrieving the counter value always retrieves from the database. The assertion checks if the counter would allow an increment. If so, it acts as though the increment had already occurred, and schedules a transaction to take place as soon as possible to perform the actual increment. If multiple increments are pending on the same node, they are batched into a single transaction. Multiple nodes updating the same counter take turns incrementing it in batches. For advanced technical users: You can tune the time delay for writing to the database with the com.l7tech.hacounter.flushTimeWriteDatabase system property. Move the slider to Scalability for maximum performance and scalability, permitting quota overflows more frequently. Technical explanation behind Scalability setting... In the Scalability setting, writes and reads are both done asynchronously. The writes are still placed in a queue to be serviced on a 0.5 second delay (similar to the "midpoint" setting). Counter values are retrieved from the database on a separate delay (default 60 seconds) and cached locally on the Gateway. Counter values are always read from this local cache, until the read delay has been reached, at which point the the cache is updated by retrieving from the database. For advanced technical users: You can tune this setting with the com.l7tech.hacounter.flushTimeWriteDatabase and  com.l7tech.hacounter.timeClearReadCache system properties.
Variable Prefix	Enter a prefix that is added to the context variables created by this assertion. This prefix ensures uniqueness and prevents the variables from overwriting each other when multiple instances of this assertion appear in a policy. Default: counter (if no prefix specified). For an explanation of the validation messages displayed, see "Context Variable Validation" in Context Variables.
Click [
OK
]
 
when done.