Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info
Les sections suivantes décrivent les problèmes connus liés à Apigee. Dans la plupart des cas, les problèmes répertoriés seront résolus dans une prochaine version.
Divers problèmes connus avec Edge
Les sections suivantes décrivent divers problèmes connus liés à Edge.
| Zone | Problèmes connus |
|---|---|
L'expiration du cache entraîne une valeur cachehit incorrecte |
Lorsque la variable de flux Solution:répétez la procédure (passez un deuxième appel) juste après le premier appel. |
Définir la règle InvalidateCache PurgeChildEntries sur "true" ne fonctionne pas correctement |
Définir Solution de contournement:utilisez la règle KeyValueMapOperations pour itérer la gestion des versions du cache et éviter d'avoir à invalider le cache. |
| Les requêtes de déploiement simultanés pour un flux SharedFlow ou un proxy d'API peuvent entraîner un état incohérent sur le serveur de gestion, où plusieurs révisions sont affichées comme étant déployées. |
Cela peut se produire, par exemple, en cas d'exécutions simultanées d'un pipeline de déploiement CI/CD qui exploitent des révisions différentes. Pour éviter ce problème, évitez de déployer des proxys d'API ou des flux SharedFlow avant la fin du déploiement actuel. Solution:Évitez les déploiements simultanés de proxys d'API ou de flux SharedFlow. |
Problèmes connus avec l'interface utilisateur Edge
Les sections suivantes décrivent les problèmes connus liés à l'interface utilisateur Edge.
| Zone | Problèmes connus |
|---|---|
| Impossible d'accéder à la page d'administration de la zone d'authentification unique Edge à partir de la barre de navigation une fois l'organisation associée à une zone d'identité | Lorsque vous connectez une organisation à une zone d'identité, vous ne pouvez plus accéder à la page Administration des zones d'authentification unique d'Edge dans la barre de navigation de gauche en sélectionnant Administrateur > Authentification unique. Pour contourner ce problème, accédez directement à la page à l'aide de l'URL suivante: https://apigee.com/sso. |
Problèmes connus liés au portail intégré
Les sections suivantes décrivent les problèmes connus liés au portail intégré.
| Zone | Problèmes connus |
|---|---|
| SmartDocs |
|
| Fournisseur d'identité SAML | La déconnexion unique (SLO) avec le fournisseur d'identité SAML n'est pas disponible pour les domaines personnalisés. Pour activer un domaine personnalisé avec un fournisseur d'identité SAML, laissez le champ Sign-out URL (URL de déconnexion) vide lorsque vous configurez les paramètres SAML. |
| Administrateur de portail |
|
| Fonctionnalités du portail |
|
Problèmes connus avec Edge pour le cloud privé
Les sections suivantes décrivent les problèmes connus liés à Edge pour le cloud privé.
| Zone | Problèmes connus |
|---|
| Edge pour le cloud privé 4.52.02 et 4.53.00 |
Lorsque vous utilisez la règle SetOauthV2Info, si l'AccessToken ne peut pas être résolu en une variable ou s'il est nul, la règle génère une erreur de datastore: {
"fault": {
"faultstring": "Error while accessing datastore;Please retry later",
"detail": {
"errorcode": "datastore.ErrorWhileAccessingDataStore"
}
}
}
Ce comportement diffère des versions antérieures d'Apigee, où un tel scénario déclenchait une erreur {
"fault": {
"faultstring": "Invalid Access Token",
"detail": {
"errorcode": "keymanagement.service.invalid_access_token"
}
}
}
Pour y remédier, ajoutez une règle RaiseFault à votre proxy afin de simuler l'ancien message d'erreur. Cette règle RaiseFault peut être exécutée lorsque la variable de jeton d'accès est nulle. Référez-vous à l'exemple ci-dessous : <!-- Sample Raise Fault Policy ---> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault-MissingAccessToken"> <DisplayName>RaiseFault-MissingAccessToken</DisplayName> <Properties/> <FaultResponse> <Set> <Headers/> <Payload contentType="application/json">{"fault":{"faultstring":"Invalid Access Token","detail":{"errorcode":"keymanagement.service.invalid_access_token"}}}</Payload> <StatusCode>500</StatusCode> <ReasonPhrase>Internal Server Error</ReasonPhrase> </Set> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault> La règle RaiseFault peut être ajoutée de manière conditionnelle avant la règle SetOauthV2Info dans votre flux de proxy, comme illustré dans l'exemple ci-dessous:
<Step> <!-- Execute RaiseFault policy if access_token flow variable is null --> <Condition>access_token = null</Condition> <Name>RaiseFault-MissingAccessToken</Name> </Step> <Step> <!-- Execute SetOAuthV2Info policy if access_token flow variable is null --> <Condition>access_token != null</Condition> <Name>SetOAuthV2Info</Name> </Step> Apigee publiera un correctif pour restaurer le comportement mentionné ci-dessus pour les versions Edge pour Private Cloud 4.52.02 et 4.53.00. |
| Mise à jour d'Edge pour le cloud privé 4.52.02 |
Lorsque vous passez de la version 4.51.00, 4.52.00 ou 4.52.01 à la version 4.52.02 d'Edge pour Private Cloud, vous devez vous attendre à un impact supplémentaire sur les API d'exécution et de gestion. Cet impact se produit après la mise à jour des nœuds Cassandra et dure jusqu'à ce que tous les nœuds du processeur de messages et du serveur de gestion soient mis à jour. Dans ce cas, vous devez vous attendre à un impact dans l'un des domaines suivants:
Apigee publiera une documentation de mise à jour révisée pour Edge for Private Cloud 4.52.02 qui résoudra ce problème. |
| Mise à jour de Mint pour Edge pour le cloud privé 4.52.01 |
Ce problème ne concerne que les utilisateurs qui utilisent MINT ou qui l'ont activé dans les installations Edge pour le cloud privé. Composant concerné:edge-message-processor Problème:si la monétisation est activée et que vous installez la version 4.52.01 en tant que nouvelle installation ou que vous effectuez une mise à niveau à partir de versions précédentes du cloud privé, vous rencontrerez un problème avec les processeurs de messages. Le nombre de threads ouverts augmente progressivement, ce qui entraîne l'épuisement des ressources. L'exception suivante s'affiche dans le fichier system.log du processeur de messages Edge: Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread |
| Vulnérabilité HTTP/2 d'Apigee | Une faille par déni de service (DoS) a récemment été détectée dans plusieurs implémentations du protocole HTTP/2 (CVE-2023-44487), y compris dans Apigee Edge pour le cloud privé. La faille pourrait entraîner un déni de service de la fonctionnalité de gestion d'API Apigee. Pour en savoir plus, consultez le bulletin de sécurité Apigee GCP-2023-032. Les composants du routeur et du serveur de gestion Edge for Private Cloud sont exposés sur Internet et peuvent être vulnérables. Bien que HTTP/2 soit activé sur le port de gestion d'autres composants propres à Edge de Edge pour Private Cloud, aucun de ces composants n'est exposé à Internet. Sur les composants autres que Edge, tels que Cassandra, Zookeeper et d'autres, HTTP/2 n'est pas activé. Nous vous recommandons de suivre la procédure ci-dessous pour résoudre la faille Edge pour le cloud privé:
Suivez cette procédure si vous utilisez Edge Private Cloud version 4.51.00.11 ou ultérieure:
Suivez cette procédure si vous utilisez des versions d'Edge pour le cloud privé antérieures à 4.51.00.11:
|
| Mise à niveau de Postgresql lors de la mise à jour vers la version 4.52 | Apigee-postgresql rencontre des problèmes lors de la mise à niveau de la version 4.50 ou 4.51 d'Edge pour un cloud privé vers la version 4.52. Les problèmes surviennent principalement lorsque le nombre de tables est supérieur à 500. Vous pouvez vérifier le nombre total de tables dans Postgres en exécutant la requête SQL ci-dessous: select count(*) from information_schema.tables Solution de contournement:Lorsque vous mettez à niveau Apigee Edge 4.50.00 ou 4.51.00 vers la version 4.52.00, veillez à effectuer l' étape préliminaire avant de mettre à niveau Apigee-postgresql. |
| Règle LDAP | 149245401: les paramètres du pool de connexions LDAP pour JNDI configurés via la ressource LDAP ne sont pas reflétés, et les valeurs par défaut de JNDI entraînent des connexions à usage unique à chaque fois. Par conséquent, les connexions sont ouvertes et fermées à chaque fois pour une seule utilisation, ce qui crée un grand nombre de connexions par heure au serveur LDAP. Solution : Pour modifier les propriétés du pool de connexions LDAP, procédez comme suit pour définir une modification globale pour toutes les règles LDAP.
Pour vérifier que les propriétés JNDI de votre pool de connexions prennent effet, vous pouvez effectuer un tcpdump pour observer le comportement du pool de connexions LDAP au fil du temps. |
| Latence de traitement des requêtes élevée | 139051927: Les latences de traitement des proxys élevées détectées dans le processeur de messages affectent tous les proxys d'API. Les symptômes incluent des délais de traitement de 200 à 300 ms par rapport aux temps de réponse normaux de l'API et peuvent se produire de manière aléatoire, même avec un TPS faible. Cela peut se produire lorsque plus de 50 serveurs cibles sont connectés à un processeur de messages. Cause du problème:les processeurs de messages conservent un cache qui met en correspondance l'URL du serveur cible avec l'objet HTTPClient pour les connexions sortantes vers les serveurs cibles. Par défaut, ce paramètre est défini sur 50, ce qui peut être trop faible pour la plupart des déploiements. Lorsqu'un déploiement comporte plusieurs combinaisons org/env dans une configuration et un grand nombre de serveurs cibles dépassant 50 au total, les URL des serveurs cibles sont constamment supprimées du cache, ce qui entraîne des latences. Validation:pour déterminer si l'éviction de l'URL du serveur cible est à l'origine du problème de latence, recherchez le mot clé "onEvict" ou "Eviction" dans les journaux système du processeur de messages. Leur présence dans les journaux indique que les URL de serveur cible sont supprimées du cache HTTPClient, car la taille du cache est trop faible. Solution de contournement:pour les versions 19.01 et 19.06 d'Edge pour le cloud privé, vous pouvez modifier et configurer le cache HTTPClient, conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Redémarrez ensuite le processeur de messages. Apportez les mêmes modifications pour tous les processeurs de messages. La valeur 500 en est un exemple. La valeur optimale pour votre configuration doit être supérieure au nombre de serveurs cibles auxquels le processeur de messages se connecterait. Le fait de définir cette propriété sur une valeur plus élevée n'a aucun effet secondaire. Le seul impact est une amélioration des délais de traitement des requêtes de proxy du processeur de messages.
Remarque:La valeur par défaut de la version 50.00 d'Edge pour le cloud privé est 500. |
| Plusieurs enregistrements pour les mappages clé-valeur | 157933959: Les insertions et mises à jour simultanées d'un même mappage clé-valeur (KVM) défini au niveau de l'organisation ou de l'environnement entraînent des données incohérentes et des mises à jour perdues. Remarque:Cette limite ne s'applique qu'à Edge pour le cloud privé. Edge for Public Cloud et Hybrid ne sont pas soumis à cette limitation. Pour contourner le problème dans Edge pour le cloud privé, créez le KVM au niveau de l'étendue |