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

4.17.01 - Notes de version d'Edge for Private Cloud

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

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

Depuis la version précédente de Edge for Private Cloud, les versions suivantes ont s'est produite 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)

Reportez-vous à la section À propos de la version la numérotation pour comprendre comment déterminer si une version spécifique du cloud inclus dans votre version d'Edge pour Private Cloud.

Présentation de la version

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

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

Les cartes clé-valeur (KVM), qui étaient déjà une fonctionnalité Edge pour la persistance à long terme des paires clé/valeur, peuvent désormais être chiffrées 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 fournit d'autres options pour créer et gérer des clés API et des secrets (identifiants), révoquer des comptes de développeur applications et la désactivation des développeurs. Ces améliorations vous permettent de mettre en œuvre plus facilement des stratégies comme la rotation des clés API, et vous permettent de désactiver plusieurs clés API en révoquant une application de développeur si ses clés sont désactivées) ou la désactivation d'un développeur (toutes les applications et clés du développeur sont désactivées).

Lors de l'abandon, la fonctionnalité de limites de monétisation a été supprimée.

La suite de cette rubrique contient des informations détaillées sur toutes les nouvelles fonctionnalités, mises à jour et corrections de bugs. dans l'album.

Abandons et suppressions

Les fonctionnalités suivantes ont été abandonnées ou supprimées dans cette version. Consultez la règle d'obsolescence Edge pour plus d'informations.

Retiré: monétisation Limites (UI Cloud 16.10.26)

La fonctionnalité de limites de monétisation a été supprimée de l'interface utilisateur de gestion (Admin > les limites). Consultez l'avis d'abandon pour plus d'informations, y compris sur les méthodes de remplacement: http://docs.apigee.com/monetization/content/limit-feature-deprecation-notice. (DEVRT-3259).

Assistance pour Suppression de la version 6.5 de RedHat/CentOS

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

Nouvelles fonctionnalités et mises à jour

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version. En plus des éléments suivants, Cette version inclut également de multiples fonctionnalités en termes de facilité d'utilisation, de performances, de sécurité et de stabilité améliorations.

Pour plus d'informations et d'instructions, consultez la documentation Edge pour 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. 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. Consultez la section Activer le consentement pour en savoir plus.

L'API BaaS est compatible avec plusieurs centres de données

Vous pouvez désormais installer une API BaaS dans plusieurs centres de données. Voir Plusieurs centres de données Installation pour l'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 BaaS de l'API:

BAAS_CASS_DC_LIST : spécifie les noms des régions des centres de données BaaS. Pour un seul centre de données, indiquez 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 sources du cluster BaaS.

Voir Mettre à jour Apigee Edge 4.16.09 au 4.17.01 pour en savoir plus.

N'exécute plus "deploy" avec la commande apigee-service pour l'API BaaS

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

Nouvelle exigence de port pour l'API BaaS

Tous les nœuds de pile BaaS doivent désormais ouvrir le port 2551 pour que tous les autres nœuds de pile puissent y accéder. Si vous si vous possédez plusieurs centres de données BaaS, le port doit être accessible depuis tous les nœuds de la pile dans toutes les données Centres d'aide.

Consultez les pages Installation d'API BaaS et Conditions d'installation pour en savoir plus.

Le portail de 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 effectuent une mise à niveau vers la version 4.17.01 à partir d'une version antérieure continuent à utiliser MySQL ou MariaDB.

Les nouvelles installations pour la version 4.17.01 installent également Nginx en tant que serveur Web. Clients passant à 4.17.01 d'une version précédente continuent à utiliser Apache.

Le portail de services pour les développeurs n'active plus SmartDocs par défaut.

Vous devez activer SmartDocs sur le portail. Pour plus d'informations sur les SmartDocs, consultez l'article Utiliser SmartDocs pour documenter API.

Portail des services pour les développeurs désormais installé à partir des RPM

La version 4.17.01 du portail de services pour les développeurs est installée à partir de RPM à l'aide de la même un dépôt et des outils comme Edge et API BaaS. Voir le portail de services pour les développeurs l'installation.

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

	Installation basée sur le 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 avec Apache)

Qpid mis à niveau vers la version 1.35

Cette version inclut la version 1.35 de Qpid.

Mise à niveau de Cassandra vers la version 2.1.16

Cette version inclut la version 2.1.16 de Cassandra.

Google Play mis à niveau à la version 2.4

Cette version inclut le framework d'UI Play 2.4.

