Kontingentrichtlinie

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Was

Mit der Kontingentrichtlinie können Sie die Anzahl der Anfragenachrichten konfigurieren, die ein API-Proxy in einem bestimmten Zeitraum zulässt, z. B. in einer Minute, einer Stunde, einem Tag, einer Woche oder einem Monat. Sie können festlegen, dass das Kontingent für alle Anwendungen, die auf den API-Proxy zugreifen, gleich ist, oder Sie können die Kontingente auf folgenden Grundlagen festlegen:

  • Das Produkt, das den API-Proxy enthält
  • Die Anwendung, die die Anfrage an die API sendet
  • Der Entwickler der Anwendung
  • Viele weitere Kriterien

Verwenden Sie das Kontingent nicht, um allgemeine Trafficspitzen zu verhindern. Dazu verwenden Sie die SpikeArrest-Richtlinie. Siehe Spike Arrest .

Videos

In diesen Videos wird die Kontingentverwaltung per Kontingentrichtlinie vorgestellt:

Einführung (New Edge)

Intro (Classic Edge)

Dynamisches Kontingent

Verteilt und synchron

Nachrichtengewichtung

Kalender

Rollierendes Zeitfenster

Flexi

Bedingtes Kontingent

Ablaufvariablen

Fehlerbehandlung

Beispiele

Diese Codebeispiele für Richtlinien zeigen, wie Sie das Start- und Enddatum für Kontingente festlegen:

Dynamischere Kontingente

<Quota name="CheckQuota"> 
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

Mit dynamischen Kontingenten können Sie eine einzelne Kontingentrichtlinie konfigurieren, die verschiedene Kontingenteinstellungen anhand der Angaben erzwingt, die an die Kontingentrichtlinie übergeben werden. Ein weiterer Begriff für Kontingenteinstellungen ist in diesem Kontext "Serviceplan". Beim dynamischen Kontingent wird der "Serviceplan" der Anwendungen geprüft und es werden diese Einstellungen erzwungen.

Hinweis: Wenn Sie für ein Element sowohl einen Wert als auch einen Verweis angeben, erhält die Referenz die Priorität. Wenn der Verweis zur Laufzeit nicht aufgelöst wird, ist der Wert verwendet.

Wenn Sie beispielsweise ein API-Produkt erstellen, können Sie optional das zulässige Kontingentlimit, die Zeiteinheit und das Intervall festlegen. Wenn Sie diesen Wert für das API-Produkt festlegen, wird die Verwendung in einem API-Proxy jedoch nicht erzwungen. Sie müssen außerdem eine Kontingentrichtlinie zum API-Proxy hinzufügen, die diese Werte liest. Weitere Informationen finden Sie unter API-Produkte erstellen.

Im obigen Beispiel verwendet der API-Proxy, der die Kontingentrichtlinie enthält, eine Richtlinie "VerifyAPIKey" mit dem Namen verify-api-key, um den in einer Anfrage übergebenen API-Schlüssel zu validieren. Die Kontingentrichtlinie greift dann auf die Ablaufvariablen aus der VerifyAPIKey-Richtlinie zu, um die für das API-Produkt festgelegten Kontingentwerte zu lesen. Weitere Informationen zu VerifyAPIKey-Ablaufvariablen finden Sie unter API-Schlüsselrichtlinie prüfen.

Eine weitere Option besteht darin, benutzerdefinierte Attribute für einzelne Entwickler oder Anwendungen festzulegen und diese Werte dann in der Kontingentrichtlinie zu lesen. Sie können beispielsweise unterschiedliche Kontingentwerte pro Entwickler festlegen. In diesem Fall legen Sie benutzerdefinierte Attribute für den Entwickler fest, die das Limit, die Zeiteinheit und das Intervall enthalten. Verweisen Sie dann in der Kontingentrichtlinie auf diese Werte:

<Quota name="DeveloperQuota"> 
  <Identifier ref="verifyapikey.verify-api-key.client_id"/> 
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/> 
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/> 
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/> 
</Quota>

In diesem Beispiel werden auch die VerifyAPIKey-Ablaufvariablen verwendet, um auf die benutzerdefinierten Attribute zu verweisen, die für den Entwickler festgelegt wurden.

Sie können eine beliebige Variable verwenden, um die Parameter der Kontingentrichtlinie festzulegen. Diese Variablen können aus folgenden Quellen stammen:

  • Ablaufvariablen
  • Attribute für das API-Produkt, die Anwendung oder den Entwickler
  • Eine Schlüssel/Wert-Paar-Zuordnung (KVM)
  • Ein Header, Suchparameter, Formularparameter usw.

Sie können für jeden API-Proxy eine Kontingentrichtlinie hinzufügen, die entweder auf dieselbe Variable verweist wie alle anderen Kontingentrichtlinien in allen anderen Proxys oder die Kontingentrichtlinie kann auf Variablen verweisen, die für diese Richtlinie und diesen Proxy einzigartig sind.

Beginn

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Für ein Kontingent, bei dem type als calendar festgelegt ist, müssen Sie einen expliziten <StartTime>-Wert festlegen. Der Zeitwert ist die GMT-Zeit, nicht die Ortszeit. Wenn Sie für eine Richtlinie des Typs keinen <StartTime>-Wert angeben calendar, Edge gibt einen Fehler aus.

Der Kontingentzähler wird pro Anwendung anhand der Werte <StartTime>, <Interval> und <TimeUnit> aktualisiert. In diesem Beispiel beginnt das Kontingent am 18. Februar 2017 um 10:30 Uhr GMT zu zählen. Die Aktualisierung erfolgt alle 5 Stunden. Die nächste Aktualisierung erfolgt also am 18. Februar 2017 um 15:30 Uhr GMT.

