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.

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**. info

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 (version 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 à 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, se protéger contre les pics de trafic et enregistrer des données.

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

Avec une nouvelle règle FlowCallout dans un proxy d'API
Sur un nouvel artefact appelé hooks de flux, qui se trouve aux emplacements suivants :
- Requête : avant le PreFlow ProxyEndpoint, après le TargetEndpoint PostFlow
- Réponse : avant le PreFlow TargetEndpoint, après le PostFlow ProxyEndpoint
Ces points d'association 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 hook 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 magasin sécurisé Edge existant (coffre-fort) 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 de KVM chiffrées avec Node.js ou la règle Key ValueMapOperations.

Créer des KVM chiffrés

Utilisez les API KVM existantes. Lorsque vous incluez “encrypted”: “true” dans la définition de la charge utile lors de la création d'un KVM, Edge chiffre le KVM et génère une clé de chiffrement qui a la même portée que le KVM.
Vous ne pouvez pas utiliser la règle KeyValueMapOperations 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 de KVM chiffrées.
Lorsque vous obtenez une valeur de clé chiffrée, préfixez la variable pour conserver la valeur avec "private.". Exemple : <Get assignTo="private.secretVar">. Cette private.secretVar variable 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 chiffrée automatiquement 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 de la portée. 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. 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 KeyValueMapOperations tente de mettre à jour (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, pour une clé nulle, la clé-valeur n'était pas ajoutée au KVM. Au lieu de cela, l'entrée restait dans le cache en mémoire du processeur de messages et était temporairement disponible pour les opérations Get suivantes. 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 Spec est stocké dans les métadonnées du proxy d'API. Par exemple, si vous utilisez l'API de gestion 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 aux documents de référence de l'API dans le nouveau portail des développeurs. (MGMT-2913)

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

Afin de contrôler plus précisément l'emplacement des 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 de robot. (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 des erreurs SNI) sur les appels de service JavaScript callouts
APIRT-3408	Le module d'analyse apigee-access de la version MP 160817 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 d'un code d'erreur généré par les opérations de règle OAuthV2 GenerateAccessToken et RefreshAccessToken lorsque la propriété <GenerateResponse> de la règle 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 toutes les conditions de règle d'erreur qui interceptent "`invalid_client`" pour intercepter les anciens et les nouveaux codes. Par exemple, dans votre règle d'erreur, remplacez : `(fault.name = "invalid_client")` par : `(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 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. Cette correction peut modifier la durée d'expiration de vos jetons. Vous pouvez également rencontrer des effets secondaires tels que davantage d'erreurs de jeton non valide, ce qui peut vous obliger à implémenter des actualisations de jeton plus fréquentes 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 bloqué après le passage à ASG
APIRT-3152	L'appel de gestion cachedlogs entraîne la fragmentation des messages de journalisation
APIRT-3117	Le processeur de messages 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 gestion de la charge
CORESERV-774	L'accès à l'aide d'une clé valide avec une référence apiproduct non valide provoque une erreur de serveur interne erreur