Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

4.17.01 - Notes de version d'Edge for Private Cloud

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Le mercredi 25 janvier 2017, nous avons lancé une nouvelle version d'Apigee Edge for Private Cloud.

Depuis la précédente version de fonctionnalité d'Edge for Private Cloud, les versions suivantes ont été publiées et sont incluses dans cette version de fonctionnalité :

Cloud : 16.08.24.01 (UI), 16.10.05 (UI), 16.09.21, 16.09.21_9, 16.10.26 (UI)

Consultez À propos de la numérotation des versions pour savoir comment déterminer si une version cloud spécifique est incluse dans votre version d'Edge for Private Cloud.

Présentation de la version

Cette version inclut un certain nombre de fonctionnalités notables qui vous aident à mieux contrôler et sécuriser vos API.

Les flux partagés et les hooks de flux vous permettent de créer un ensemble réutilisable de règles et de comportements sur plusieurs proxys d'API.

Les mappages clé-valeur (KVM), qui étaient déjà une fonctionnalité d'Edge pour la persistance à long terme des paires clé-valeur, peuvent désormais être chiffrés pour renforcer la sécurité des données.

Pour un contrôle plus flexible de l'accès des développeurs à vos API, l'interface utilisateur de gestion Edge offre davantage d'options pour créer et gérer des clés API et des secrets (identifiants), révoquer des applications de développeur et désactiver des développeurs. Ces améliorations vous permettent d'implémenter plus facilement des stratégies telles que la rotation des clés API et de désactiver plusieurs clés API en révoquant une application de développeur (toutes ses clés sont désactivées) ou en désactivant un développeur (toutes les applications et clés du développeur sont désactivées).

En ce qui concerne les fonctionnalités obsolètes, la fonctionnalité "Limites de monétisation" a été supprimée.

Le reste de cette rubrique contient des détails sur toutes les nouvelles fonctionnalités, les mises à jour et les corrections de bugs incluses dans la version.

Abandons et suppressions

Les fonctionnalités suivantes ont été abandonnées ou supprimées dans cette version. Pour en savoir plus, consultez le règlement relatif aux abandons d'Edge.

Obsolète : limites de monétisation (UI Cloud 16.10.26)

La fonctionnalité de limites de monétisation a été supprimée de l'interface utilisateur de gestion (Admin > Limites). Pour en savoir plus, y compris sur les alternatives, consultez l'avis d'abandon : http://docs.apigee.com/monetization/content/limit-feature-deprecation-notice. (DEVRT-3259)

Suppression de la compatibilité avec RedHat/CentOS version 6.5

Si vous utilisez actuellement RedHat/CentOS version 6.5, vous devez mettre à jour votre système d'exploitation vers la version 6.6 ou ultérieure avant de passer à Edge 4.17.01.

Nouvelles fonctionnalités et mises à jour

Voici les nouvelles fonctionnalités et améliorations de cette version. En plus des améliorations suivantes, cette version contient également plusieurs améliorations de la facilité d'utilisation, des performances, de la sécurité et de la stabilité.

Pour obtenir plus d'informations et d'instructions, consultez la documentation d'Edge for Private Cloud.

Cloud privé

Vous pouvez afficher une bannière de consentement lorsqu'un utilisateur accède pour la première fois à l'interface utilisateur Edge. La bannière de consentement affiche du texte au format HTML et un bouton que l'utilisateur sélectionne pour accéder à l'écran de connexion. Pour en savoir plus, consultez Activer la bannière de consentement.

API BaaS est compatible avec plusieurs centres de données

Vous pouvez désormais installer API BaaS dans plusieurs centres de données. Pour en savoir plus, consultez Installation de plusieurs centres de données pour API BaaS.

Nouveaux paramètres de configuration de l'installation d'API BaaS

Deux nouveaux paramètres de configuration ont été ajoutés au fichier de configuration de l'API BaaS :

BAAS_CASS_DC_LIST : spécifie les noms de région des centres de données BaaS. Pour un seul centre de données, spécifiez la même valeur que BAAS_CASS_LOCALDC.
BAAS_CLUSTER_SEEDS : spécifie les nœuds de la pile BaaS utilisés pour définir les seeds du cluster BaaS.