Access Counter

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Ein API-Proxy hat Zugriff auf die durch die Kontingentrichtlinie festgelegten Flussvariablen. Sie können auf diese Flussvariablen im API-Proxy zugreifen, um eine bedingte Verarbeitung durchzuführen, die Richtlinie im Blick zu behalten, wenn das Kontingentlimit erreicht wird, den aktuellen Kontingentzähler an eine Anwendung zurückzugeben oder aus anderen Gründen.

Da der Zugriff auf die Flussvariablen für die Richtlinie auf dem Attribut name der Richtlinie basiert, greifen Sie für die oben genannte Richtlinie mit dem Namen QuotaPolicy so auf die Flussvariablen zu:

  • ratelimit.QuotaPolicy.allowed.count: Zugelassene Menge.
  • ratelimit.QuotaPolicy.used.count: Aktueller Zählerwert.
  • ratelimit.QuotaPolicy.expiry.time: UTC-Zeit, zu der der Zähler zurückgesetzt wird.

Es gibt viele weitere Flussvariablen, auf die Sie wie unten beschrieben zugreifen können.

Sie können beispielsweise die folgende AssignMessage-Richtlinie verwenden, um die Werte der Flussvariablen eines Kontingents als Antwortheader zurückzugeben:

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

First Request

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

Verwenden Sie diesen Beispielcode, um ein Kontingent von 10.000 Aufrufen pro Stunde zu erzwingen. Die Richtlinie setzt den Kontingentzähler zu jeder vollen Stunde zurück. Wenn der Zähler das Kontingent von 10.000 Aufrufen vor Ablauf der Stunde erreicht, werden weitere Aufrufe abgelehnt.

Wenn der Zähler beispielsweise bei 2017-07-08 07:00:00 beginnt, wird der Wert am 2017-07-08 08:00:00 (eine Stunde ab der Startzeit) auf 0 zurückgesetzt. Wenn die erste Nachricht am 2017-07-08 07:35:28 eingeht und die Anzahl der Nachrichten vor 2017-07-08 08:00:00 10.000 erreicht hat, werden weitere Aufrufe abgelehnt, bis der Zähler zur vollen Stunde zurückgesetzt wird.

Die Zeit bis zum Zurücksetzen des Zählers basiert auf der Kombination aus <Interval> und <TimeUnit>. Wenn Sie beispielsweise <Interval> für eine <TimeUnit>-Stunde auf 12 setzen, wird der Zähler alle 12 Stunden zurückgesetzt. Sie können <TimeUnit> auf Minute, Stunde, Tag, Woche oder Monat festlegen.

Sie können in Ihrem API-Proxy an mehreren Stellen auf diese Richtlinie verweisen. Sie können es beispielsweise im Proxy-PreFlow platzieren, damit er bei jeder Anfrage ausgeführt wird. Alternativ können Sie sie auch in mehreren Abläufen im API-Proxy platzieren. Wenn Sie diese Richtlinie an mehreren Stellen im Proxy verwenden, wird ein einzelner Zähler verwaltet, der von allen Instanzen der Richtlinie aktualisiert wird.

Alternativ können Sie mehrere Kontingentrichtlinien in Ihrem API-Proxy definieren. Jede Kontingentrichtlinie nutzt dann einen eigenen Zähler, gemäß dem Attribut name der Richtlinie.

ID festlegen

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/> 
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Bei einer Kontingentrichtlinie wird standardmäßig ein einzelner Zähler für den API-Proxy definiert, unabhängig vom Ursprung einer Anfrage. Alternativ können Sie bei einer Kontingentrichtlinie das Attribut <Identifier> verwenden, um separate Zähler basierend auf dem Wert des Attributs <Identifier> zu verwalten.

Beispielsweise können Sie mit dem Tag <Identifier> separate Zähler für jede Client-ID definieren. Bei einer Anfrage an Ihren Proxy übergibt die Clientanwendung, wie im obigen Beispiel gezeigt, einen Header, der clientID enthält.

Sie können eine beliebige Ablaufvariable im Attribut <Identifier> angeben. Beispiel: Sie können angeben, dass ein Abfrageparameter namens id die eindeutige Kennzeichnung enthält:

<Identifier ref="request.queryparam.id"/>

Wenn Sie die VerifyAPIKey-Richtlinie zur Validierung des API-Schlüssels oder der OAuthV2-Richtlinien mit OAuth-Tokens verwenden, können Sie Informationen im API-Schlüssel oder -Token nutzen, um einzelne Zähler für dieselbe Kontingentrichtlinie zu definieren. Beispiel: Folgender <Identifier>-Tag verwendet die Ablaufvariable client_id einer VerifyAPIKey-Richtlinie mit dem Namen verify-api-key:

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

Jeder eindeutige client_id-Wert definiert nun einen eigenen Zähler in der Kontingentrichtlinie.

Klasse

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

Sie können Kontingentlimits dynamisch festlegen, indem Sie eine klassenbasierte Kontingentzählung verwenden. In diesem Beispiel wird das Kontingentlimit durch den Wert des Headers developer_segment bestimmt, der mit jeder Anfrage übergeben wird. Diese Variable kann den Wert platinum oder silver haben. Wenn der Header einen ungültigen Wert enthält, gibt die Richtlinie einen Fehler wegen Kontingentverletzung zurück.


Informationen zur Kontingentrichtlinie

