Problèmes connus concernant Apigee

Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X
en savoir plus

Les sections suivantes décrivent les problèmes connus liés à Apigee. Dans la plupart des cas, les problèmes listés seront résolus dans une prochaine version.

Problèmes connus liés à Apigee Sense

Les sections suivantes décrivent les problèmes connus liés à Apigee Sense.

Quartier Problèmes connus
TorListRule est désactivé En raison d'un problème en cours, nous avons dû désactiver la règle de détection TorListRule. Une fois ce problème résolu et la règle réactivée, nous publierons une note de version.

Problèmes connus de divers problèmes liés à Edge

Les sections suivantes décrivent divers problèmes connus concernant Edge.

Quartier Problèmes connus
L'expiration du cache entraîne une valeur cachehit incorrecte

Lorsque la variable de flux cachehit est utilisée après la règle LookupCache, en raison de la manière dont les points de débogage sont distribués pour le comportement asynchrone, LookupPolicy renseigne l'objet DebugInfo avant l'exécution de l'appel, ce qui génère une erreur.

Solution:répétez le processus (effectuez un deuxième appel) juste après le premier appel.

La définition de la règle InvalidateCache PurgeChildEntries sur "true" ne fonctionne pas correctement

Si vous définissez PurgeChildEntries dans la règle InvalidateCache, seules les valeurs de l'élément KeyFragment seront supprimées définitivement, mais l'ensemble du cache sera effacé.

Solution:Utilisez la règle KeyValueMapOperations pour itérer la gestion des versions du cache et contourner le besoin d'invalidation du cache.

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 concernant le portail intégré

Les sections suivantes décrivent les problèmes connus liés au portail intégré.

Zone Problèmes connus
SmartDocs
  • Apigee Edge est compatible avec la spécification OpenAPI 3.0 lorsque vous créez des spécifications à l'aide de l'éditeur de spécifications et que vous publiez des API à l'aide de SmartDocs sur votre portail, bien qu'un sous-ensemble de fonctionnalités ne soit pas encore pris en charge.

    Par exemple, les fonctionnalités suivantes de la spécification OpenAPI 3.0 ne sont pas encore compatibles :

    • Propriétés allOf permettant de combiner et d'étendre des schémas
    • Références distantes

    Si une fonctionnalité non compatible est référencée dans la spécification OpenAPI, dans certains cas, les outils ignorent la fonctionnalité, mais affichent toujours la documentation de référence de l'API. Dans d'autres cas, une fonctionnalité non compatible entraînera des erreurs qui empêchent l'affichage de la documentation de référence de l'API. Dans les deux cas, vous devez modifier la spécification OpenAPI pour éviter d'utiliser la fonctionnalité non compatible jusqu'à ce qu'elle soit compatible avec une prochaine version.

    Remarque: Étant donné que l'éditeur de spécifications est moins restrictif que SmartDocs lors de l'affichage de la documentation de référence de l'API, vous pouvez constater des résultats différents entre les outils.

  • Lorsque vous utilisez cette API dans le portail, l'en-tête Accept est défini sur application/json, quelle que soit la valeur définie pour consumes dans la spécification OpenAPI.
Fournisseur d'identité SAML La déconnexion unique (SLO) avec le fournisseur d'identité SAML n'est pas acceptée pour les domaines personnalisés. Pour activer un domaine personnalisé avec un fournisseur d'identité SAML, laissez le champ URL de déconnexion vide lorsque vous configurez les paramètres SAML.
Administrateur du portail
  • Pour le moment, les mises à jour simultanées du portail (telles que les modifications de pages, de thèmes, de CSS ou de scripts) par plusieurs utilisateurs ne sont pas acceptées.
  • Si vous supprimez une page de documentation de référence de l'API à partir du portail, vous ne pouvez pas la recréer. Vous devrez supprimer et rajouter le produit d'API, puis générer à nouveau la documentation de référence de l'API.
  • Lors de la configuration de la stratégie de sécurité du contenu, l'application complète des modifications peut prendre jusqu'à 15 minutes.
  • Lorsque vous personnalisez le thème de votre portail, un délai de cinq minutes peut être nécessaire pour que les modifications soient appliquées.
