<ph type="x-smartling-placeholder"></ph>
Vous consultez la documentation Apigee Edge.
Accédez à la page
Documentation sur Apigee X. En savoir plus
InvalidTimeout
Message d'erreur
Le déploiement du proxy d'API via l'interface utilisateur Edge ou l'API de gestion Edge échoue avec ce message d'erreur:
Error Saving Revision revision_number CacheLookupTimeoutInSeconds value value should be greater than zero.
Exemple de message d'erreur
Error Saving Revision 2
CacheLookupTimeoutInSeconds -1 value should be greater than zero.
Exemple de capture d'écran d'erreur
Cause
Si l'élément <CacheLookupTimeoutInSeconds>
d'une règle ResponseCache est défini sur un nombre négatif, le déploiement du proxy d'API échoue.
Par exemple, si <CacheLookupTimeoutInSeconds>
équivaut à -1
, le déploiement du proxy d'API échoue.
Diagnostic
Identifiez la valeur non valide utilisée pour l'élément
<CacheLookupTimeoutInSeconds>
dans la règle ResponseCache. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, la valeur non valide utilisée pour l'élément<CacheLookupTimeoutInSeconds>
est-1
:CacheLookupTimeoutInSeconds -1 value should be greater than zero.
Examinez toutes les règles ResponseCache dans le proxy d'API spécifique où l'échec a eu lieu. Une ou plusieurs règles ResponseCache peuvent être spécifiées dans l'élément
<CacheLookupTimeoutInSeconds>
.Par exemple, la configuration de règle suivante définit
<CacheLookupTimeoutInSeconds>
sur-1
, qui correspond au contenu du message d'erreur :<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1"> <DisplayName>Response Cache-1</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" type="string"/> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSec ref="">3600</TimeoutInSec> </ExpirySettings> <CacheLookupTimeoutInSeconds>-1</CacheLookupTimeoutInSeconds> </ResponseCache>
Si la valeur de
<CacheLookupTimeoutInSeconds>
est spécifiée sous forme d'un entier négatif, alors il s'agit de la cause de l'erreur.
Solution
Vérifiez que la valeur de l'élément <CacheLookupTimeoutInSeconds>
de la règle ResponseCache est toujours spécifiée sous la forme d'un entier non négatif.
Pour corriger l'exemple de règle ResponseCache présenté ci-dessus, vous pouvez modifier la valeur <CacheLookupTimeoutInSeconds> element
en 30
.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
<DisplayName>Response Cache-1</DisplayName>
<Properties/>
<CacheKey>
<Prefix/>
<KeyFragment ref="request.uri" type="string"/>
</CacheKey>
<Scope>Exclusive</Scope>
<ExpirySettings>
<ExpiryDate/>
<TimeOfDay/>
<TimeoutInSec ref="">3600</TimeoutInSec>
</ExpirySettings>
<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>
</ResponseCache>
InvalidCacheResourceReference
Message d'erreur
Le déploiement du proxy d'API via l'interface utilisateur Edge ou l'API de gestion Edge échoue avec ce message d'erreur:
Error Deploying Revision revision_number to environment Invalid cache resource reference cache_resource in Step definition response_cache_policy_name. Context Revision:revision_number;APIProxy:ResponseCache;Organization:organization;Environment:environment
Exemple de message d'erreur
Error Deploying Revision 2 to prod
Invalid cache resource reference itemscache in Step definition ItemsResponseCache. Context Revision:2;APIProxy:StoresInventory;Organization:kkalckstein-eval;Environment:prod
Exemple de capture d'écran d'erreur
Cause
Cette erreur se produit si l'élément <CacheResource>
d'une règle ResponseCache est défini sur un nom qui n'existe pas dans l'environnement où le proxy d'API est déployé.
Diagnostic
Identifiez le cache non valide utilisé dans l'élément
<CacheResource>
de la règle ResponseCache et l'environnement où l'erreur s'est produite. Ces deux éléments se trouvent dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom du cache non valide estitemscache
et le nom de l'environnement estprod
.Invalid cache resource reference itemscache in Step definition ItemsResponseCache. Context Revision:2;APIProxy:StoresInventory;Organization:kkalckstein-eval;Environment:prod
Examinez toutes les règles ResponseCache dans le proxy d'API spécifique où l'échec a eu lieu. Identifiez la règle ResponseCache spécifique dans laquelle le cache non valide (identifié à l'étape 1) est spécifié dans l'élément
<CacheResource>
.Par exemple, la règle suivante spécifie la valeur de
<CacheResource>
commeitemscache
, qui correspond au contenu du message d'erreur:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="ItemsResponseCache"> <DisplayName>ItemsResponseCache</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" type="string"/> </CacheKey> <CacheResource>itemscache</CacheResource> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSec ref="">3600</TimeoutInSec> </ExpirySettings> <SkipCacheLookup/> <SkipCachePopulation/> </ResponseCache>
Vérifiez si le cache (déterminé à l'étape 2) a été défini dans l'environnement spécifique (identifié à l'étape 1).
Dans l'interface utilisateur Edge, accédez à APIs > Configuration de l'environnement et vérifiez si le cache existe dans l'onglet Caches de l'environnement concerné. Si le cache n'existe pas, il s'agit de la cause de l'erreur.
Par exemple, dans la capture d'écran ci-dessous, notez que le cache nommé
itemscache
n'existe pas.Étant donné que le cache
itemscache
n'est pas défini dans l'environnementprod
, vous obtenez l'erreur suivante :Invalid cache resource reference does_not_exist in Step definition Response-Cache-1. Context Revision:2;APIProxy:ResponseCache;Organization:kkalckstein-eval;Environment:prod
Solution
Vérifiez que le nom de cache spécifié dans l'élément <CacheResource>
a été créé dans l'environnement dans lequel vous souhaitez déployer le proxy d'API.
Consultez la section Créer et modifier un cache d'environnement pour savoir comment créer le cache.
ResponseCacheStepAttachmentNotAllowedReq
Message d'erreur
Le déploiement du proxy d'API via l'interface utilisateur Edge ou l'API de gestion Edge échoue avec ce message d'erreur:
Error Deploying Revision revision_number to environment Response cache step definition response_cache_policy_name can not be attached more than once in the request path.
Exemple de message d'erreur
Error Deploying Revision 2 to test
Response cache step definition Response-Cache-1 can not be attached more than once in the request path.
Exemple de capture d'écran d'erreur
Cause
Cette erreur se produit si la même règle ResponseCache est associée à plusieurs chemins de requête dans tous les flux d'un proxy d'API.
Par exemple, cette erreur se produit si vous avez associé la même règle ResponseCache au Preflow de requête des points de terminaison du proxy et des points de terminaison cibles.
Diagnostic
Identifiez le nom de la règle ResponseCache associée plusieurs fois. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle ResponseCache est Response‐Cache‐1.
Error Deploying Revision 2 to test Response cache step definition Response-Cache-1 can not be attached more than once in the request path.
Examinez tous les flux de requêtes dans les points de terminaison du proxy et les points de terminaison cibles du proxy d'API où l'erreur s'est produite. Si la même règle ResponseCache est associée dans deux flux de requêtes ou plus, il s'agit de la cause de l'erreur.
Dans l'exemple suivant, la même règle ResponseCache
Response-Cache-1
est configurée dans le chemin de requête du point de terminaison du proxy par défaut PreFlow et du point de terminaison cible par défaut PreFlow :<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request> <Step> <Name>Response-Cache-1</Name> </Step> </Request> ... <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <TargetEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request> <Step> <Name>Response-Cache-1</Name> </Step> </Request> ...
Solution
Vérifiez qu'une règle ResponseCache est associée à un seul chemin de requête pour tous les flux du proxy d'API.
Pour corriger l'exemple présenté ci-dessus, supprimez la règle ResponseCache Response-Cache-1
de l'un des deux flux de requêtes.
ResponseCacheStepAttachmentNotAllowedResp
Message d'erreur
Le déploiement du proxy d'API via l'interface utilisateur Edge ou l'API de gestion Edge échoue avec ce message d'erreur:
Error Deploying Revision revision_number to environment Response cache step definition response_cache_policy_name can not be attached more than once in the response path.
Exemple de message d'erreur
Error Deploying Revision 2 to test
Response cache step definition Response-Cache-1 can not be attached more than once in the response path.
Exemple de capture d'écran d'erreur
Cause
Cette erreur se produit si la même règle ResponseCache est associée à plusieurs chemins de réponse dans les flux d'un proxy d'API.
Par exemple, cette erreur se produit si vous avez associé la même règle ResponseCache au Preflow de réponse des points de terminaison du proxy et des points de terminaison cibles.
Diagnostic
Identifiez le nom de la règle ResponseCache associée plusieurs fois. Vous trouverez cette information dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle ResponseCache est
Response-Cache-1
.Error Deploying Revision 2 to test Response cache step definition Response-Cache-1 can not be attached more than once in the response path.
Examinez tous les flux de requêtes dans les points de terminaison du proxy et les points de terminaison cibles du proxy d'API où l'erreur s'est produite. Si la même règle ResponseCache est associée dans deux flux de réponse ou plus, il s'agit de la cause de l'erreur.
Dans l'exemple suivant, la même règle ResponseCache
Response-Cache-1
est configurée dans le chemin de réponse du point de terminaison du proxy par défaut PreFlow et du point de terminaison cible par défaut PreFlow :<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request> <Step> <Name>Response-Cache</Name> </Step> </Request> <Response> <Step> <Name>Response-Cache-1</Name> </Step> </Response> </PreFlow> ... <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <TargetEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response> <Step> <Name>Response-Cache-1</Name> </Step> </Response> </PostFlow> ...
Solution
Vérifiez qu'une règle ResponseCache est associée à un seul chemin de réponse pour tous les flux du proxy d'API.
Pour corriger l'exemple présenté ci-dessus, supprimez la règle ResponseCache Response-Cache-1
de l'un des deux chemins de réponse.
InvalidMessagePatternForErrorCode
Message d'erreur
Le déploiement du proxy d'API via l'interface utilisateur Edge ou l'API de gestion Edge échoue avec l'un des messages d'erreur suivants:
Error Deploying Revision revision_number to environment Invalid message pattern found for error code steps.cache.InvalidSkipCacheLookUpCondition.
OU
Error Deploying Revision revision_number to environment Invalid message pattern found for error code steps.cache.InvalidSkipCachePopulationCondition.
Exemple de message d'erreur
Error Deploying Revision 2 to prod
Invalid message pattern found for error code steps.cache.InvalidSkipCacheLookUpCondition.
OU
Error Deploying Revision 2 to prod
Invalid message pattern found for error code steps.cache.InvalidSkipCachePopulationCondition.
Capture d'écran du message d'erreur
OU
Cause
Cette erreur se produit si l'élément <SkipCacheLookup>
ou <SkipCachePopulation>
d'une règle ResponseCache comprend une condition non valide.
Diagnostic
Examinez toutes les règles ResponseCache dans le proxy d'API où l'erreur s'est produite et vérifiez si des règles ont des conditions spécifiées pour
<SkipCacheLookup>
et/ou les éléments<SkipCachePopulation>
.Vérifiez si la condition spécifiée pour l'élément
<SkipCacheLookup>
et/ou l'élément<SkipCachePopulation>
est non valide. Si c'est le cas, alors il s'agit de la cause de l'erreur.Dans l'exemple suivant, l'élément
<SkipCachePopulation>
utilise l'opérateur JavaScript === pour rechercher la même valeur et le même type non valides.<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1"> <DisplayName>Response Cache-1</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" type="string"/> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSec ref="">3600</TimeoutInSec> </ExpirySettings> <CacheLookupTimeoutInSeconds>2</CacheLookupTimeoutInSeconds> <SkipCacheLookup>request.header.bypass-cache === "true"</SkipCacheLookup> </ResponseCache>
Étant donné que l'opérateur
===
est non valide, l'erreur suivante s'affiche :Invalid message pattern found for error code steps.cache.InvalidSkipCacheLookUpCondition.
Solution
Vérifiez que la condition spécifiée pour les éléments <SkipCacheLookup>
et/ou <SkipCachePopulation>
est toujours valide.
Pour corriger l'exemple de la règle ResponseCache présenté ci-dessus, vous pouvez modifier <SkipCacheLookup>
pour utiliser l'opérateur =
:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
<DisplayName>Response Cache-1</DisplayName>
<Properties/>
<CacheKey>
<Prefix/>
<KeyFragment ref="request.uri" type="string"/>
</CacheKey>
<Scope>Exclusive</Scope>
<ExpirySettings>
<ExpiryDate/>
<TimeOfDay/>
<TimeoutInSec ref="">3600</TimeoutInSec>
</ExpirySettings>
<CacheLookupTimeoutInSeconds>2</CacheLookupTimeoutInSeconds>
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
</ResponseCache>
CacheNotFound
Message d'erreur
Le déploiement du proxy d'API via l'interface utilisateur Edge ou l'API de gestion Edge entraîne un message d'erreur comme celui-ci et l'état de déploiement du proxy d'API est marqué comme partiellement déployé:
Error: Cache : cache_resource, not found in organization : organization__environment.
Exemple de message d'erreur
Error Cache : Response-Cache-1, not found in organization : kkalckstein-eval__prod
Cause
Cette erreur se produit si le cache spécifique mentionné dans le message d'erreur n'a pas été créé sur un composant du processeur de message spécifique.
Solution
Si vous êtes un utilisateur du cloud privé, suivez les instructions ci-dessous:
Répertoriez les déploiements de proxy d'API et identifiez les processeurs de messages qui présentent l'erreur
steps.cache.CacheNotFound
.Exemple de résultat
curl -u $USERID:$USERPASSWORD http://<management-server-host>:8080/v1/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/deployments { "aPIProxy" : "ResponseCache", "environment" : [ { "configuration" : { "basePath" : "/", "configVersion" : "SHA-512:45d3f39783414d3859bf2dec4135d8f5f9960ee6b2d361db2799c82693a8e3f8b95dbbb37c547eb3c0a3819d8ca51727f390502bcaefdf1f113263521a9023b6", "steps" : [ ] }, "name" : "prod", "server" : [ { "pod" : { "name" : "pod1", "region" : "us-central1" }, "status" : "deployed", "type" : [ "message-processor" ], "uUID" : "f2e5e34a-5630-43a9-8fef-48a5b9da76d1" }, { "pod" : { "name" : "pod1", "region" : "us-central1" }, "status" : "deployed", "type" : [ "message-processor" ], "uUID" : "879a6538-a5e0-4503-b142-9cb2b4e0623d" }, { "error" : "Cache : Response-Cache-1, not found in organization : kkalckstein-eval__prod", "errorCode" : "steps.cache.CacheNotFound", "status" : "error", "type" : [ "message-processor" ], "uUID" : "a8f9ce0b-c32d-48a9-b26c-9c75d8bf467d" }, ... "state" : "deployed" } ], "name" : "2", "organization" : "kkalckstein-eval"
Notez le ou les UUID du processeur de messages dans lequel vous observez l'erreur
steps.cache.CacheNotFound
. Identifiez le nom d'hôte ou l'adresse IP du processeur de messages à partir de l'UUID.Connectez-vous au processeur de messages spécifique et redémarrez-le à l'aide de la commande suivante:
apigee-service edge-message-processor restart
Si vous utilisez un cloud public ou si le problème persiste pour le cloud privé, contactez l'assistance Apigee pour obtenir de l'aide.