Ein Kontingent gibt die Anzahl der Anfragenachrichten an, die ein API-Proxy über einen bestimmten Zeitraum verarbeiten kann, z. B. Minute, Stunde, Tag, Woche oder Monat. Die Richtlinie verwaltet Zähler, in denen die Anzahl der Anfragen erfasst wird, die vom API-Proxy empfangen werden. Mit dieser Funktion können API-Anbieter Limits für die Anzahl von API-Aufrufen festlegen, die von Apps über einen bestimmten Zeitraum ausgeführt werden. Mit Kontingentrichtlinien können Sie beispielsweise Anwendungen auf eine Anfrage pro Minute oder 10.000 Anfragen pro Monat beschränken.

Wenn als Kontingent beispielsweise 10.000 Nachrichten pro Monat definiert sind, beginnt die Ratenbegrenzung nach der 10.000. Nachricht. Dabei spielt es keine Rolle, ob am ersten oder am letzten Tag dieses Zeitraums 10.000 Nachrichten gezählt wurden. Es sind keine weiteren Anfragen zugelassen, bis der Kontingentzähler am Ende des angegebenen Zeitintervalls automatisch zurückgesetzt wird oder bis das Kontingent mithilfe der Richtlinie zum Zurücksetzen von Kontingenten explizit zurückgesetzt wird.

Eine Variante des Kontingents namens SpikeArrest verhindert Trafficspitzen (oder Bursts), die durch einen plötzlichen Nutzungsanstieg, einen fehlerhaften Client oder bösartige Angriffe verursacht werden können. Weitere Informationen zu SpikeArrest finden Sie unter Spike Arrest-Richtlinie.

Kontingente gelten für einzelne API-Proxys und werden nicht unter API-Proxys aufgeteilt. Beispiel: Wenn Sie drei API-Proxys in einem API-Produkt haben, wird ein Kontingent nicht für alle drei genutzt, auch wenn alle drei die gleiche Kontingentrichtlinie-Konfiguration verwenden.

Typen von Kontingentrichtlinien

Die Kontingentrichtlinie unterstützt verschiedene Typen von Richtlinien: Standard, calendar, flexi und rollingwindow. Für jeden Typ ist definiert, wann der Kontingentzähler gestartet und zurückgesetzt wird, wie in der folgenden Tabelle dargestellt:

Zeiteinheit Standardmäßige Zurücksetzung (oder Null) Kalenderzurücksetzung Zurücksetzung Flexi
Minute Beginn der nächsten Minute Eine Minute nach <StartTime> Eine Minute nach der ersten Anfrage
Stunde Volle nächste Stunde 1 Stunde nach <StartTime> 1 Stunde nach der ersten Anfrage
Tag Mitternacht GMT des aktuellen Tages 24 Stunden nach <StartTime> 24 Stunden nach der ersten Anfrage
Woche Sonntags um Mitternacht GMT am Ende der Woche Eine Woche nach <StartTime> Eine Woche nach der ersten Anfrage
Monat Mitternacht GMT am letzten Tag des Monats Einen Monat (28 Tage) nach <StartTime> Einen Monat (28 Tage) nach der ersten Anfrage

Für type="calendar" müssen Sie den Wert von <StartTime> angeben.

In der Tabelle ist der Wert für den Typ rollingwindow nicht aufgeführt. Die rollierenden Fensterkontingente werden durch Festlegen der Größe eines Kontingentfensters, z. B. eine Stunde oder ein Zeitfenster, festgelegt. Wenn eine neue Anfrage eingeht, bestimmt die Richtlinie, ob das Kontingent in der Vergangenheit überschritten wurde.

Sie definieren zum Beispiel ein zweistündiges Zeitfenster, in dem 1.000 Anfragen zugelassen werden. Um 16:45 Uhr geht eine neue Anfrage ein. Die Richtlinie berechnet den Kontingentzähler für das letzte Fenster von zwei Stunden, d. h. die Anzahl der Anfragen seit 14:45 Uhr. Wenn das Kontingentlimit in diesem zweistündigen Zeitraum nicht überschritten wurde, wird die Anfrage zugelassen.

Eine Minute später, um 16:46 Uhr, geht eine weitere Anfrage ein. Jetzt berechnet die Richtlinie den Kontingentzähler seit 14:46 Uhr, um zu ermitteln, ob das Limit überschritten wurde.

Beim Typ rollingwindow wird der Zähler nie zurückgesetzt, sondern bei jeder Anfrage neu berechnet.

Informationen zu Kontingentzählern

Standardmäßig gilt für eine Kontingentrichtlinie ein einzelner Zähler, unabhängig davon, wie oft Sie in einem API-Proxy darauf verweisen. Der Name des Kontingentzählers basiert auf dem Attribut name der Richtlinie.

Sie erstellen beispielsweise eine Kontingentrichtlinie namens MyQuotaPolicy mit einem Limit von fünf Anfragen und platzieren diese in mehreren Abläufen (A, B und C) im API-Proxy. Auch wenn der Zähler in mehreren Abläufen verwendet wird, bleibt er ein einzelner Zähler, der von allen Instanzen der Richtlinie aktualisiert wird:

  • Ablauf A wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 1.
  • Ablauf B wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 2.
  • Ablauf A wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 3.
  • Ablauf C wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 4.
  • Ablauf A wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 5.

Die nächste Anfrage an einen der drei Abläufe wird abgelehnt, da der Kontingentzähler sein Limit erreicht hat.

Die Verwendung derselben Kontingentrichtlinie an mehreren Stellen in einem API-Proxy-Ablauf, wodurch das Kontingent ungewollt schneller als erwartet erschöpft, ist ein Anti-Muster, das in The Book of Apigee Edge Antipatterns

