Cette page a été traduite par l'API Cloud Translation.

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 pour le cloud privé.

Depuis la précédente version de fonctionnalité Edge pour le cloud privé, 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 plusieurs 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 pour plusieurs proxys d'API.

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

Pour un contrôle plus flexible de l'accès des développeurs à vos API, l'UI de gestion Edge offre plus d'options pour créer et gérer les clés et secrets d'API (identifiants), révoquer les applications de développement et désactiver les développeurs. Ces améliorations vous permettent d'implémenter plus facilement des stratégies telles que la rotation des clés API. Elles vous permettent également 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 l'abandon de fonctionnalités, la fonctionnalité de limites de monétisation a été supprimée.

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

Arrêts et suppressions

Les fonctionnalités suivantes ont été abandonnées ou supprimées dans cette version. Pour en savoir plus, consultez les Règles d'abandon d'Edge.

Retiré : limites de monétisation (UI Cloud 16.10.26)

La fonctionnalité 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 à utiliser, consultez l'avis d'obsolescence : 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 la version 6.5 de RedHat/CentOS, 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 apportées à cette version. En plus des améliorations suivantes, cette version contient également de nombreuses améliorations en termes d'usabilité, de performances, de sécurité et de stabilité.

Pour en savoir plus et obtenir des instructions, consultez la documentation Edge pour le cloud privé.

Cloud privé

Vous pouvez afficher une bannière de consentement lorsqu'un utilisateur accède à l'interface utilisateur Edge pour la première fois. 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.

L'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 de l'API BaaS

Deux nouveaux paramètres de configuration ont été ajoutés au fichier de configuration 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 pour 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 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 concernant les ports pour l'API BaaS

Tous les nœuds de la pile BaaS doivent désormais ouvrir le port 2551 pour permettre l'accès à partir de 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 Stack de tous les centres de données.

Pour en savoir plus, consultez Installation de l'API BaaS et Exigences d'installation.

Le portail des services pour les développeurs 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 antérieure continuent d'utiliser MySQL ou MariaDB.

Les nouvelles installations de la version 4.17.01 installent également Nginx comme serveur Web. Les clients qui passent à la version 4.17.01 à partir d'une version antérieure continuent d'utiliser Apache.

Le portail Developer Services ne permet plus d'activer SmartDocs par défaut

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

Le portail des services pour les développeurs est désormais installé à partir de RPM

La version 4.17.01 du portail Developer Services 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 Installation du portail Developer Services.

L'installation basée sur RPM et le programme 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
Database (Base de données)	PostgreSQL	MySQL
PHP	php-fpm (FastCGI)	mod_php (en cours de traitement avec Apache)

Qpid mis à niveau vers la version 1.35

Cette version inclut Qpid 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'UI Play 2.4.

Ajout de la compatibilité avec RedHat/CentOS version 7.3

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

Modifications apportées au tableau de bord de surveillance bêta

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

Incluez 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 la présentation de la version bêta du tableau de bord Apigee Monitoring.

Il est désormais possible de 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 recherches 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 Message Processor, 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 opérationnaliser les proxys d'API (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 y faire référence depuis n'importe quel proxy d'API pour exécuter une logique réutilisable à source unique. Par exemple, un flux partagé peut valider la clé API, protéger contre les pics d'utilisation et enregistrer les données.

Vous définissez des 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'attachement vous permettent d'exécuter une logique opérationnelle avant ou après les points de flux principaux du proxy individuel. Vous attribuez des flux partagés à ces emplacements de hooks 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 clé-valeur 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 coffre-fort Edge 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 KeyValueMapOperations.

Créer des KVM chiffrés

Utilisez les API de gestion des KVM existantes. Lorsque vous incluez “encrypted”: “true” dans la définition de charge utile lors de la création d'un KVM, Edge génère une clé de chiffrement qui a la même portée que le KVM et chiffre le KVM à l'aide de cette clé.
Vous ne pouvez pas utiliser la règle "Opérations sur les mappages 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 KeyValueMapOperations pour obtenir et mettre à jour les valeurs KVM chiffrées.
Lorsque vous obtenez une valeur de clé chiffrée, préfixez la variable contenant la valeur avec le mot clé "private.". Exemple : <Get assignTo="private.secretVar">. Cette variable private.secretVar contient la valeur déchiffrée.
Lorsque vous mettez à jour une valeur avec le règlement, vous n'avez rien de particulier à faire. La valeur sera automatiquement chiffrée dans les KVM chiffrées.
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é spécifique. Par exemple, la commande suivante obtient un KVM de portée 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) à l'échelle de l'environnement dans l'interface utilisateur de gestion (API > Configuration de l'environnement > Mappages clé-valeur), une nouvelle case à cocher Chiffré vous permet de créer un KVM chiffré. Une fois que vous avez ajouté des clés au KVM, les valeurs chiffrées s'affichent sous forme d'astérisques (*****) dans l'interface utilisateur de gestion. Vous ajoutez des clés/valeurs à un KVM chiffré exactement comme vous le feriez pour un KVM non chiffré. La compatibilité complète du backend avec les KVM chiffrés était disponible dans la version cloud 160921. (EDGEUI-764)

Avertissement :

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

Si une règle d'opérations de mappage clé-valeur tente d'insérer (PUT) 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 listées dans les étapes FaultRule et DefaultFaultRule avant le déploiement. Avant cette correction, le déploiement réussissait avec un code d'état HTTP 200, même si les règles listées dans les étapes FaultRule ou DefaultFaultRule n'existaient pas. L'erreur InvalidPolicyReference ne se produisait qu'au moment de 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)

