Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
Le mardi 30 août 2016, nous avons lancé 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.
Charges utiles JSON dans "Attribuer un message" et "Générer une erreur"
Avec cette amélioration, aucune solution de contournement n'est nécessaire pour garantir une mise en forme correcte des messages JSON. De plus, les variables peuvent être spécifiées à l'aide d'accolades sans créer de JSON non valide. Par exemple, la requête suivante insère la valeur de message.content dans le message JSON:
<Payload contentType="application/json">{"message" : "{message.content}"}</Payload>
Si vous avez utilisé une solution de contournement, votre code continuera à fonctionner tel quel. Vous pouvez également utiliser variablePrefix et variableSuffix au lieu d'accolades pour indiquer les variables.
Consultez l'élément <Set><Payload> dans la documentation de référence sur la stratégie de message d'affectation et la stratégie sur les erreurs de déclenchement. (APIRT-1160).
Améliorations apportées aux règles XML vers JSON
La règle XML vers JSON a été améliorée avec les fonctionnalités suivantes. Vous pouvez configurer cette règle pour:
- Lors de la conversion, traitez certains éléments XML comme des tableaux. Pour ce faire, placez les valeurs entre crochets "[ ]" dans le document JSON.
- Supprimer ou supprimer des niveaux de la hiérarchie des documents XML dans le document JSON final.
Pour en savoir plus, consultez la section Règle XML vers JSON. (APIRT-1144).
Plusieurs caractères génériques dans les chemins de ressources des produits d'API
Lorsque vous définissez des chemins d'accès aux ressources dans un produit d'API, vous pouvez inclure des caractères génériques à plusieurs endroits dans un chemin de ressource. Par exemple, /team/*/invoices/** autorise les appels d'API avec une valeur après /team et tous les chemins d'accès aux ressources après invoices/. Voici un exemple d'URI autorisé pour un appel d'API : proxyBasePath/team/finance/invoices/company/a.
Après cette version, si les chemins d'accès aux ressources de produits d'API existants cessent de fonctionner comme prévu, définissez la propriété suivante dans votre organisation afin de rétablir le comportement précédent: features.enableStandardWildCardMatchForAPIProductResources = true
(MGMT-3273)
Fonctions de chiffrement en JavaScript
Un nouvel ensemble de fonctions JavaScript crypto hautes performances est disponible pour créer, obtenir et mettre à jour les objets suivants: MD5, SHA-1, SHA256 et SHA512.
L'objet crypto vous permet également d'obtenir la date dans différents formats. Pour en savoir plus, consultez la page Modèle d'objet JavaScript.
(APIRT-2886).
Vérification de la version JAR de l'accroche Java
Lors de l'importation d'une ressource JAR Java vers un proxy d'API, un code d'état HTTP 400 est renvoyé (au lieu d'un code 500) si la version de la ressource Java est incompatible avec la version de Java compatible avec Edge, répertoriée dans Logiciels et versions compatibles. (MGMT-3420)
Validation des ressources proxy d'API
Lorsque des fichiers de ressources de proxy d'API (tels que des fichiers JavaScript ou JAR Java) sont stockés au niveau de l'environnement ou de l'organisation, le framework de validation ne vous oblige plus à inclure ces ressources au niveau du proxy d'API dans un groupe de proxys pour que l'importation réussisse la validation. La validation des ressources s'effectue désormais au moment du déploiement et non lors de l'importation. (MGMT-1430)
Configurer le délai avant expiration pour les proxys d'API individuels
Vous pouvez configurer les proxys d'API pour qu'ils expirent après un délai spécifié (avec un état de délai d'expiration de la passerelle 504). Le cas d'utilisation principal concerne les clients de cloud privé dont l'exécution prend plus de temps que les proxys d'API. Par exemple, supposons que vous ayez besoin que des proxys spécifiques expirent au bout de trois minutes. Vous pouvez utiliser une nouvelle propriété api.timeout dans la configuration d'un proxy d'API. Voici comment procéder avec cet exemple de trois minutes:
- Assurez-vous d'abord de configurer l'équilibreur de charge, le routeur et le processeur de messages pour qu'ils expirent au bout de trois minutes.
- Configurez ensuite les proxys appropriés pour qu'ils expirent au bout de trois minutes. Spécifiez la valeur en millisecondes. Exemple :
<ProxyEndpoint name="default"> <HTTPProxyConnection> <BasePath>/v1/weather</BasePath> <Properties> <!-- api.timeout is in milliseconeds --> <Property name="api.timeout">180000</Property> </Properties> ... - Notez toutefois que l'augmentation des délais avant expiration du système peut entraîner des problèmes de performances, car tous les proxys sans paramètre api.timeout utilisent les nouveaux délais d'inactivité pour l'équilibreur de charge, le routeur et le processeur de messages, plus élevés. Configurez donc d'autres proxys d'API qui ne nécessitent pas de délais d'inactivité plus longs pour utiliser des délais d'inactivité inférieurs. Par exemple, la commande suivante définit un proxy d'API pour qu'il expire après une minute:
<Property name="api.timeout">60000</Property>
Les clients Cloud, qui ne peuvent pas modifier les délais avant expiration Edge, peuvent également configurer un délai avant expiration du proxy d'API, à condition que celui-ci soit inférieur au délai avant expiration du processeur de messages Edge standard de 57 secondes.
Vous ne pouvez pas renseigner la valeur avec une variable. Cette propriété est abordée dans la documentation de référence sur les propriétés des points de terminaison. (APIRT-1778).
TLS/SSL pour les règles de journalisation des messages
<KeyStore> et <TrustStore> peuvent être définis dans la configuration SSLInfo de la règle de journalisation des messages, ce qui autorise les protocoles TLS/SSL unidirectionnels avec un service de journalisation. La configuration de SSLInfo sur la règle de journalisation des messages s'effectue de la même manière que sur un proxy
TargetEndpoint. Toutefois, Message Logging TLS/SSL n'est compatible qu'avec le protocole TCP.
(APIRT-1858)
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 |
|---|---|
| SECENG-609 | Les appels d'exécution n'échouent pas pendant la suppression du magasin de confiance associé ou lorsque le certificat valide du magasin de confiance est supprimé |
| MGMT-3404 | L'affichage et la récupération des journaux Node.js et le déploiement de proxys sont très lents |
| MGMT-3400 | L'appel à l'API de gestion /userroles échoue si le nom de l'utilisateur qui effectue cet appel est précédé d'un signe "+" |
| MGMT-3368 | java.lang.ArrayIndexOutOfBoundsException: 1, lors de l'importation d'un groupe de proxys d'API contenant le répertoire resources/node/resources |
| MGMT-3364 | OAuthV2: vérification redirect_uri |
| MGMT-3319 | Lister les entrées d'un coffre-fort dont l'une d'elles contient une valeur nulle ne fonctionne pas pour les organisations (CPS et non-CPS) |
| MGMT-3226 | L'interrogation au niveau de l'organisation/de l'environnement ne doit pas extraire toutes les données provoquant l'échec de l'API La version 160302 comportait un bug qui empêchait l'affichage de la liste des ressources au niveau de l'organisation/de l'environnement si la taille cumulée des ressources était supérieure à 16 Mo. Ce correctif s'en charge. |
| AXAPP-2429 | L'API Analytics qui utilise Response_status_code renvoie une erreur d'accès aux données |
| AXAPP-2386 | Corriger le contenu des rapports vides dans les rapports Analytics quotidiens envoyés par e-mail |
| AXAPP-2347 | Je ne reçois pas d'e-mails récapitulant quotidiennement les données analytiques |
| APIRT-3141 | Les appels Java échouent lors de l'appel de la nouvelle ExecutionResult() , car le constructeur est désormais privé |
| APIRT-3140 | La règle ServiceCall ne fonctionne pas dans les appels de l'API HEAD |
| APIRT-3131 | Erreur createBy affichée pour un proxy d'API lors de l'utilisation de la monétisation avec un fournisseur d'authentification externe |
| APIRT-3121 | Une modification apportée au fichier de ressources de l'organisation n'est pas efficace à 100% |
| APIRT-3117 | MP a atteint 100% d'utilisation du processeur et a cessé de diffuser le trafic |
| APIRT-3016 | Erreurs "Call timed out" (Expiration du délai d'appel) du routeur lors des déploiements |
| APIRT-2975 | Échec de l'importation du groupe de certificats |
| APIRT-2955 | Impossible de masquer certains attributs des données de réponse JSON pour l'en-tête de type de contenu FHIR-complaint "application/json+fhir" |
| APIRT-2946 | La règle OAuthV2-RefreshToken ne masque pas les attributs, même si l'affichage est défini sur "false" |
| APIRT-2908 | L'application de TLS 1.2 pour les appels d'API internes est requise après la mise à jour de TLS 1.2 sur l'hôte virtuel. |
| APIRT-2901 | Les réponses compressées avec Gzip renvoyées depuis le cache sont compressées en double |
| APIRT-2873 | Les MP génèrent une exception NullPointerException liée à VerifyAPIKey après la suppression de produits/développeurs/proxys |
| APIRT-2871 | Règles IOIntensive apparaissant deux fois dans Trace |
| APIRT-2825 | Erreur grammaticale dans la réponse d'erreur du jeton d'accès |
| APIRT-2750 | Échecs de trafic fréquents dans une organisation spécifique |
| APIRT-2685 | Le trafic ne peut pas circuler, car une erreur inconnue est générée |
| APIRT-2647 | Erreur "Le flux d'entrée sous-jacent renvoie zéro octet" avec nonprod/dev |
| APIRT-2630 | Problèmes intermittents lors des tentatives de lecture de la valeur du cache |
| APIRT-2620 | Pool de threads distinct pour certaines étapes de blocage |
| APIRT-2610 | java.lang.ClassCastException avec stratégie de cache de réponse |
| APIRT-2608 | Erreur d'analyse des en-têtes Last-Modified dans les stratégies de cache de réponse |
| APIRT-2605 | Les variables"organisation" et "environnement" ne doivent pas être remplacées via des règles |
| APIRT-2566 | La règle OAuthV2 renvoie un en-tête WWW-Authenticate incorrect |
| APIRT-2491 | Échec de la mise à jour de TargetServer en raison du délai avant expiration du RPC entre la gestion et les MP |
| APIRT-2386 | Un champ d'application de chaîne vide est créé dans un produit d'API avec un champ d'application OAuth autorisé vide |
| APIRT-2383 | Les stratégies de transformation XSL ne semblent consigner aucune donnée en cas d'erreur |
| APIRT-2364 | Les variables de flux de défaillance OAuth ne sont pas mises à jour en cas d'erreur |
| APIRT-2216 | Événements envoyés par le serveur – Flux d'événements présentant des problèmes en production |
| APIRT-2079 | L'appel cURL de débogage ne s'arrête pas après l'expiration du délai pour la session créée |
| APIRT-1495 | La protection contre les menaces XML n'intercepte pas le type de contenu |
| APIRT-347 | La stratégie XSL n'est pas correctement validée à l'importation (elle n'affecte pas les résultats aux variables de sortie comme indiqué) |