16.08.17 - Notes de version d'Apigee Edge pour le cloud public

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur 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 Message and Raise Fault

Avec cette amélioration, aucune solution de secours n'est nécessaire pour garantir un formatage correct des messages JSON. peuvent être spécifiées à l'aide d'accolades sans créer de fichier JSON non valide. Par exemple, La commande 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 de fonctionner en l'état. Vous pouvez également utiliser variablePrefix et variableSuffix au lieu d'accolades pour indiquer des variables.

Voir le <Set><Payload> dans la règle Attribuer un message et Règle Lever la défaillance des documents de référence. (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 la règle pour:

• Traiter certains éléments XML comme des tableaux lors de la conversion (les valeurs seront alors carrées) crochets '[ ]' dans le document JSON.
• Supprimez ou supprimez des niveaux de la hiérarchie des documents XML dans le document JSON final.

Pour en savoir plus, consultez la page XML à la stratégie JSON. (APIRT-1144)

Plusieurs caractères génériques dans Chemins de ressources de produit d'API

Lorsque vous définissez des chemins d'accès aux ressources dans le produit API, vous pouvez inclure des caractères génériques à plusieurs endroits dans un chemin d'accès à la ressource. Par exemple, /team/*/invoices/** autorise les appels d'API avec n'importe quelle Une valeur après /team et tous les chemins d'accès aux ressources après le invoices/. Un URI autorisé dans un appel d'API être proxyBasePath/team/finance/invoices/company/a.

Si, après cette version, les chemins d'accès aux ressources de votre produit d'API existants cessent de fonctionner comme prévu, définissez la propriété suivante de votre organisation pour revenir à la version précédente comportement: 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, SHA512. L'objet crypto vous permet également d'obtenir dans divers formats. Pour en savoir plus, consultez la page Modèle d'objet JavaScript. (APIRT-2886)

Version JAR d'accroche Java en cours de vérification

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 500) si la version de la ressource Java est incompatible avec la version de Java, répertoriée dans la section Logiciels et versions compatibles. (MGMT-3420)

Validation des ressources de proxy d'API

Lorsque des fichiers de ressources de proxy d'API (tels que des fichiers JAR JavaScript ou Java) sont stockés dans la d'environnement ou d'organisation, le framework de validation ne vous oblige plus inclure ces ressources au niveau du proxy de l'API dans un bundle de proxy pour que l'importation réussisse la validation. La validation des ressources s'effectue désormais au moment du déploiement, et non au moment 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 délai avant expiration de la passerelle 504) état actuel). Le cas d'utilisation principal concerne les clients de cloud privé qui disposent de proxys d'API plus de temps à exécuter. Par exemple, supposons que vous ayez besoin de proxys spécifiques pour qu'ils expirent au bout de trois minutes. Vous pouvez utilisez une nouvelle propriété api.timeout dans la configuration d'un proxy d'API. Voici comment procéder : dans l'exemple de 3 minutes:

1. Assurez-vous d'abord de configurer l'équilibreur de charge, le routeur et le processeur de messages pour qu'ils expirent au bout de 3 minutes.
2. Configurez ensuite les proxys appropriés pour qu'ils expirent au bout de trois minutes. Spécifiez la valeur dans millisecondes. Exemple :

   <ProxyEndpoint name="default">
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath> 
       <Properties> 
         <!-- api.timeout is in milliseconeds -->
         <Property name="api.timeout">180000</Property>
       </Properties>
       ...

3. Notez toutefois que l'augmentation des délais d'expiration du système peut entraîner des problèmes de performances, car Tous les proxys sans paramètre "api.timeout" utilisent le nouvel équilibreur de charge, le nouveau routeur et les délais avant expiration du processeur de messages. Configurez donc d'autres proxys d'API qui ne nécessitent pas de délais avant expiration plus longs. d'utiliser des délais avant expiration plus bas. Par exemple, ce qui suit définit un proxy d'API pour qu'il expire après 1 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 de proxy API, tant que le délai avant expiration est inférieur au délai d'expiration standard du processeur de messages Edge de 57 secondes.

Vous ne pouvez pas renseigner la valeur avec une variable. Cette propriété est couverte par Documentation de référence sur les propriétés des points de terminaison (APIRT-1778).

TLS/SSL pour la journalisation des messages Règles

<KeyStore> et <TrustStore> peuvent être définis dans le Configuration SSLInfo sur la règle de journalisation des messages autorisant TLS/SSL uni et bidirectionnel avec un service de journalisation. Pour configurer SSLInfo sur la règle de journalisation des messages, procédez de la même manière que le ferait sur un proxy Point de terminaison cible. Toutefois, la journalisation des messages 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.