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

16.09.21 : Notes de version d'Apigee Edge pour le cloud public

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

Le jeudi 13 octobre 2016, nous avons commencé à déployer une nouvelle version d'Apigee Edge pour le cloud public.

Nouvelles fonctionnalités et mises à jour

Vous trouverez ci-dessous les nouvelles fonctionnalités et mises à jour offertes par cette version.

Flux partagés et hooks de flux pour opérationnaliser les proxys d'API (bêta sur demande uniquement)

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 :
- Requête : avant le PreFlow ProxyEndpoint, après le PostFlow TargetEndpoint
- Réponse : avant le PreFlow TargetEndpoint, après le PostFlow ProxyEndpoint
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).

Mappages clé-valeur chiffrés

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 KVM existantes. Lorsque vous incluez “encrypted”: “true” dans la définition de charge utile lors de la création d'un KVM, Edge chiffre le KVM et génère une clé de chiffrement ayant la même portée que le KVM.
Vous ne pouvez pas utiliser la règle "Opérations sur les mappages clé-valeur" pour créer un KVM chiffré.
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 "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. Exemple :
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy');
  encryptedKVM.get('secret1', function(err, secretValue) {
  // use the secret value here
});
```

(APIRT-1197)

Avertissement :

Opérations PUT KVM avec des clés nulles

Si une règle d'opérations de mappage de clés-valeurs tente d'insérer (PUT) une nouvelle clé-valeur dans un mappage de clés-valeurs (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)

URL de spécification OpenAPI incluses dans les métadonnées du proxy d'API

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)

Contrôle de l'adresse IP du client avec Sense

Pour contrôler plus précisément où trouver les adresses IP pour la détection des robots Sense lorsque vous utilisez des produits de routage tels qu'Akamai, Sense vous permet de définir l'emplacement de l'adresse IP du client avec une variable additionalIPVars. Par exemple, vous pouvez définir additionalIPVars pour utiliser l'en-tête true-client-ip, qui contient l'adresse IP correcte d'Akamai à évaluer dans les règles relatives aux robots. (APIRT-3332)

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.

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 lorsque la propriété <GenerateResponse> de la stratégie OAuthV2 est définie sur false : `{"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.