Dépannage des problèmes de déploiement d'une stratégie de quota

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

Ce guide de dépannage vous a-t-il été utile ? N'hésitez pas à nous envoyer des commentaires.

InvalidQuotaInterval

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision_number]
Invalid quota interval [interval] in quota policy [policy_name].

Exemple de message d'erreur

Error Saving Revision 1
Invalid quota interval 0.1 in quota policy Quota-1.

Exemple de capture d'écran

Cause

Si l'intervalle de quota spécifié dans l'élément <Interval> de la règle de quota n'est pas un entier, le déploiement du proxy d'API échoue.

Par exemple, si l'intervalle de quota spécifié est de 0,1 dans l'élément <Interval> d'une règle de quota, le déploiement du proxy d'API échoue.

Diagnostic

1. Identifiez la règle de quota pour laquelle l'erreur s'est produite et l'intervalle de quota non valide. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle est Quota-1 et l'intervalle de quota non valide est de 0.1 :

   Error Saving Revision 1
   Invalid quota interval 0.1 in quota policy Quota-1.
   

2. Vérifiez que la valeur de l'intervalle de quota spécifiée dans la règle d'échec de quota correspond à la valeur identifiée dans le message d'erreur (étape 1 ci-dessus). Par exemple, la règle suivante spécifie une valeur d'intervalle de quota de 0.1, qui correspond au contenu du message d'erreur :

   <Quota async="false" continueOnError="false" enabled="true" name="Quota-1">
    <DisplayName>Quota-1</DisplayName>
    <Properties />
    <Allow count="3" />
    <Interval>0.1</Interval>
    <TimeUnit>minute</TimeUnit>
   </Quota>
   

3. Si l'intervalle de quota spécifié n'est pas un entier, il s'agit de l'origine de l'erreur.

   Dans l'exemple de règle de quota présenté ci-dessus, la valeur de l'intervalle de quota est de 0,1, qui n'est pas un entier. Par conséquent, le déploiement du proxy d'API échoue avec l'erreur suivante :

   Invalid quota interval 0.1 in quota policy Quota-1.
   

Solution

Vérifiez que la valeur de l'intervalle de quota spécifié dans l'élément <Interval> de la règle de quota est un entier. Exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-1">
    <DisplayName>Quota-1</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
</Quota>

InvalidQuotaTimeUnit

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision_number]
Invalid quota interval time unit [time_unit] in quota policy
[policy_name] in Revision [revision_number] of application
[proxy_name], in organization [org_name].

Exemple de message d'erreur

Error Saving Revision 1
Invalid quota interval time unit year in quota policy Quota-1 in Revision 1 of application Quota_test, in organization aprabhashankar-eval.

Exemple de capture d'écran

Cause

Si l'unité de temps spécifiée dans l'élément <TimeUnit> de la règle de quota n'est pas acceptée, le déploiement du proxy d'API échoue.

Les unités de temps acceptées sont minute, hour, day, week et month.

Par exemple, si l'unité de temps est spécifiée en tant que year dans l'élément <TimeUnit> de la stratégie de quota, le déploiement du proxy d'API échoue.

Diagnostic

1. Identifiez la règle de quota pour laquelle l'erreur s'est produite et l'unité de temps non valide. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle est Quota-1 et l'unité de temps non valide est year :

   Invalid quota interval time unit year in quota policy Quota-1
   in Revision 1 of application Quota_test, in organization aprabhashankar-eval.
   

2. Vérifiez que l'unité de temps spécifiée dans l'élément <TimeUnit> de la règle de quota correspond à celle identifiée dans le message d'erreur (étape 1 ci-dessus). Par exemple, la règle suivante spécifie une valeur d'intervalle de quota de year, qui correspond au contenu du message d'erreur :

   <Quota async="false" continueOnError="false" enabled="true" name="Quota-1">
    <DisplayName>Quota-1</DisplayName>
    <Properties />
    <Allow count="3" />
    <Interval>1</Interval>
    <TimeUnit>year</TimeUnit>
   </Quota>
   

3. Si l'unité de temps spécifiée dans la règle de quota n'est pas acceptée, il s'agit de la cause de l'erreur.

   Dans l'exemple de règle de quota présenté ci-dessus, l'unité de temps est spécifiée est year (non acceptée). Par conséquent, le déploiement du proxy d'API échoue avec l'erreur suivante :

   Invalid quota interval time unit year in quota policy Quota-1 in Revision 1 of application Quota_test, in organization aprabhashankar-eval.
   

Solution