Compatibilité avec RedHat/CentOS version 7.3 ajoutée

Edge prend désormais en charge 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 vers:

Ajout de nouveaux tableaux de bord pour Cassandra, ZooKeeper, OpenLDAP, Postgres et Qpid
Mise à niveau d'Influx vers la version 4.16.09 de la version 0.11 à la version 1.0.2.
Ajout de plusieurs correctifs de stabilité.

Voir Apigee Présentation de la version bêta du tableau de bord Monitoring.

Possibilité de définir le mot de passe Postgres dans le fichier de configuration d'installation

Utiliser la propriété PG_PWD pour définir le mot de passe Postgres dans le fichier de configuration d'installation. Voir Fichier de configuration Edge Documentation de référence pour en savoir plus

Activer le dépôt EPEL

Vous devez activer les packages supplémentaires pour Enterprise Linux (ou EPEL) pour installer ou mettre à jour Edge. Consultez la section Conditions d'installation pour plus encore.

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; tpm -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; tpm -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 effectue deux résolutions DNS: une pour IPv4 et une pour IPv6. Vous devez désactiver la résolution DNS sur IPv6 lorsque à l'aide de NSCD. Consultez la section Conditions d'installation. pour en savoir plus.

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

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

Services d'API

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

Un nouveau "Flux partagés" fonctionnalité vous permet d'opérationnaliser une fonctionnalité dans les mandataires d'API. Par combinant des règles et des ressources conditionnelles dans un flux partagé, vous pouvez le référencer n'importe quel proxy d'API pour exécuter une logique à source unique et réutilisable. Par exemple, un flux partagé peut vérifier la clé API, la protection contre les arrestations de pics et les données de journal.

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

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