Fonctionnalités du portail
  • La recherche sera intégrée au portail intégré dans une prochaine version.

Problèmes connus avec Edge pour Private Cloud

Les sections suivantes décrivent les problèmes connus liés à Edge for Private Cloud.

Quartier Problèmes connus
Faille HTTP/2 Apigee

Une faille de déni de service (DoS) a été récemment découverte dans plusieurs mises en œuvre du protocole HTTP/2 (CVE-2023-44487), y compris dans Apigee Edge pour le cloud privé. La faille pourrait entraîner une attaque DoS de la fonctionnalité de gestion des API d'Apigee. Pour en savoir plus, consultez le Bulletin de sécurité Apigee GCP-2023-032.

Les composants de routeur et de serveur de gestion Edge for Private Cloud sont exposés à Internet et peuvent être vulnérables. Bien que HTTP/2 soit activé sur le port de gestion d'autres composants spécifiques à Edge de Edge for Private Cloud, aucun de ces composants n'est exposé à Internet. Sur les composants autres que Edge, tels que Cassandra, Zookeeper ou autres, HTTP/2 n'est pas activé. Nous vous recommandons de suivre les étapes ci-dessous pour corriger la faille Edge for Private Cloud:

Suivez ces étapes si vous utilisez Edge Private Cloud version 4.51.00.11 ou ultérieure:

  1. Mettez à jour le serveur de gestion:

    1. Sur chaque nœud du serveur de gestion, ouvrez /opt/apigee/customer/application/management-server.properties.
    2. Ajoutez la ligne suivante au fichier de propriétés :
      conf_webserver_http2.enabled=false
    3. Redémarrez le composant du serveur de gestion :
      apigee-service edge-management-server restart
  2. Mettez à jour le processeur de messages:

    1. Sur chaque nœud de processeur de messages, ouvrez /opt/apigee/customer/application/message-processor.properties.
    2. Ajoutez la ligne suivante au fichier de propriétés :
      conf_webserver_http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-message-processor restart
  3. Mettez à jour le routeur:

    1. Sur chaque nœud de routeur, ouvrez /opt/apigee/customer/application/router.properties.
    2. Ajoutez la ligne suivante au fichier de propriétés :
      conf_webserver_http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-router restart
  4. Mise à jour du QPID:

    1. Sur chaque nœud QPID, ouvrez /opt/apigee/customer/application/qpid-server.properties.
    2. Ajoutez la ligne suivante au fichier de propriétés :
      conf_webserver_http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-qpid-server restart
  5. Mettez à jour Postgres:

    1. Sur chaque nœud Postgres, ouvrez /opt/apigee/customer/application/postgres-server.properties
    2. Ajoutez la ligne suivante au fichier de propriétés :
      conf_webserver_http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-postgres-server restart

Procédez comme suit si vous utilisez des versions de Edge for Private Cloud antérieures à la version 4.51.00.11:

  1. Mettez à jour le serveur de gestion:

    1. Sur chaque nœud du serveur de gestion, ouvrez /opt/apigee/customer/application/management-server.properties.
    2. Ajoutez les deux lignes suivantes au fichier de propriétés :
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Redémarrez le composant du serveur de gestion :
      apigee-service edge-management-server restart
  2. Mettez à jour le processeur de messages:

    1. Sur chaque nœud de processeur de messages, ouvrez /opt/apigee/customer/application/message-processor.properties.
    2. Ajoutez les deux lignes suivantes au fichier de propriétés :
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-message-processor restart
  3. Mettez à jour le routeur:

    1. Sur chaque nœud de routeur, ouvrez /opt/apigee/customer/application/router.properties.
    2. Ajoutez les deux lignes suivantes au fichier de propriétés :
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-router restart
  4. Mise à jour du QPID:

    1. Sur chaque nœud QPID, ouvrez /opt/apigee/customer/application/qpid-server.properties.
    2. Ajoutez les deux lignes suivantes au fichier de propriétés :
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-qpid-server restart
  5. Mettez à jour Postgres:

    1. Sur chaque nœud Postgres, ouvrez /opt/apigee/customer/application/postgres-server.properties
    2. Ajoutez les deux lignes suivantes au fichier de propriétés :
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Redémarrez le composant du processeur de messages :
      apigee-service edge-postgres-server restart
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 d'Edge for Private Cloud version 4.50 ou 4.51 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:Lors de la mise à jour d'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.