Assurez-vous que l'unité de temps spécifiée dans l'élément <TimeUnit> de la règle de quota est acceptée. Exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-1">
    <DisplayName>Quota-1</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>month</TimeUnit>
</Quota>

InvalidQuotaType

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision_number]
No enum constant com.apigee.quota.types.QuotaType.[type].

Exemple de message d'erreur

Error Saving Revision 1
No enum constant com.apigee.quota.types.QuotaType.window.

Exemple de capture d'écran

Cause

Si le type de quota spécifié par l'attribut type dans l'élément <Quota> de la règle de quota n'est pas valide, le déploiement du proxy d'API échoue.

Les types de quota acceptés sont default, calendar, flexi et rollingwindow.

Par exemple, si le type de la stratégie spécifié en tant que window dans l'élément <Quota> de la règle de quota n'est pas valide, le déploiement du proxy d'API échoue.

Diagnostic

1. Identifiez le type de quota non valide utilisé dans la règle de quota. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, le type de ressource non valide est window.

   Error Saving Revision 1
   No enum constant com.apigee.quota.types.QuotaType.window.
   

2. Examinez toutes les règles de quota du proxy d'API spécifique où l'erreur s'est produite. S'il existe une règle de quota pour laquelle le type de quota spécifié dans l'élément <Quota> correspond au type non accepté identifié à l'étape 1, il s'agit de la cause de l'erreur.

   Par exemple, la stratégie suivante spécifie le type en tant que window, qui correspond au contenu du message d'erreur:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="window">
       <DisplayName>Quota-1</DisplayName>
       <Properties/>
       <Allow count="3"/>
       <Interval>1</Interval>
       <TimeUnit>minute</TimeUnit>
       <StartTime>2017-7-16 12:00:00</StartTime>
       <MessageWeight ref="messageWeight"/>
   </Quota>
   

   Étant donné que l'attribut "type" est défini sur window, ce qui n'est pas accepté, le déploiement du proxy d'API échoue avec l'erreur :

   No enum constant com.apigee.quota.types.QuotaType.window.
   

Solution

Assurez-vous que le type de quota spécifié par l'attribut type dans l'élément <Quota> de la règle de quota est accepté. Exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="rollingwindow">
    <DisplayName>Quota-1</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <StartTime>2017-7-16 12:00:00</StartTime>
    <MessageWeight ref="messageWeight"/>
</Quota>

InvalidStartTime

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision_number]
Invalid Starttime:[start_time]; Start Time should be of the format yyyy-MM-dd HH:mm:ss.

Exemple de message d'erreur

Error Saving Revision 1
Invalid Starttime:7-16-2017 12:00:00; Start Time should be of the format yyyy-MM-dd HH:mm:ss.

Exemple de capture d'écran

Cause

Si le format horaire spécifié dans l'élément <StartTime> de la règle de quota est incorrect, le déploiement du proxy d'API échoue.

Le format valide est yyyy-MM-dd HH:mm:ss. Il correspond au format d'horodatage ISO 8601.

Par exemple, si l'horodatage spécifié dans l'élément <StartTime> de la règle de quota est 7-16-2017 12:00:00, le déploiement du proxy d'API échoue.

Diagnostic

1. Indiquez l'heure de début non valide indiquée dans la règle de quota. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, l'heure de début non valide est 7-16-2017 12:00:00

   Invalid Starttime:7-16-2017 12:00:00; Start Time should be of the format yyyy-MM-dd HH:mm:ss.
   

2. Examinez toutes les règles de quota du proxy d'API spécifique où l'erreur s'est produite. Si une valeur de quota dans laquelle la valeur spécifiée dans l'élément <StartTime> correspond à l'heure de début non valide identifiée à l'étape 1 ci-dessus, alors il s'agit de la cause de l'erreur.

   Par exemple, la stratégie suivante spécifie le type en tant que 7-16-2017 12:00:00, qui correspond au contenu du message d'erreur:

   <?xml version="1.0" encoding="UTF-8"?>
   <Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="calendar">
      <DisplayName>Quota-1</DisplayName>
      <Properties />
      <Allow count="3" />
      <Interval>1</Interval>
      <TimeUnit>minute</TimeUnit>
      <StartTime>7-16-2017 12:00:00</StartTime>
   </Quota>
   

   Comme la valeur de <StartTime> est définie sur 7-16-2017 12:00:00, qui ne respecte pas le format d'horodatage requis, le déploiement du proxy d'API échoue avec l'erreur :

   Invalid Starttime:7-16-2017 12:00:00; Start Time should be of the format yyyy-MM-dd HH:mm:ss.
   