Pour en savoir plus, consultez Mettre à jour Apigee Edge 4.16.09 vers la version 4.17.01.

L'option "deploy" n'est plus exécutée avec la commande apigee-service pour API BaaS

L'option deploy de la commande apigee-service n'est plus compatible avec la pile et le portail API BaaS. Utilisez plutôt les options configure et restart. Pour en savoir plus, consultez Installation d'API BaaS.

Nouvelle exigence de port pour API BaaS

Tous les nœuds de la pile BaaS doivent désormais ouvrir le port 2551 pour l'accès depuis tous les autres nœuds de la pile. Si vous disposez de plusieurs centres de données BaaS, le port doit être accessible depuis tous les nœuds de la pile dans tous les centres de données.

Pour en savoir plus, consultez les sections Installation d'API BaaS et Conditions d'installation.

Le portail Developer Services utilise désormais Postgres comme base de données et Nginx comme serveur Web.

Pour toutes les nouvelles installations, le portail utilise Postgres comme base de données au lieu de MySQL et MariaDB. Les clients qui passent à la version 4.17.01 à partir d'une version précédente continuent d'utiliser MySQL ou MariaDB.

Les nouvelles installations de la version 4.17.01 installent également Nginx en tant que serveur Web. Les clients qui effectuent une mise à niveau vers la version 4.17.01 à partir d'une version précédente continuent d'utiliser Apache.

Le portail Developer Services n'active plus SmartDocs par défaut

Vous devez activer SmartDocs sur le portail. Pour en savoir plus sur SmartDocs, consultez Utiliser SmartDocs pour documenter des API.

Portail Developer Services désormais installé à partir de RPM

La version 4.17.01 du portail des services pour les développeurs est installée à partir de RPM à l'aide du même dépôt et des mêmes outils qu'Edge et API BaaS. Pour en savoir plus, consultez Installer le portail des services des développeurs.

L'installation basée sur RPM et l'outil de mise à jour basé sur .tar utilisent des composants différents :

	Installation basée sur RPM	Installation basée sur .tar
Serveur Web	Nginx	Apache
Racine Web	/opt/apigee/apigee-drupal	/var/www/html
Port	8079	80
Base de données	PostgreSQL	MySQL
PHP	php-fpm (FastCGI)	mod_php (en cours de traitement avec Apache)

Mise à niveau de Qpid vers la version 1.35

Cette version inclut Qpid version 1.35.

Mise à niveau de Cassandra vers la version 2.1.16

Cette version inclut Cassandra 2.1.16.

Mise à niveau de Play vers la version 2.4

Cette version inclut le framework d'interface utilisateur Play 2.4.

Ajout de la compatibilité avec RedHat/CentOS version 7.3

Edge est désormais compatible avec RedHat/CentOS version 7.3.

Mises à jour du tableau de bord de surveillance (bêta)

La version bêta du tableau de bord de surveillance Edge a été mise à jour :

Inclusion de nouveaux tableaux de bord pour Cassandra, Zookeeper, OpenLDAP, Postgres et Qpid.
Mise à niveau de la version d'Influx dans la version 4.16.09 de 0.11 à 1.0.2.
Ajout d'un certain nombre de correctifs de stabilité.

Pour en savoir plus, consultez Présentation du tableau de bord Apigee Monitoring (bêta).

Vous pouvez désormais définir le mot de passe Postgres dans le fichier de configuration de l'installation.

Utilisez la propriété PG_PWD pour définir le mot de passe Postgres dans le fichier de configuration de l'installation. Pour en savoir plus, consultez la documentation de référence sur le fichier de configuration Edge.

Activer le dépôt EPEL

Vous devez activer Extra Packages for Enterprise Linux (ou EPEL) pour installer ou mettre à jour Edge. Pour en savoir plus, consultez Conditions d'installation.

La commande à utiliser dépend de votre version de RedHat/CentOS :