Alternativ können Sie mehrere Kontingentrichtlinien in Ihrem API-Proxy definieren und in jedem Ablauf eine andere Richtlinie verwenden. Jede Kontingentrichtlinie nutzt dann einen eigenen Zähler, gemäß dem Attribut name der Richtlinie.

Alternativ können Sie das Element <Class> oder <Identifier> in der Kontingentrichtlinie verwenden, um mehrere eindeutige Zähler in einer einzelnen Richtlinie zu definieren. Wenn Sie diese Elemente verwenden, kann eine einzelne Richtlinie verschiedene Zähler verwalten – auf Grundlage der Anwendung, die die Anfrage stellt, des App-Entwicklers, der die Anfrage stellt, einer Client-ID, einer Client-Kennzeichnung und so weiter. Weitere Informationen zur Verwendung der Elemente <Class> und <Identifier> finden Sie in den obigen Beispielen.

Zeitnotation

Alle Kontingentzeiten sind auf die koordinierte Weltzeit (UTC) eingestellt.

Die Notation der Kontingentzeit entspricht der internationalen Standardnotation, die im internationalen Standard ISO 8601 definiert ist.

Datumsangaben sind als Jahr, Monat und Tag im folgenden Format definiert: YYYY-MM-DD. Beispielsweise steht 2015-02-04 für den 4. Februar 2015.

Die Tageszeit wird im folgenden Format als Stunden, Minuten und Sekunden angegeben: hours:minutes:seconds. Beispielsweise steht 23:59:59 für die Uhrzeit um eine Sekunde vor Mitternacht.

Beachten Sie, dass es zwei Notationen gibt, nämlich 00:00:00 und 24:00:00, um zwischen den beiden Uhrzeiten um Mitternacht zu unterscheiden, die einem Datum zugeordnet werden können. Daher ist 2015-02-04 24:00:00 dasselbe Datum und dieselbe Uhrzeit wie 2015-02-05 00:00:00. Letzteres ist normalerweise die bevorzugte Notation.

Kontingenteinstellungen aus der API-Produktkonfiguration abrufen

Sie können Kontingentlimits in API-Produktkonfigurationen festlegen. Diese Limits erzwingen nicht automatisch ein Kontingent. Stattdessen können Sie in einer Kontingentrichtlinie auf die Einstellungen für das Produktkontingent verweisen. Beim Festlegen eines Kontingents für das Produkt haben Sie folgende Vorteile:

  • Bei Kontingentrichtlinien kann eine einheitliche Einstellung für alle API-Proxys im API-Produkt verwendet werden.
  • Sie können Laufzeitänderungen an der Kontingenteinstellung eines API-Produkts vornehmen. Außerdem haben Kontingentrichtlinien, die auf den Wert verweisen, automatisch aktualisierte Kontingentwerte.

Weitere Informationen zur Verwendung der Kontingenteinstellungen aus einem API-Produkt finden Sie im obigen Beispiel "Dynamisches Kontingent".

Informationen zum Konfigurieren von API-Produkten mit Kontingentlimits finden Sie unter API-Produkte erstellen.

Elementverweis

Die folgenden Elemente und Attribute können Sie für diese Richtlinie konfigurieren: Beachten Sie, dass einige Elementkombinationen sich gegenseitig ausschließen oder nicht erforderlich sind. Unter den jeweiligen Beispielen werden konkrete Anwendungsfälle gezeigt. Die unten aufgeführten verifyapikey.VerifyAPIKey.apiproduct.*-Variablen sind standardmäßig verfügbar, wenn eine API-Schlüsselrichtlinie "VerifyAPIKey" verwendet wird, um den API-Schlüssel der Anwendung in der Anfrage zu prüfen. Die Variablenwerte stammen aus den Kontingenteinstellungen des API-Produkts, dem der Schlüssel zugeordnet ist, wie unter Kontingenteinstellungen der API-Produktkonfiguration abrufen beschrieben.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval> 
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime> 
   <Distributed>false</Distributed> 
   <Synchronous>false</Synchronous> 
   <AsynchronousConfiguration> 
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds> 
      <SyncMessageCount>5</SyncMessageCount> 
   </AsynchronousConfiguration> 
   <Identifier/> 
   <MessageWeight/> 
</Quota>

<Quota>-Attribute

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

Die folgenden Attribute sind spezifisch für diese Richtlinie.

Attribut Beschreibung Standard Präsenz
Typ

Hiermit können Sie bestimmen, wann und wie der Kontingentzähler die Kontingentnutzung prüft. Weitere Informationen finden Sie unter Kontingentrichtlinien.

Wenn Sie einen type-Wert weglassen, beginnt der Zähler am Anfang der Minute/Stunde/Tag/Woche/Monat.

Gültige Werte sind:

  • calendar: Konfigurieren Sie ein Kontingent anhand einer expliziten Startzeit. Der Kontingentzähler für jede Anwendung wird anhand der von Ihnen festgelegten Werte für <StartTime>, <Interval> und <TimeUnit> aktualisiert.
  • rollingwindow: Konfigurieren Sie ein Kontingent, das ein "rollierendes Fenster" verwendet, um die Kontingentnutzung zu ermitteln. Mithilfe von rollingwindow legen Sie die Größe des Fensters mit den Elementen <Interval> und <TimeUnit> fest, zum Beispiel 1 Tag. Wenn eine Anfrage eingeht, ermittelt Edge die exakte Uhrzeit der Anfrage (z. B. 17:01 Uhr), die Anzahl der Anfragen, die zwischen dieser Uhrzeit und 17:01 Uhr am Vortag eingegangen sind, und bestimmt, ob das Kontingent während dieses Zeitfensters überschritten wurde.
  • flexi: Konfigurieren Sie ein Kontingent, das bewirkt, dass der Zähler startet, wenn die erste Anfragenachricht von einer Anwendung empfangen wird, und das auf Grundlage der Werte <Interval>, und <TimeUnit> zurückgesetzt wird.