Solution

Assurez-vous que le format de l'heure de début spécifié dans l'élément <StartTime> de la règle de quota est valide et respecte le format yyyy-MM-dd HH:mm:ss requis. Exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="calendar">
    <DisplayName>Quota-1</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <StartTime>2017-7-16 12:00:00</StartTime>
</Quota>

StartTimeNotSupported

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision_number]
Starttime is not supported for quotatype [quota_type]. Starttime is supported only for calendar based type.

Exemple de message d'erreur

Error Saving Revision 1
Starttime is not supported for quotatype flexi. Starttime is supported only for calendar based type.

Exemple de capture d'écran

Cause

Si l'élément <StartTime> est spécifié dans une stratégie de quota dont le type de quota n'est pas le type agenda, le déploiement du proxy d'API échoue.

L'élément <StartTime> n'est accepté que pour le type de quota calendar.

Par exemple, si l'attribut type est défini sur flexi ou rolling window dans l'élément <Quota> de la règle de quota, le déploiement du proxy d'API échoue.

Diagnostic

1. Identifiez le type de quota spécifié dans la règle de quota ayant déclenché l'erreur. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, l'heure de début non valide est flexi

   Starttime is not supported for quotatype flexi. Starttime is
   supported only for calendar based type.
   

2. Examinez toutes les règles de quota du proxy d'API spécifique où l'erreur s'est produite. S'il existe une règle relative au quota dans laquelle l'attribut "type" correspond au type de quota identifié à l'étape 1 ci-dessus et si l'élément <StartTime> est spécifié, alors il s'agit de la cause de l'erreur.

   Par exemple, la règle suivante spécifie le type de quota flexi, qui correspond au contenu du message d'erreur et spécifie également l'élément <StartTime> :

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="flexi">
       <DisplayName>Quota-1</DisplayName>
       <Properties/>
       <Allow count="3"/>
       <Interval>1</Interval>
       <TimeUnit>minute</TimeUnit>
       <StartTime>2017-7-16 12:00:00</StartTime>
   </Quota>
   

   Comme l'élément <StartTime> est spécifié dans la règle de quota dont le type de quota est défini sur flexi, le déploiement du proxy d'API échoue avec l'erreur :

   Starttime is not supported for quotatype flexi. Starttime is supported only for calendar based type.
   

Solution

Vérifiez que l'élément <StartTime> n'est pas spécifié lorsque le type de quota indiqué par l'attribut type dans l'élément <Quota> est flexi ou rolling window. Exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="flexi">
    <DisplayName>Quota-1</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
</Quota>

InvalidTimeUnitForDistributedQuota

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision number]
Invalid timeunit second for distributed quota.

Exemple de message d'erreur

Error Saving Revision 1
Invalid timeunit second for distributed quota.

Exemple de capture d'écran

Cause

Si l'élément <Distributed> est défini sur true, et l'élément <TimeUnit> sur second, le déploiement du proxy d'API échoue. L'unité de temps second n'est pas valide pour un quota distribué.

Lorsque l'élément Distributed est défini sur true, la règle doit conserver un compteur central et le synchroniser en continu sur tous les processeurs de messages. Par conséquent, il serait difficile d'assurer la synchronisation tout en vérifiant que le nombre de requêtes n'a pas dépassé le quota spécifié dans un intervalle de temps court, par exemple un intervalle défini en secondes. Pour cette raison, l'unité de temps second est considérée comme non valide pour le quota distribué.

Diagnostic

Examinez toutes les règles de quota du proxy d'API spécifique où l'erreur s'est produite. S'il existe une règle de quota avec un élément <TimeUnit> défini sur second et que l'élément <Distributed> est défini sur true, il s'agit de la cause de l'erreur.

Par exemple, la règle ci-dessous comporte un élément <TimeUnit> défini sur second, et l'élément <Distributed> est défini sur true.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="CheckQuota" type="calendar">
    <DisplayName>CheckQuota</DisplayName>
    <Properties/>
    <Allow count="30"/>
    <Interval>1</Interval>
    <TimeUnit>second</TimeUnit>
    <StartTime>2018-8-05 12:00:00</StartTime>
    <Distributed>true</Distributed>
    <Synchronous>false</Synchronous>
</Quota>

Solution

Assurez-vous que l'élément <TimeUnit> n'est jamais défini sur second lorsque l'élément <Distributed> est défini sur "true". L'élément <TimeUnit> peut être défini sur toutes les autres valeurs autorisées : minute, hour, day, week, ou month. Exemple :