Pour RedHat/CentOS 7.x :
> wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; rpm -ivh epel-release-latest-7.noarch.rpm
Pour RedHat/CentOS 6.x :
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm; rpm -ivh epel-release-latest-6.noarch.rpm

Désactiver la résolution DNS sur IPv6 lors de l'utilisation de NSCD (Name Service Cache Daemon)

Si vous avez installé et activé NSCD (Name Service Cache Daemon), les processeurs de messages effectuent deux résolutions DNS : une pour IPv4 et une pour IPv6. Vous devez désactiver la résolution DNS sur IPv6 lorsque vous utilisez NSCD. Pour en savoir plus, consultez Conditions d'installation.

Pour désactiver la résolution DNS sur IPv6 :

Sur chaque nœud de processeur de messages, modifiez /etc/nscd.conf.
Définissez la propriété suivante :
enable-cache hosts no

Services d'API

Flux partagés et hooks de flux pour rendre les proxys d'API opérationnels (Cloud 16.09.21)

Une nouvelle fonctionnalité "Flux partagés" vous permet d'opérationnaliser des fonctionnalités dans les proxys d'API. En combinant des règles et des ressources conditionnelles dans un flux partagé, vous pouvez le référencer à partir de n'importe quel proxy d'API pour exécuter une logique réutilisable à source unique. Par exemple, un flux partagé peut vérifier la clé API, protéger contre les pics d'arrêts et consigner les données.

Vous définissez les flux partagés dans l'interface utilisateur de gestion (API > Flux partagés), puis vous les référencez de deux manières différentes :

Avec une nouvelle règle FlowCallout dans un proxy d'API
ou
Sur un nouvel artefact appelé "hooks de flux", qui se trouve aux emplacements suivants :

Ces points d'association vous permettent d'exécuter une logique opérationnelle avant ou après les principaux points de flux du proxy individuel. Vous attribuez des flux partagés à ces emplacements de hook de flux dans l'interface utilisateur de gestion (API > Configuration de l'environnement > Hooks de flux).
- Requête : avant le PreFlow ProxyEndpoint, après le PostFlow TargetEndpoint
- Réponse : avant le PreFlow TargetEndpoint, après le PostFlow ProxyEndpoint

Pour en savoir plus, consultez Flux partagés réutilisables et Associer un flux partagé à l'aide d'un hook de flux.

Mappages de clé-valeurs chiffrés (Cloud 16.09.21)

Vous pouvez créer des mappages clé-valeur (KVM) chiffrés pour stocker des informations sensibles telles que des identifiants ou des données PII/HIPAA. Cette fonctionnalité est différente du magasin sécurisé Edge (coffre-fort) existant et est conçue pour le remplacer, car les valeurs du coffre-fort ne sont accessibles qu'avec Node.js (en plus de l'API de gestion). Vous pouvez accéder aux valeurs KVM chiffrées avec Node.js ou la règle des opérations de mappage clé-valeur.

Créer des KVM chiffrés

Utilisez les API de gestion des KVM existantes. Lorsque vous incluez “encrypted”: “true” dans la définition de la charge utile lors de la création d'un KVM, Edge génère une clé de chiffrement qui a le même champ d'application que le KVM et chiffre le KVM à l'aide de cette clé.
Vous ne pouvez pas utiliser la règle d'opérations de mappage clé-valeur pour créer un KVM chiffré. Vous devez créer un KVM chiffré à l'aide des API de gestion des KVM avant de l'utiliser dans la règle.
Vous ne pouvez pas chiffrer un KVM non chiffré existant.

Utiliser des KVM chiffrés