URL de spécification OpenAPI incluses 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 nouvelle génération d'Edge, qui associe les spécifications OpenAPI aux proxys d'API, aux produits d'API et à la documentation de référence des 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 to SOAP to 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é sur Edge pour les proxys SOAP pass-through (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 fichier WSDL hébergé à l'adresse http(s)://[edge_domain]/[proxy_base_path]?wsdl, qui correspond à la nouvelle URL du point de terminaison du service pour les clients appelant le service SOAP via le proxy. (EDGEUI-718)

Nouvel exemple de WSDL de cours de bourse 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 WSDL de cours de bourse de remplacement est disponible dans les exemples : https://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?WSDL. (EDGEUI-655)

Services pour les développeurs

Gestion des applications pour les développeurs dans l'UI (UI Cloud 16.10.05)

La gestion des applications de développeur dans l'interface utilisateur Edge est devenue plus performante 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 Affichage, le champ affiche é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 peuvent être réutilisées si le développeur est à nouveau approuvé. Le libellé "Approuvée" pour les clés API s'affiche en texte barré lorsqu'une application est à l'état révoqué.
Les dates d'expiration des clés API sont désormais indiquées sur la page d'informations sur l'application du développeur. Les clés sont organisées par date d'expiration dans la section "Identifiants". Par exemple, une clé sans date d'expiration est affichée dans un groupe avec les produits d'API associés, tandis qu'une clé qui expire dans 90 jours est affichée dans un autre groupe avec les produits associés. Vous ne pouvez pas modifier la date d'expiration d'un identifiant existant.
Grâce au nouveau bouton "Ajouter un identifiant" en mode d'édition de l'application pour les développeurs, vous pouvez générer des clés API avec des délais ou des dates d'expiration spécifiques (ou sans expiration). Lorsque vous créez un identifiant (ou après), vous pouvez y ajouter des produits d'API.
Cette fonctionnalité remplace le bouton "Régénérer la clé" sur la page "Informations sur l'application pour les développeurs". Ce bouton a été supprimé.

Ces améliorations ajoutent à l'UI des fonctionnalités 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 (actif ou 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 de ses clés API d'application de développeur 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 inactif dans l'UI (UI du 26/10/2016)

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 consultez les applications et les identifiants d'un développeur inactif dans l'UI de gestion, le libellé d'état "Approuvé" sur les applications et les identifiants est barré. Une info-bulle s'affiche au passage de la souris sur le libellé pour indiquer que le développeur est inactif. Si le développeur est rétabli sur "Actif", ses applications et identifiants approuvés sont à nouveau valides, et le texte barré sur le libellé "Approuvé" est supprimé. (EDGEUI-728)

Services d'analyse

Le tableau de bord "Analyse des codes d'erreur" a été renommé (interface utilisateur du 26/10/2016)

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 des codes d'état HTTP 4xx et 5xx. (EDGEUI-738)

Données TPS sur les tableaux de bord de proxy (UI du 26/10/16)

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

Affichage des erreurs Analytics (UI du 26/10/2016)

Lorsqu'un tableau de bord Analytics recevait une erreur 500, l'interface utilisateur de gestion affichait "Le rapport a expiré", quelle que soit l'erreur. Pour vous aider à résoudre les problèmes, l'UI affiche désormais l'erreur réelle. (EDGEUI-753)

Bugs résolus

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 pour le cloud privé 4.17.01

ID du problème	Description
APIBAAS-1990	La pile API BaaS n'essaie plus de s'authentifier auprès du protocole 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	N'effectuez pas de résolution DNS si le nom d'hôte est une adresse IP.
DOS-4070	La commande"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	Échec de la création du proxy avec StockQuote WSDL

Cloud 16.09.21_9

ID du problème	Description
MGMT-3674	Impossible de créer des KVM ou des coffres-forts 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 génère 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 MP traite les messages différemment
APIRT-3390	Modification de la réponse d'erreur renvoyée par la stratégie d'actualisation du jeton d'accès Avertissement : Modification du code d'erreur "invalid_client" d'OAuthV2. Notez la modification suivante apportée à un code d'erreur généré par les opérations de la stratégie OAuthV2 : GenerateAccessToken et RefreshAccessToken : `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` a été remplacé par : `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Nous vous recommandons de modifier les conditions de règle d'erreur qui piègent "`invalid_client`" pour identifier les anciens et les nouveaux codes. Par exemple, dans votre règle d'erreur, remplacez : `(fault.name = "invalid_client")` par ceci : `(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 des clients
APIRT-3366	Échec des règles JavaScript dans 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 des jetons 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, la date d'expiration par défaut définie dans la règle. Cette correction peut modifier la durée d'expiration de vos jetons. Vous pouvez rencontrer des effets secondaires tels que des erreurs de jeton non valide plus fréquentes, ce qui peut vous obliger à actualiser les jetons plus souvent 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 est suspendu après le transfert vers ASG
APIRT-3152	L'appel de gestion cachedlogs entraîne la fragmentation des messages de journaux
APIRT-3117	Le MP 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 bloquantes 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 apiproduct non valide entraîne une erreur de serveur interne.

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 des 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 lié au nom de l'opération de transfert WSDL SOAP
EDGEUI-653	Erreur lors de la création d'un proxy d'API Node.js lorsque l'option "Activer CORS" est sélectionnée
EDGEUI-648	Les appels depuis l'UI qui durent 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