<Quota async="false" continueOnError="false" enabled="true" name="CheckQuota" type="calendar">
    <DisplayName>CheckQuota</DisplayName>
    <Properties/>
    <Allow count="30"/>
    <Interval>1</Interval>
    <TimeUnit>hour</TimeUnit>
    <StartTime>2018-8-05 12:00:00</StartTime>
    <Distributed>true</Distributed>
    <Synchronous>false</Synchronous>
</Quota>

InvalidSynchronizeIntervalForAsyncConfiguration

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision number]
SyncIntervalInSeconds should be a value greater than zero.

Exemple de message d'erreur

Error Saving Revision 1
SyncIntervalInSeconds should be a value greater than zero.

Exemple de capture d'écran

Cause

Si la valeur spécifiée pour l'élément <SyncIntervalInSeconds> au sein de l'élément <AsynchronousConfiguration> d'une règle de quota est inférieure à zéro, le déploiement du proxy d'API échoue.

Diagnostic

Examinez toutes les règles de quota du proxy d'API spécifique où l'erreur s'est produite. S'il existe une règle de quota pour laquelle l'élément <SyncIntervalInSeconds> est défini sur une valeur inférieure à zéro dans l'élément <AsynchronousConfiguration>, alors il s'agit de la cause de l'erreur.

Par exemple, l'élément <SyncIntervalInSeconds> de la règle ci-dessous est défini sur une valeur négative.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota_AsyncConfig" type="calendar">
    <DisplayName>Quota_AsyncConfig</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <StartTime>2017-7-16 12:00:00</StartTime>
    <Distributed>true</Distributed>
    <Synchronous>false</Synchronous>
    <AsynchronousConfiguration>
        <SyncIntervalInSeconds>-1</SyncIntervalInSeconds>
    </AsynchronousConfiguration>
</Quota>

Solution

Assurez-vous de toujours spécifier un entier positif pour l'élément <SyncIntervalInSeconds> dans l'élément <AsynchronousConfiguration> d'une règle de quota. Exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota_AsyncConfig" type="calendar">
    <DisplayName>Quota_AsyncConfig</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <StartTime>2017-7-16 12:00:00</StartTime>
    <Distributed>true</Distributed>
    <Synchronous>false</Synchronous>
    <AsynchronousConfiguration>
        <SyncIntervalInSeconds>5</SyncIntervalInSeconds>
    </AsynchronousConfiguration>
</Quota>

InvalidAsynchronizeConfigurationForSynchronousQuota

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision [revision number]
AsynchronousConfiguration is not valid for synchronous quota.

Exemple de message d'erreur

Error Saving Revision 2
AsynchronousConfiguration is not valid for synchronous quota.

Exemple de capture d'écran

Cause

Si la valeur de l'élément <Synchronous> est définie sur true dans une règle de quota, qui possède également une configuration asynchrone définie à l'aide de l'élément <AsynchronousConfiguration>, le déploiement du proxy d'API échoue.

Diagnostic

Examinez toutes les règles de quota du proxy d'API spécifique où l'erreur s'est produite. S'il existe une règle relative au quota pour laquelle l'élément <Synchronous> est défini sur true et qu'il comporte également un élément <AsynchronousConfiguration> défini, il s'agit de la cause de l'erreur.

Par exemple, la règle ci-dessous possède un élément <Synchronous> défini sur true ainsi qu'un élément <AsynchronousConfiguration> défini :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota_AsyncConfig" type="calendar">
    <DisplayName>Quota_AsyncConfig</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <StartTime>2017-7-16 12:00:00</StartTime>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <AsynchronousConfiguration>
     <SyncIntervalInSeconds>1</SyncIntervalInSeconds>
    </AsynchronousConfiguration>
</Quota>

Solution

Assurez-vous qu'aucune configuration asynchrone n'est définie à l'aide de l'élément <AsynchronousConfiguration> si l'élément <Synchronous> est défini sur true dans une règle de quota.

Vous pouvez corriger l'exemple ci-dessus en supprimant la section <AsynchronousConfiguration>, comme illustré ci-dessous :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota_AsyncConfig" type="calendar">
    <DisplayName>Quota_AsyncConfig</DisplayName>
    <Properties/>
    <Allow count="3"/>
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <StartTime>2017-7-16 12:00:00</StartTime>
    <Distributed>true</Distributed>
 <Synchronous>true</Synchronous>
</Quota>