apigee-mirror sur RHEL 8.0

apigee-mirror ne fonctionne pas sur Red Hat Enterprise Linux (RHEL) 8.0.

Solution:Pour contourner ce problème, installez apigee-mirror sur un serveur exécutant une version antérieure de RHEL ou d'un autre système d'exploitation compatible avec Apigee. Vous pouvez ensuite utiliser le miroir pour ajouter des packages, même si vous avez installé Apigee sur des serveurs RHEL 8.0.

Règlement 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 génèrent des connexions à usage unique à chaque fois. Par conséquent, les connexions sont ouvertes et fermées à chaque usage pour une utilisation unique, 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 afin de définir une modification globale pour toutes les règles LDAP.

  1. S'il n'existe pas encore, créez un fichier de propriétés de configuration :
    /opt/apigee/customer/application/message-processor.properties
  2. Ajoutez les éléments suivants au fichier (remplacez les valeurs des propriétés JNDI (Java Naming and Directory Interface) en fonction de vos exigences de configuration des ressources LDAP).
    bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
    -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
    -Dcom.sun.jndi.ldap.connect.pool.initsize=2
    -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
    -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
  3. Assurez-vous que le fichier /opt/apigee/customer/application/message-processor.properties appartient à "apigee:apigee".
  4. Redémarrez chaque processeur de messages.

Pour vérifier que les propriétés JNDI de votre pool de connexions sont prises en compte, vous pouvez exécuter un test tcpdump afin d'observer le comportement du pool de connexions LDAP au fil du temps.

Délai de traitement élevé des demandes

139051927: Les latences de traitement de proxy élevées détectées dans le processeur de messages affectent tous les proxys d'API. Les symptômes sont des retards de 200 à 300 ms dans les temps de traitement par rapport aux temps de réponse normaux de l'API et peuvent se produire de manière aléatoire, même avec un faible TPS. Cela peut se produire lorsqu'un processeur de messages établit des connexions depuis plus de 50 serveurs cibles.

Cause:les processeurs de messages conservent un cache qui mappe l'URL du serveur cible à 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 qu'un grand nombre de serveurs cibles dépasse 50 au total, les URL des serveurs cibles continuent d'être évincé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 le fichier system.logs. Leur présence dans les journaux indique que les URL du serveur cible sont supprimées du cache HTTPClient, car la taille du cache est trop petite.

Solution:Pour les versions 19.01 et 19.06 de Edge for Private Cloud, vous pouvez modifier et configurer le cache HTTPClient, /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Redémarrez ensuite le processeur de messages. Effectuez 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 devrait se connecter. Définir cette propriété à une valeur supérieure n'a aucun effet secondaire, et le seul impact serait l'amélioration des temps de traitement des requêtes par proxy du processeur de messages.

Remarque:Le paramètre par défaut d'Edge for Private Cloud version 50.00 est 500.

Plusieurs entrées pour les mappages de clés-valeurs

157933959: les insertions et les mises à jour simultanées d'un même mappage de clés-valeurs (KVM) limitées au niveau de l'organisation ou de l'environnement entraînent des données incohérentes et des mises à jour perdues.

Remarque: Cette limitation s'applique uniquement à Edge for Private Cloud. Edge pour le cloud public et hybride ne présente pas cette limitation.

Pour une solution de contournement dans Edge pour Private Cloud, créez le KVM au champ d'application apiproxy.