Utilisez la règle d'opérations de mappage clé-valeur pour obtenir et mettre à jour les valeurs de mappage clé-valeur chiffrées.
Lorsque vous obtenez une valeur de clé chiffrée, ajoutez le préfixe "private." à la variable qui doit contenir la valeur. Exemple : <Get assignTo="private.secretVar">. Cette variable private.secretVar contient la valeur déchiffrée.
Lorsque vous mettez à jour une valeur avec la règle, vous n'avez rien de spécial à faire. La valeur sera automatiquement chiffrée dans les KVM chiffrés.
Vous pouvez également accéder à la valeur déchiffrée à l'aide du module apigee-access dans le code Node.js. Utilisez la fonction getKeyValueMap() pour récupérer un KVM en fonction du nom et du champ d'application. Deux fonctions sont disponibles sur l'objet renvoyé : getKeys(callback) pour obtenir un tableau de noms de clés et get(key, callback) pour obtenir la valeur d'une clé particulière. Par exemple, la commande suivante obtient un KVM de niveau apiproxy appelé VerySecureKVM et récupère la valeur chiffrée de key1 :
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy');
  encryptedKVM.get('key1', function(err, secretValue) {
  // use the secret value here
});
```

Pour en savoir plus, consultez Utiliser des mappages clé-valeur et Accéder aux mappages clé-valeur dans Node.js.

(APIRT-1197)

Créer des mappages clé-valeur chiffrés dans l'UI (UI 16.10.26)

Lorsque vous créez un mappage clé-valeur (KVM) au niveau de l'environnement dans l'interface utilisateur de gestion (APIs > Environment Configuration > Key Value Maps), une nouvelle case à cocher Encrypted (Chiffré) vous permet de créer un KVM chiffré. Une fois que vous avez ajouté des clés au KVM, les valeurs chiffrées apparaissent dans l'interface utilisateur de gestion sous forme d'astérisques (*****). Vous ajoutez des clés/valeurs à un KVM chiffré exactement comme vous le feriez pour des KVM non chiffrés. La compatibilité complète du backend avec les KVM chiffrés est disponible dans la version cloud 160921. (EDGEUI-764)

Avertissement :

Opérations PUT KVM avec des clés nulles (Cloud 16.09.21)

Si une règle d'opérations de mappage clé-valeur tente d'insérer une nouvelle clé-valeur dans un mappage clé-valeur (KVM) à l'aide d'une clé nulle, la clé suivante est créée automatiquement : __$$_EDGE_KVM_EMPTY_KEY_$$__

Cette situation se produit, par exemple, si vous insérez une clé à l'aide d'une référence de variable et que la variable référencée est nulle. Lors de l'exécution de nouvelles opérations PUT contenant des clés nulles, seule cette clé est utilisée. Les valeurs existantes de cette clé sont donc potentiellement écrasées à chaque exécution de la règle.

Auparavant, lorsqu'une clé était nulle, la clé-valeur n'était pas ajoutée au KVM. Au lieu de cela, l'entrée est restée dans le cache en mémoire du processeur de messages et était temporairement disponible pour les opérations Get ultérieures. Si l'implémentation de votre règle KVM repose sur le comportement précédent, les opérations Get sur les clés nulles échoueront désormais, car elles ne font pas référence au nouveau nom de clé (ci-dessus) créé pour les clés nulles. (APIRT-3530)

Avertissement :

Validation des règles dans les étapes FaultRule et DefaultFaultRule avant le déploiement (Cloud 16.09.21)

Lors du déploiement du proxy d'API, Edge valide désormais les règles répertoriées dans les étapes FaultRule et DefaultFaultRule avant le déploiement. Avant ce correctif, le déploiement réussissait avec un code d'état HTTP 200, même si les règles répertoriées dans les étapes FaultRule ou DefaultFaultRule n'existaient pas, et l'erreur InvalidPolicyReference ne se produisait pas avant l'exécution. Désormais, un état HTTP 400 est renvoyé avec une erreur InvalidPolicyReference lors du déploiement. Si vous utilisez des scripts pour déployer des proxys d'API, vous verrez désormais des échecs de déploiement si FaultRules ou DefaultFaultRule font référence à des règles qui n'existent pas. (MGMT-3354)

Inclusion d'URL de spécification OpenAPI dans les métadonnées du proxy d'API (Cloud 16.09.21)

Lorsque vous créez un proxy d'API basé sur une spécification OpenAPI, l'emplacement de la spécification OpenAPI est stocké dans les métadonnées du proxy d'API. Par exemple, si vous utilisez l'API Management pour obtenir les détails d'une révision de proxy, les métadonnées incluent le chemin d'accès à la spécification OpenAPI au format suivant :

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

Cette amélioration est compatible avec la version de nouvelle génération d'Edge, qui associe les spécifications OpenAPI aux proxys d'API, aux produits d'API et aux documents de référence de l'API dans le nouveau portail des développeurs. (MGMT-2913)

Génération de spécifications OpenAPI pour les proxys SOAP (UI Cloud 16.10.05)

Lorsque vous créez un proxy "REST vers SOAP vers REST" basé sur un fichier WSDL, Edge génère automatiquement une spécification OpenAPI hébergée basée sur les ressources du proxy. Vous pouvez accéder à la spécification à l'adresse http(s)://[edge_domain]/[proxy_base_path]/openapi.json. Toutefois, la conversion n'est pas toujours précise, car toutes les règles d'un schéma XML ne peuvent pas être représentées dans une spécification OpenAPI. (EDGEUI-718)

WSDL hébergé par Edge pour les proxys SOAP de type passthrough (UI Cloud 16.10.05)

Lorsque vous créez un proxy "Pass-Through SOAP" basé sur un fichier WSDL, Edge héberge le fichier WSDL et crée un flux dans le proxy pour vous permettre d'y accéder. Vous pouvez accéder au WSDL hébergé à l'adresse http(s)://[edge_domain]/[proxy_base_path]?wsdl, qui est l'URL du nouveau point de terminaison de service pour les clients appelant le service SOAP via le proxy. (EDGEUI-718)

Nouvel exemple de fichier WSDL de cotation boursière dans l'assistant de proxy d'API (Cloud 16.08.24.01)

Lorsque vous créez une API de service SOAP avec l'assistant de proxy d'API, un fichier WSDL de remplacement pour les cours de bourse est disponible dans les exemples : https://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?WSDL. (EDGEUI-655)

Services pour les développeurs

Gestion des applications de développeur dans l'interface utilisateur (UI Cloud 16.10.05)

La gestion des applications de développeur dans l'interface utilisateur Edge a été améliorée grâce à un certain nombre d'améliorations :

Vous pouvez révoquer et approuver des applications (en mode Édition) dans un nouveau champ "État de l'application". En mode d'affichage, le champ indique également l'état actuel de l'application. Si une application est révoquée, aucune de ses clés API n'est valide pour les appels d'API. Les clés elles-mêmes ne sont pas révoquées et sont de nouveau disponibles si le développeur est réapprouvé. Le libellé "Approuvé" des clés API est barré lorsqu'une application est révoquée.
Les dates d'expiration des clés API sont désormais affichées sur la page d'informations de l'application de développeur, et les clés sont organisées par date d'expiration dans une section "Identifiants". Par exemple, une clé sans expiration est affichée dans un groupe avec ses produits d'API associés, et une clé qui expire dans 90 jours est affichée dans un autre groupe avec ses produits associés. Vous ne pouvez pas modifier l'expiration d'un identifiant existant.
Grâce au nouveau bouton "Ajouter un identifiant" en mode d'édition de l'application de développeur, vous pouvez générer des clés API avec des dates ou des heures d'expiration spécifiques (ou sans expiration). Lorsque vous créez un identifiant (ou après l'avoir créé), vous pouvez y ajouter des produits d'API.
Cette fonctionnalité remplace le bouton "Regénérer la clé" sur la page d'informations de l'application de développeur. Ce bouton a été supprimé.

Ces améliorations ajoutent des fonctionnalités à l'interface utilisateur qui étaient déjà disponibles dans l'API Management. (EDGEUI-104)

Activer/Désactiver un développeur d'applications dans l'UI (UI Cloud 16.10.05)

Vous pouvez modifier l'état d'un développeur d'applications entre actif et inactif dans l'interface utilisateur Edge (page "Détails du développeur", mode Édition, bouton "Activer/Désactiver"). Lorsqu'un développeur est inactif, aucune des clés API de son application de développement ni aucun des jetons OAuth générés avec ces clés ne sont valides dans les appels aux proxys d'API. (EDGEUI-304)

Indicateurs de développeur inactifs dans l'UI (UI 16.10.26)

Lorsqu'un développeur d'applications est défini sur "Inactif", ses applications et ses identifiants ne sont plus valides, même s'ils restent à l'état "Approuvé". Désormais, lorsque vous affichez les applications et les identifiants d'un développeur inactif dans l'interface utilisateur de gestion, le libellé d'état "Approuvé" des applications et des identifiants s'affiche en texte barré, et une info-bulle au survol de la souris indique que le développeur est inactif. Si l'état du développeur est rétabli sur "Actif", ses applications et ses identifiants approuvés sont à nouveau valides, et le texte barré sur l'étiquette "Approuvé" est supprimé. (EDGEUI-728)

Services d'analyse

Tableau de bord "Analyse des codes d'erreur" renommé (UI 16.10.26)

Le tableau de bord "Analyse des erreurs" a été renommé "Analyse des codes d'erreur". Le tableau de bord inclut les appels d'API avec les codes d'état HTTP 4xx et 5xx. (EDGEUI-738)

Données TPS sur les tableaux de bord de proxy (UI 16.10.26)

Les données relatives au nombre moyen de transactions par seconde ("TPS moyen") ont été ajoutées au tableau de bord principal du trafic du proxy. De plus, lorsque vous pointez sur des points de données individuels dans les graphiques "Trafic du proxy" et "Performances du proxy", le nombre de TPS pour cet intervalle de temps s'affiche dans l'info-bulle. (EDGEUI-668)

Affichage des erreurs Analytics (UI 16.10.26)

Lorsqu'un tableau de bord d'analyse recevait une erreur 500, l'UI de gestion affichait "Délai d'expiration du rapport dépassé", quelle que soit l'erreur. Pour améliorer les fonctionnalités de dépannage, l'UI affiche désormais l'erreur réelle. (EDGEUI-753)

Corrections de bugs

Les bugs suivants sont résolus dans cette version. Cette liste s'adresse principalement aux utilisateurs qui veulent vérifier si leurs demandes d'assistance ont été corrigées. Elle n'est pas conçue pour fournir des informations détaillées à tous les utilisateurs.

Edge for Private Cloud 4.17.01

ID du problème	Description
APIBAAS-1990	La pile API BaaS ne tente plus de s'authentifier auprès de SMTP lorsque smtp.auth est défini sur "false"
APIRT-3032	L'exécution de la commande "apigee-service baas-usergrid restart" exécute désormais également "configure" Vous n'avez plus besoin d'exécuter "apigee-service baas-usergrid configure" suivi de "apigee-service baas-usergrid restart" pour la pile BaaS.
APIRT-3032	Ne pas effectuer de résolution DNS si le nom d'hôte est une adresse IP.
DOS-4070	"apigee-all -version" affiche désormais la version des RPM edge-mint-*
DOS-4359	Ajout de l'option "pdb" pour installer uniquement la base de données Postgres. Utilisé uniquement lors de l'installation du portail Developer Services. Consultez Installation du portail Developer Services.

Cloud 16.10.26 (UI)

ID du problème	Description
EDGEUI-768	La création du proxy avec le WSDL StockQuote échoue

Cloud 16.09.21_9

ID du problème	Description
MGMT-3674	Impossible de créer des KVM ou des coffres chiffrés pour les organisations compatibles avec la loi HIPAA
MGMT-3647	L'accès au rôle utilisateur pour les utilisateurs dont l'adresse e-mail comporte des majuscules renvoie une erreur 403

Cloud 16.09.21

ID du problème	Description
APIRT-3507	Erreurs intermittentes (telles que les erreurs SNI) sur les appels de service JavaScript
APIRT-3408	Le module d'analyse apigee-access de la version 160817 du processeur de messages traite les messages différemment
APIRT-3390	Modification de la réponse d'erreur renvoyée par la règle d'actualisation du jeton d'accès Avertissement : Modification du code d'erreur OAuthV2 "invalid_client". Notez la modification suivante apportée à un code d'erreur généré par les opérations GenerateAccessToken et RefreshAccessToken de la règle OAuthV2 : `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` a été remplacé par : `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Nous vous recommandons de modifier toutes les conditions de règle d'erreur qui interceptent "`invalid_client`" pour intercepter à la fois l'ancien et le nouveau code. Par exemple, dans votre règle de défaillance, modifiez : `(fault.name = "invalid_client")` par celle-ci : `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Avertissement : Erreur lors de l'importation de charges utiles Node.js de plus de 25 Ko L'importation de charges utiles Node.js de plus de 25 Ko est désormais autorisée.
APIRT-3381	Latences élevées sur les proxys de production du client
APIRT-3366	Les règles JavaScript échouent sur toutes les nouvelles organisations d'essai
APIRT-3363	L'analyse d'une URL non valide renvoie un état 500 avec ApplicationNotFound
APIRT-3356	Message de jeton OAuth non valide
APIRT-3355	Erreur 403 intermittente sur le proxy OAuth
APIRT-3285	Avertissement : Expiration incohérente du jeton OAuth2 Lorsque vous générez un jeton OAuth à l'aide de la règle OAuth v2.0, vous pouvez définir l'expiration du jeton par référence ou par défaut codé en dur. Exemple : `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. La première fois que l'expiration du jeton a été définie par référence, Edge a stocké et utilisé cette valeur pour chaque nouvelle expiration de jeton. Ce bug a été corrigé pour utiliser la valeur de référence ou, si aucune valeur de référence n'est fournie, l'expiration par défaut définie dans la règle. Ce correctif peut modifier la durée d'expiration de vos jetons, et vous pouvez rencontrer des effets secondaires tels que des erreurs de jeton non valide, ce qui peut vous obliger à actualiser plus fréquemment les jetons ou à modifier l'expiration par défaut dans vos règles OAuth.
APIRT-3261	Les identifiants sont validés par rapport à une autre application de développement en production
APIRT-3234	L'application Node.js renvoie une exception de pointeur nul
APIRT-3223	Problème de cache obsolète Apigee
APIRT-3193	Le serveur cible Node.js se bloque après le passage à ASG
APIRT-3152	L'appel de gestion cachedlogs entraîne la fragmentation des messages de journal
APIRT-3117	Le processeur de messages a atteint 100 % d'utilisation du processeur et a cessé de diffuser du trafic
APIRT-3064	Routeur : message d'erreur 503 personnalisé du routeur
APIRT-2620	Pool de threads distinct pour certaines étapes de blocage afin d'améliorer la gestion de la charge
CORESERV-774	L'accès à l'aide d'une clé valide avec une référence de produit d'API non valide entraîne une erreur interne du serveur

Cloud 16.10.05 (UI)

ID du problème	Description
EDGEUI-697	Bouton d'exportation de la page "Rapports" Le bouton "Exporter" a été supprimé de la page d'accueil "Rapports personnalisés". L'exportation de rapports est disponible sur chaque page de rapports personnalisés.

Cloud 16.08.24.01

ID du problème	Description
EDGEUI-663	Le proxy généré pour le port WeatherHttpGet de Weather.wsdl échoue lors de l'exécution avec une erreur 500 Lors de la génération d'un proxy d'API pour un service SOAP, les ports WSDL sans liaison de protocole SOAP ne sont plus visibles dans l'assistant de proxy d'API. C'est normal, car l'assistant ne génère que des requêtes SOAP.
EDGEUI-658	Problème de nom d'opération de transfert SOAP WSDL
EDGEUI-653	Erreur lors de la création du proxy d'API Node.js lorsque l'option "Activer CORS" est sélectionnée
EDGEUI-648	Les appels depuis l'interface utilisateur qui prennent entre deux et trois minutes expirent
EDGEUI-623	Le bouton "Modifier la date" de l'historique de l'organisation ne fonctionne pas dans Firefox

4.17.01.01

4.16.09.04