Ces points d'attache vous permettent d'exécuter une logique opérationnelle avant ou après le flux principal les points de terminaison du proxy individuel. Vous attribuez des flux partagés à ces emplacements de hook de flux dans la section (API > Environment Configuration > Flow Hooks [API > Configuration de l'environnement > Hooks de flux]).
- Requête: avant le PreFlow du ProxyEndpoint, après le TargetEndpoint PostFlow
- Réponse: Avant le PreFlow de TargetEndpoint, après le ProxyEndpoint PostFlow

Pour en savoir plus, consultez la section Réutilisables flux partagés et Associer un flux partagé à l'aide d'un crochet de flux.

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

Vous pouvez créer des cartes KVM (Key Value Map) chiffrées pour stocker des informations sensibles telles que ou des informations personnelles/HIPAA. Cette fonctionnalité est différente du stockage sécurisé Edge existant (vault) et est conçu pour le remplacer, car les valeurs Vault ne sont accessibles qu'avec Node.js (dans en plus de l'API de gestion). Vous pouvez accéder aux valeurs KVM chiffrées avec Node.js ou la clé Règle Opérations sur la carte de valeur.

Créer des KVM chiffrées

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

Utiliser des KVM chiffrées

Utilisez la règle Opérations de mappage de valeurs clés pour obtenir et mettre à jour les valeurs KVM chiffrées.
Lorsque vous obtenez une valeur de clé chiffrée, faites précéder la variable de la valeur avec le mot clé "privée". Exemple : <Get assignTo="private.secretVar">. Cela La variable private.secretVar contient la valeur déchiffrée.
Lorsque vous mettez à jour une valeur avec la règle, aucune action spéciale n'est requise. La valeur seront chiffrés automatiquement dans des 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 une KVM en fonction de son nom et de son champ d'application Deux des 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. Pour Dans l'exemple suivant, on obtient une KVM de portée apiproxy appelée 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 la section Utiliser des clés les mappages de valeurs et l'accès les mappages de paires clé-valeur dans Node.js.

(APIRT-1197)

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

Lors de la création d'un mappage de clé-valeur à l'échelle de l'environnement dans l'interface utilisateur de gestion (API > Configuration de l'environnement > des mappages de clés-valeurs), La nouvelle case à cocher Chiffré vous permet de créer une clé KVM chiffrée. Après avoir ajouté à la KVM, les valeurs chiffrées apparaissent dans l'interface utilisateur de gestion sous forme d'astérisques (*****). Vous ajoutez clés/valeurs à une KVM chiffrée, exactement comme vous le feriez pour des KVM non chiffrées. Compatibilité complète avec le backend pour les KVM chiffrées était disponible dans la version cloud 160921. (EDGEUI-764)

</ph> Avertissement:

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

Si une stratégie Opérations de mappage de valeurs clés tente d'insérer une nouvelle clé/valeur dans un mappage de clé-valeur (KVM) à l'aide d'une clé nulle, la clé suivante est créé 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, pour une clé nulle, la clé/valeur n'était pas ajoutée à la KVM. Au lieu de cela, l'entrée est restée dans le cache en mémoire du processeur de messages et a été temporairement disponibles pour les opérations Get ultérieures. Si l'implémentation de votre stratégie KVM repose sur précédent, les opérations Get sur des clés nulles échoueront maintenant, car elles ne font pas référence le nouveau nom de clé (ci-dessus) créé pour les clés nulles. (APIRT-3530).

</ph> Avertissement:

Validation des stratégies dans les étapes FaultRule et DefaultFaultRule avant le déploiement (Cloud Build 16.09.21)

Lors du déploiement du proxy d'API, Edge valide désormais les stratégies répertoriées dans FaultRule et DefaultFaultRule avant le déploiement. Avant ce correctif, le déploiement passait avec succès le code d'état 200 même si les stratégies répertoriées dans les étapes FaultRule ou DefaultFaultRule n'existaient pas, et que l'erreur InvalidPolicyReference ne s'est produite qu'au moment de l'exécution. L'état HTTP 400 est maintenant renvoyé avec une erreur InvalidPolicyReference lors du déploiement. Si vous utilisez des scripts pour déployer des proxys d'API, vous verrez des échecs de déploiement si FaultRules ou le DefaultFaultRule référence des stratégies 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 du La spécification est stockée dans les métadonnées du proxy d'API. Par exemple, si vous utilisez l'API de gestion pour obtenir d'une révision de proxy, les métadonnées incluent le chemin d'accès à la spécification OpenAPI dans format:

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

Cette amélioration prend en charge la version nouvelle génération d'Edge, qui associe les spécifications OpenAPI à Proxys d'API, produits d'API et documents 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 une requête basé sur un WSDL, Edge génère automatiquement un la spécification OpenAPI hébergée en fonction des ressources du proxy. Vous pouvez consulter les spécifications à l'adresse http(s)://[edge_domain]/[proxy_base_path]/openapi.json Toutefois, la conversion est pas toujours précises, car toutes les règles d'un schéma XML ne peuvent pas être représentées dans une API OpenAPI Spécifications (EDGEUI-718)

WSDL hébergé en périphérie pour les proxys SOAP passthrough (UI Cloud 16.10.05)

Lorsque vous créez un protocole basé sur un WSDL, Edge héberge le WSDL et crée un 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, le nouveau point de terminaison du service URL pour les clients qui appellent le service SOAP via le proxy. (EDGEUI-718)

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

Lors de la création d'une API de service SOAP avec l'assistant de proxy d'API, le fichier WSDL d'une cotation d'action de remplacement est comme indiqué dans les exemples suivants: https://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?WSDL. (EDGEUI-655)

Services pour les développeurs

Avantages de la gestion des applications de développement dans l'UI (UI Cloud 16.10.05)

La gestion des applications de développement dans l'interface utilisateur Edge est devenue plus efficace avec un certain nombre améliorations:

Vous pouvez révoquer et approuver des applications (en mode Édition) dans la nouvelle section "État de l'application". . En mode Vue, 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. Leurs clés ne sont pas révoquées et sont de nouveau disponibles pour utiliser si le développeur est de nouveau approuvé. L'état "Approuvé" le libellé des clés API s'affiche texte barré lorsqu'une application est désactivée
Les dates d'expiration des clés API s'affichent désormais sur la page d'informations de l'application pour les développeurs, et les clés sont organisées par date d'expiration dans un . Par exemple, une clé sans délai d'expiration est visible dans un groupe avec ses produits d'API associés, et une clé qui expire au bout de 90 jours est affichée dans un autre groupe avec ses produits associés. Vous ne pouvez pas modifier la date d'expiration d'un identifiant existant.
Grâce au nouveau bouton "Add Credential" (Ajouter des identifiants) en mode Édition de l'application de développement, vous pouvez générer des clés API avec des dates ou heures d'expiration spécifiques (ou aucune date d'expiration) ; Pendant (ou après) la création d'un identifiant, vous pouvez y ajouter des produits d'API.
Cette fonctionnalité remplace l'option "Regénérer la clé" sur la page d'informations sur l'application pour les développeurs. Cela a été supprimé.

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

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

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

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

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

Services d'analyse

Changement de nom : "Analyse de code d'erreur" tableau de bord (interface utilisateur 16.10.26)

Analyse des erreurs tableau de bord a été renommé « Analyse de code 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 des proxys (interface utilisateur 16.10.26)

Les données relatives au nombre moyen de transactions par seconde ("TPS moyen") ont été ajoutées au proxy principal. Tableau de bord du trafic. De plus, lorsque vous pointez sur des points de données individuels dans 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 (interface utilisateur 16.10.26)

Lorsqu'un tableau de bord d'analyse recevait une erreur 500, l'interface utilisateur de gestion affichait « Rapport avec code temporel " quelle que soit l'erreur. Pour offrir de meilleures fonctionnalités de dépannage, 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 for Private Cloud 4.17.01

ID du problème	Description
APIBAAS-1990	La pile BaaS de l'API ne tente plus de s'authentifier auprès du serveur SMTP lorsque smtp.auth est faux
APIRT-3032	Exécuter le "redémarrage baas-usergrid apigee-service" à présent aussi exécute "configure" Vous n'avez plus besoin d'exécuter "apigee-service baas-usergrid configure" suivi de "redémarrage baas-usergrid apigee-service" 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	"apigee-all -version" affiche désormais la version des RPM Edge-mint-*
DOS-4359	Ajout de "pdb" permettant d'installer la base de données Postgres uniquement. Utilisé uniquement lors de l'installation du portail de services pour les développeurs. Voir Services pour les développeurs l'installation du portail.

Cloud 16.10.26 (UI)

ID du problème	Description
EDGEUI-768	Échec de la création du proxy avec le WSDL StockCitation

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 soumises à la loi HIPAA
MGMT-3647	L'accès "Userrole" pour les utilisateurs avec une adresse e-mail en 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 le service JavaScript accroches
APIRT-3408	Module d'analyse d'accès Apigee version 160817 du MP traitant les messages différemment
APIRT-3390	Modification de la réponse d'erreur renvoyée par la stratégie d'actualisation des jetons d'accès <ph type="x-smartling-placeholder"> </ph> 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 de la stratégie OAuthV2. <ph type="x-smartling-placeholder"></ph> GenerateAccessToken et RefreshAccessToken: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` a été remplacé par: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Il est recommandé de modifier les conditions des règles d'erreur "`invalid_client`" pour détecter à la fois l'ancien et le nouveau code. Pour exemple, dans votre règle de faute, remplacez: `(fault.name = "invalid_client")` par: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Avertissement:Erreur lors du chargement des charges utiles Node.js sur 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 client
APIRT-3366	Les règles JavaScript ne fonctionnent pas dans toutes les nouvelles organisations en phase d'essai
APIRT-3363	L'analyse des URL non valides 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:Jeton OAuth2 incohérent expiration Lors de la génération d'un jeton OAuth à l'aide de la règle OAuth v2.0, vous pouvez définir le jeton soit par référence, soit par défaut codée en dur. Exemple : `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. La première fois que le jeton expiration a été définie par référence, Edge a stocké et utilisé cette valeur pour chaque nouveau jeton la date d'expiration. Ce bug a été corrigé afin d'utiliser la valeur de référence ou, en l'absence de référence, est fournie, le délai d'expiration par défaut défini dans la stratégie. Ce correctif est susceptible de changer la durée d'expiration de vos jetons, et vous risquez de rencontrer des effets secondaires, les erreurs de jeton non valide, ce qui peut vous obliger à mettre en œuvre des actualisations de jeton plus fréquentes ou modifier le délai d'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 NPE
APIRT-3223	Problème de cache Apigee non actualisé
APIRT-3193	Le serveur cible Node.js est suspendu après son déplacement vers ASG
APIRT-3152	L'appel de gestion cachedlogs entraîne la rupture des messages de journal
APIRT-3117	La MP a atteint 100% d'utilisation du processeur et a cessé de diffuser le 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 charge de traitement
CORESERV-774	L'accès à l'aide d'une clé valide avec une référence de produit d'API non valide entraîne un serveur interne aïe !"

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 du rapport est disponibles 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 au moment de l'exécution avec 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. Il s'agit d'un principe simple, puisque l'assistant qui génère des demandes SOAP.
EDGEUI-658	Problème lié au nom de l'opération de passthrough WSDL SOAP
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 à partir de l'interface utilisateur qui prennent entre deux et trois minutes
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