calendar Optional

In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:

Attribut Beschreibung Standard Präsenz
name

Der interne Name der Richtlinie. Der Wert des Attributs name kann Buchstaben, Ziffern, Leerzeichen, Bindestriche, Unterstriche und Punkte enthalten. Dieser Wert darf 255 Zeichen nicht überschreiten.

Optional können Sie das Element <DisplayName> verwenden, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

Erforderlich
continueOnError

Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird.

false Optional
enabled

Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen.

Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

true Optional
async

Dieses Attribut wurde verworfen.

false Veraltet

<DisplayName>-Element

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<DisplayName>Policy Display Name</DisplayName>
Standardeinstellung

Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs name der Richtlinie verwendet.

Präsenz Optional
Typ String

<Allow>-Element

Gibt das numerische Limit für das Kontingent an. Wenn der Zähler für die Richtlinie dieses Limit erreicht, werden nachfolgende Aufrufe abgelehnt, bis der Zähler zurückgesetzt wird.

Hier sehen Sie drei Möglichkeiten zum Festlegen des Elements <Allow>:

<Allow count="2000"/> 
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

Wenn Sie sowohl count als auch countRef angeben, erhält countRef die Priorität. Wenn countRef zur Laufzeit nicht aufgelöst wird, wird der Wert von count verwendet.

Standard:
Präsenz: Optional
Typ: Ganzzahl

Attribute

Attribut Beschreibung Standard Präsenz
count

Dient zum Angeben einer Nachrichtenzahl für das Kontingent.

Ein Wert von 100 für das Attribut count, ein Interval von 1 und die TimeUnit "Monat" geben beispielsweise ein Kontingent von 100 Nachrichten pro Monat an.

2000 Optional
countRef

Dient zum Angeben einer Ablaufvariable, die die Nachrichtenanzahl für ein Kontingent enthält. countRef hat Vorrang vor dem Attribut count.

keine Optional

<Allow>/<Class>-Element

Mit dem Element <Class> können Sie den Wert des Elements <Allow> basierend auf dem Wert einer Flussvariablen an Bedingungen knüpfen. Für jedes unterschiedliche untergeordnete <Allow>-Tag von <Class> verwaltet die Richtlinie einen anderen Zähler.

Wenn Sie das <Class>-Element verwenden möchten, geben Sie eine Ablaufvariable mithilfe des Attributs ref für das Tag <Class> an. Edge verwendet dann den Wert des können Sie eines der <Allow> untergeordneten Tags auswählen, um die zulässige Anzahl der Richtlinie. Edge entspricht dem Wert der Flussvariablen mit class des <Allow>-Tags wie unten gezeigt:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

In diesem Beispiel wird der aktuelle Kontingentzähler durch den Wert des an Ihrer Anfrage übergebenen Abfrageparameters time_variable bestimmt. Diese Variable kann den Wert peak_time oder off_peak_time haben. Wenn der Abfrageparameter einen ungültigen Wert enthält, gibt die Richtlinie einen Fehler wegen Kontingentverletzung zurück.

Standard:
Präsenz: Optional
Typ:

Attribute

Attribut Beschreibung Standard Präsenz
ref

Dient zum Angeben einer Ablaufvariable, die die Kontingentklasse für ein Kontingent enthält.

keine Erforderlich

<Allow>/<Class>/<Allow>-Element

Das Element <Allow> gibt das Limit für einen Kontingentzähler an, der durch das Element <Class> definiert ist. Für jedes unterschiedliche untergeordnete <Allow>-Tag von <Class> verwaltet die Richtlinie einen anderen Zähler.

Beispiel:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

In diesem Beispiel pflegt die Kontingentrichtlinie zwei Kontingentzähler mit dem Namen von peak_time und off_peak_time.

Standard:
Präsenz: Optional
Typ:

Attribute

Attribut Beschreibung Standard Präsenz
Klasse

Definiert den Namen des Kontingentzählers.

keine Erforderlich
count Gibt das Kontingentlimit für den Zähler an. keine Erforderlich

<Interval>-Element

Wird zur Angabe einer Ganzzahl verwendet (z. B. 1, 2, 5, 60 usw.), die mit der von Ihnen angegebenen TimeUnit gekoppelt wird (Minute, Stunde, Tag, Woche oder Monat), um einen Zeitraum zu bestimmen, in dem Edge die Kontingentnutzung berechnet.

Ein Interval von 24 mit einer TimeUnit von hour bedeutet, dass das Kontingent über einen Zeitraum von 24 Stunden berechnet wird.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
Standard: keine
Präsenz: Erforderlich
Typ: Ganzzahl

Attribute

Attribut Beschreibung Standard Präsenz
ref

Wird verwendet, um eine Ablaufvariable anzugeben, die das Intervall für ein Kontingent enthält. ref hat Vorrang vor einem expliziten Intervallwert. Wenn sowohl Referenz als auch Wert angegeben sind, erhält die Referenz die Priorität. Wenn ref nicht zur Laufzeit aufgelöst wird, wird der Wert verwendet.

keine Optional

<TimeUnit>-Element

Dient zum Angeben der Zeiteinheit für das Kontingent.

Ein Interval von 24 mit einer TimeUnit von hour bedeutet, dass das Kontingent über einen Zeitraum von 24 Stunden berechnet wird.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
Standard: keine
Präsenz: Erforderlich
Typ:

String. Wählen Sie zwischen minute, hour, day, week und month.

Attribute

Attribut Beschreibung Standard Präsenz
Ref Mit diesem Parameter legen Sie eine Ablaufvariable fest, die die Zeiteinheit für ein Kontingent enthält. ref hat Vorrang vor einem expliziten Intervallwert. Wenn die .ref nicht zur Laufzeit aufgelöst wird, wird der Wert verwendet. Optional

<StartTime>-Element

Wenn type auf calendar, gesetzt ist, werden hiermit Datum und Uhrzeit für den Start des Kontingentzählers angegeben, unabhängig davon, ob Anfragen von Anwendungen empfangen wurden.

Sie müssen ein explizites StartTime angeben, wenn type explizit auf calendar, festgelegt ist. Sie können keinen Verweis auf eine Flussvariable verwenden. Wenn Sie einen StartTime-Wert angeben und kein type-Wert festgelegt ist, erhalten Sie eine Fehlermeldung.

Beispiel:

<StartTime>2017-7-16 12:00:00</StartTime>
Standard: keine
Präsenz: Erforderlich, wenn type auf calendar gesetzt ist.
Typ:

String im Datums- und Zeitformat nach ISO 8601.

<Distributed>-Element

Eine Installation von Edge kann einen oder mehrere Message Processors zur Verarbeitung von Anfragen verwenden. Setzen Sie dieses Element auf true, um anzugeben, dass die Richtlinie einen zentralen Zähler verwalten soll und dieser kontinuierlich auf allen Message Processors synchronisiert wird. Die Message Processors können sich in verschiedenen Verfügbarkeitszonen und/oder Regionen befinden.

<ph type="x-smartling-placeholder">

Wenn Sie den Standardwert false verwenden, kann Ihr Kontingent überschritten werden, da die Zahl für jeden Message Processor nicht gemeinsam genutzt wird:

<Distributed>true</Distributed>

Um dafür zu sorgen, dass die Zähler bei jeder Anfrage synchronisiert und aktualisiert werden, legen Sie <Distributed> und <Synchronous> auf „true“ fest:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>
Standard: false
Präsenz: Optional
Typ: Boolean

<Synchronous>-Element

Legen Sie true fest, um einen verteilten Kontingentzähler synchron zu aktualisieren. Dieses Das bedeutet, dass die Aktualisierung des Zählers zur selben Zeit erfolgt, zu der das Kontingent bei einer Anfrage geprüft wird an die API senden. Setzen Sie den Wert auf true, wenn Sie keine API-Aufrufe über das Kontingent zulassen möchten.

Setzen Sie den Wert auf false, um den Kontingentzähler asynchron zu aktualisieren. Dies bedeutet, dass einige API-Aufrufe trotz Überschreitung des Kontingents möglicherweise ausgeführt werden. Dies hängt davon ab, wann der Kontingentzähler im zentralen Repository asynchron aktualisiert wird. Es bestehen jedoch keine Auswirkungen auf die Leistung wie bei einer synchronen Aktualisierung.

Bei asynchroner Aktualisierung beträgt das Standardaktualisierungsintervall 10 Sekunden. Verwenden Sie das Element AsynchronousConfiguration, um dieses asynchrone Verhalten zu konfigurieren.

<Synchronous>false</Synchronous>
Standard: false
Präsenz: Optional
Typ: Boolean

<AsynchronousConfiguration>-Element

Konfiguriert das Synchronisierungsintervall zwischen verteilten Kontingentzählern, wenn das Richtlinienkonfigurationselement <Synchronous> nicht vorhanden ist oder vorhanden und auf false festgelegt ist.

Sie können nach einem Zeitraum oder einer Nachrichtenzahl synchronisieren und dabei eines der untergeordneten Elemente SyncIntervalInSeconds oder SyncMessageCount verwenden. Diese schließen sich gegenseitig aus. Beispiel:

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

oder

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>
Standard: SyncIntervalInSeconds = 10 Sekunden
Präsenz: Optional; wird ignoriert, wenn <Synchronous> auf true gesetzt ist.
Typ:

Komplex

<AsynchronousConfiguration>/<SyncIntervalInSeconds>-Element

Verwenden Sie dieses Element, um das Standardverhalten zu überschreiben, bei dem asynchrone Aktualisierungen nach einem Intervall von 10 Sekunden ausgeführt werden.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

Das Synchronisierungsintervall muss mindestens 10 Sekunden lang sein, wie im Thema Limits beschrieben.

Standard: 10
Präsenz: Optional
Typ:

Integer

<AsynchronousConfiguration>/<SyncMessageCount>-Element

Gibt die Anzahl der Anfragen bei allen Message Processors von Apigee zwischen Kontingentaktualisierungen an.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

In diesem Beispiel wird angegeben, dass die Kontingentanzahl nach jeweils 5 Anfragen bei allen Message Processors von Apigee Edge aktualisiert wird.

Standard:
Präsenz: Optional
Typ:

Integer

<Identifier>-Element

Verwenden Sie das Element <Identifier>, um die Richtlinie so zu konfigurieren, dass gemäß einer Ablaufvariable eindeutige Zähler erstellt werden.

Sie können eindeutige Zähler für die von einer Ablaufvariablen definierten Eigenschaften erstellen. Beispiel: Sie können die E-Mail-Adresse des Entwicklers verwenden, um ein Kontingent einen bestimmten Entwickler zuzuordnen. Sie können verschiedene Variablen zur Identifizierung eines Kontingents verwenden, darunter benutzerdefinierte oder vordefinierte Variablen, beispielsweise diejenigen, die mit der Richtlinie „API-Schlüssel prüfen“ verfügbar sind. Weitere Informationen finden Sie in der Variablenreferenz.

Wenn Sie dieses Element nicht verwenden, verwendet die Richtlinie einen einzelnen Zähler, der auf das Kontingent angewendet wird.

Dieses Element wird auch im folgenden Apigee-Communitybeitrag besprochen: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<Identifier ref="verifyapikey.verify-api-key.client_id"/>
Standard:
Präsenz: Optional
Typ:

String

Attribute

Attribut Beschreibung Standard Präsenz
ref

Gibt eine Flussvariable an, mit der der Zähler identifiziert wird, der für die Anfrage verwendet wird. Die ID kann ein HTTP-Header, ein Abfrageparameter, ein Formularparameter oder der Inhalt einer Nachricht sein, der für jede Anwendung, jeden Nutzer der Anwendung, jeden App-Entwickler, jedes API-Produkt oder andere Eigenschaften eindeutig ist.

Die am häufigsten zur eindeutigen Identifizierung von Anwendungen verwendete <Identifier> ist client_id. client_id ist ein anderer Name für den API-Schlüssel oder Consumer-Schlüssel, der für eine Anwendung generiert wird, wenn sie in einer Organisation in Apigee Edge registriert wird. Sie können diese ID verwenden, wenn Sie für Ihre API die API-Schlüssel- oder OAuth-Autorisierungsrichtlinien aktiviert haben.

Unter bestimmten Umständen müssen Kontingenteinstellungen abgerufen werden, wenn kein client_id verfügbar ist, zum Beispiel wenn keine Sicherheitsrichtlinie vorhanden ist. In diesen Fällen können Sie die Access Entity-Richtlinie verwenden, um die entsprechenden API-Produkteinstellungen abzurufen. Extrahieren Sie dann mit ExtractVariables die Werte und verwenden Sie die extrahierte Kontextvariable in der Kontingentrichtlinie. Weitere Informationen finden Sie unter Access Entity-Richtlinie.

Optional

<MessageWeight>-Element

Verwenden Sie diese Option, um die pro Nachricht zugewiesene Gewichtung anzugeben. Verwenden Sie die Nachrichtengewichtung, um die Wirkung von Anfragenachrichten zu erhöhen, beispielsweise von solchen, die mehr Rechenleistung verbrauchen als andere.

Beispiel: Sie möchten, dass POST-Nachrichten doppelt so hoch sind wie "schwer". oder teuer sein, wie GET Nachrichten. Daher setzen Sie MessageWeight für POST-Anfragen auf 2 und GET. Sie können sogar MessageWeight auf 0 setzen, damit die Anfrage nicht auf den Zähler auswirken. Wenn das Kontingent in diesem Beispiel bei 10 Nachrichten pro Minute liegt und MessageWeight für POST-Anfragen 2 beträgt, dann wird das Kontingent gestattet 5 POST-Anforderungen in einem beliebigen Intervall von 10 Minuten. Jede zusätzliche Anfrage, POST oder GET, bevor die Zählerzurücksetzungen abgelehnt werden.

Ein Wert, der MessageWeight darstellt, muss durch eine Flussvariable angegeben werden und kann aus HTTP-Headern, Abfrageparametern, einer XML- oder JSON-Anfragenutzlast oder einer anderen Flussvariablen extrahiert werden. Legen Sie sie beispielsweise in einem Header mit dem Namen weight fest:

<MessageWeight ref="message_weight"/>
Standard:
Präsenz: Optional
Typ:

Integer

Ablaufvariablen

Die folgenden vordefinierten Flussvariablen beim Ausführen einer Kontingentrichtlinie automatisch ausgefüllt. Weitere Informationen zu Ablaufvariablen finden Sie in der Variablenreferenz.

Variablen Typ Berechtigungen Beschreibung
ratelimit.{policy_name}.allowed.count Long Schreibgeschützt: Gibt die zulässige Kontingentzahl zurück
ratelimit.{policy_name}.used.count Long Schreibgeschützt: Gibt das aktuell in einem Kontingentintervall verwendete Kontingent zurück
ratelimit.{policy_name}.available.count Long Schreibgeschützt: Gibt die verfügbare Kontingentzahl im Kontingentintervall zurück
ratelimit.{policy_name}.exceed.count Long Schreibgeschützt: Gibt 1 zurück, wenn das Kontingent überschritten wurde.
ratelimit.{policy_name}.total.exceed.count Long Schreibgeschützt: Gibt 1 zurück, wenn das Kontingent überschritten wurde.
ratelimit.{policy_name}.expiry.time Long Schreibgeschützt:

Gibt die UTC-Zeit in Millisekunden an, mit der festgelegt wird, wann das Kontingent abläuft und ein neues Kontingentintervall beginnt.

Wenn der Kontingentrichtlinientyp rollingwindow ist, ist dieser Wert ungültig, da das Kontingentintervall niemals abläuft.

ratelimit.{policy_name}.identifier String Schreibgeschützt: Gibt den mit der Richtlinie verknüpften (Client-)ID-Verweis zurück
ratelimit.{policy_name}.class String Schreibgeschützt: Gibt die der Client-ID zugeordnete Klasse zurück
ratelimit.{policy_name}.class.allowed.count Long Schreibgeschützt: Gibt die in der Klasse definierte zulässige Kontingentzahl zurück
ratelimit.{policy_name}.class.used.count Long Schreibgeschützt: Gibt das verwendete Kontingent innerhalb einer Klasse zurück.
ratelimit.{policy_name}.class.available.count Long Schreibgeschützt: Gibt die verfügbare Kontingentzahl in der Klasse zurück
ratelimit.{policy_name}.class.exceed.count Long Schreibgeschützt: Gibt die Anzahl der Anfragen zurück, die das Limit in der Klasse im aktuellen Kontingentintervall überschreiten.
ratelimit.{policy_name}.class.total.exceed.count Long Schreibgeschützt: Gibt die Gesamtzahl der Anfragen zurück, die das Limit in der Klasse aller Kontingentintervalle überschreiten. Es ist also die Summe von class.exceed.count für alle Kontingentintervalle.
ratelimit.{policy_name}.failed Boolesch Schreibgeschützt:

Gibt an, ob die Richtlinie fehlgeschlagen ist ("true" oder "false").

Fehlerreferenz

Dieser Abschnitt beschreibt die Fehlercodes und Fehlermeldungen, die zurückgegeben werden, und die Fehlervariablen, die von Edge festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Fehlercode HTTP-Status Ursache Beheben
policies.ratelimit.FailedToResolveQuotaIntervalReference 500 Tritt auf, wenn das <Interval>-Element nicht in der Kontingentrichtlinie definiert ist. Dieses Element ist obligatorisch und wird verwendet, um das Zeitintervall anzugeben, das für das Kontingent gilt. Das Zeitintervall kann Minuten, Stunden, Tage, Wochen oder Monate sein, wie mit dem Element <TimeUnit> definiert.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference 500 Tritt auf, wenn das <TimeUnit>-Element nicht in der Kontingentrichtlinie definiert ist. Dieses Element ist obligatorisch und wird verwendet, um die Zeiteinheit anzugeben, die für das Kontingent gilt. Das Zeitintervall kann in Minuten, Stunden, Tagen, Wochen oder Monaten angegeben werden.
policies.ratelimit.InvalidMessageWeight 500 Tritt auf, wenn der Wert des <MessageWeight>-Elements, das über eine Ablaufvariable angegeben wird, ungültig ist (ein ganzzahliger Wert).
policies.ratelimit.QuotaViolation 500 Das Kontingentlimit wurde überschritten.

Bereitstellungsfehler

Fehlername Ursache Beheben
InvalidQuotaInterval Wenn das im <Interval>-Element angegebene Kontingentintervall keine Ganzzahl ist, schlägt die Bereitstellung des API-Proxys fehl. Wenn das angegebene Kontingentintervall beispielsweise 0,1 im <Interval>-Element lautet, schlägt die Bereitstellung des API-Proxys fehl.
InvalidQuotaTimeUnit Wenn die im <TimeUnit>-Element angegebene Zeiteinheit nicht unterstützt wird, schlägt die Bereitstellung des API-Proxys fehl. Die unterstützten Zeiteinheiten sind minute, hour, day, week und month.
InvalidQuotaType Wenn der Typ des Kontingents, das im <Quota>-Attribut des type-Attribut angegeben ist, ungültig ist, dann schlägt die Bereitstellung des API-Proxys fehl. Unterstützte Kontingenttypen sind default, calendar, flexi und rollingwindow.
InvalidStartTime Wenn das im <StartTime>-Element angegebene Zeitformat ungültig ist, schlägt die Bereitstellung des API-Proxys fehl. Das gültige Format ist yyyy-MM-dd HH:mm:ss, also das Datums- und Uhrzeitformat ISO 8601. Wenn beispielsweise die im <StartTime>-Element angegebene Zeit 7-16-2017 12:00:00 lautet, schlägt die Bereitstellung des API-Proxys fehl.
StartTimeNotSupported Wenn das <StartTime>-Element angegeben ist, dessen Kontingenttyp nicht calendar ist, schlägt die Bereitstellung des API-Proxys fehl. Das <StartTime>-Element wird nur für den calendar-Kontingenttyp unterstützt. Wenn beispielsweise für das type-Attribut im <Quota>-Element der Wert flexi oder rolling window festgelegt ist, schlägt die Bereitstellung des API-Proxys fehl.
InvalidTimeUnitForDistributedQuota Ist das <Distributed>-Element auf true und das <TimeUnit>-Element auf second gesetzt, so schlägt die Bereitstellung des API-Proxys fehl. Die Zeiteinheit second ist für verteilte Kontingente unzulässig.
InvalidSynchronizeIntervalForAsyncConfiguration Ist der für das Element <SyncIntervalInSeconds> im Element <AsynchronousConfiguration> in einer Kontingentrichtlinie angegebene Wert kleiner als null, so schlägt die Bereitstellung des API-Proxys fehl.
InvalidAsynchronizeConfigurationForSynchronousQuota Ist in einer Kontingentrichtlinie, in der eine asynchrone Konfiguration mithilfe des Elements <AsynchronousConfiguration> vorhanden ist, der Wert des Elements <AsynchronousConfiguration> auf true gesetzt, so schlägt die Bereitstellung des API-Proxys fehl.

Fehlervariablen

Diese Variablen werden festgelegt, wenn die Richtlinie einen Fehler auslöst. Weitere Informationen finden sich unter Was Sie über Richtlinienfehler wissen müssen.

Variablen Wo Beispiel
fault.name="fault_name" fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. fault.name Matches "QuotaViolation"
ratelimit.policy_name.failed policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. ratelimit.QT-QuotaPolicy.failed = true

Beispiel für eine Fehlerantwort

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Beispiel für eine Fehlerregel

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>
<ph type="x-smartling-placeholder">

Schemas

Weitere Informationen

ResetQuota-Richtlinie

SpikeArrest Richtlinie

Richtlinien für Kontingente, Spike Arrest und die gleichzeitige Ratenbegrenzung vergleichen