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

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

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 les messages "Assign" et "Raise Fault"

Grâce à cette amélioration, aucune solution de contournement n'est nécessaire pour garantir la mise en forme correcte des messages JSON. De plus, les variables 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 tel quel. Vous pouvez également utiliser variablePrefix et variableSuffix au lieu d'accolades pour indiquer les variables.

Consultez l'élément <Set><Payload> dans les documents de référence sur la règle AssignMessage et la règle RaiseFault. (APIRT-1160)

Améliorations apportées à la règle 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 :

• Traitez certains éléments XML comme des tableaux lors de la conversion, ce qui place les valeurs entre crochets "[ ]" dans le document JSON.
• Supprime ou élimine des niveaux de la hiérarchie du document XML dans le document JSON final.

Pour en savoir plus, consultez Règle XML vers JSON. (APIRT-1144)

Plusieurs caractères génériques dans les chemins d'accès aux ressources des produits d'API

Lorsque vous définissez des chemins de 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 n'importe quelle valeur après /team et n'importe quel chemin de ressource après invoices/. Un URI autorisé lors d'un appel d'API serait proxyBasePath/team/finance/invoices/company/a.

Si, après cette version, les chemins d'accès aux ressources de vos produits API existants ne fonctionnent plus comme prévu, définissez la propriété suivante sur votre organisation pour revenir au 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 de hachage suivants : MD5, SHA-1, SHA256, 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'appel Java

Lorsque vous importez une ressource JAR Java dans un proxy d'API, un code d'état HTTP 400 est renvoyé (au lieu de 500) si la version de la ressource Java n'est pas compatible avec la version de Java acceptée par Edge, listée dans Logiciels et versions compatibles. (MGMT-3420)

Validation des ressources de proxy d'API

Lorsque vous stockez des fichiers de ressources de proxy d'API (tels que des fichiers JAR JavaScript ou Java) au niveau de l'environnement ou de l'organisation, le framework de validation ne vous oblige plus à inclure également ces ressources au niveau du proxy d'API dans un bundle de proxy pour que l'importation soit validée. La validation des ressources a désormais lieu au moment du déploiement, et non de l'importation. (MGMT-1430)

Configurer le délai d'inactivité pour des proxys d'API individuels

Vous pouvez configurer des proxys d'API pour qu'ils expirent au bout d'une période spécifiée (avec un état 504 Gateway Timeout). Le principal cas d'utilisation est destiné aux clients de cloud privé qui disposent de proxys d'API dont l'exécution prend plus de temps. Par exemple, supposons que vous ayez besoin que des proxys spécifiques dépassent le délai 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 l'exemple de trois minutes :

1. Commencez par configurer l'équilibreur de charge, le routeur et le processeur de messages pour qu'ils dépassent le délai au bout de trois minutes.
2. Configurez ensuite les proxys concernés pour qu'ils dépassent le délai 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>
       ...

3. Notez toutefois que l'augmentation des délais d'inactivité 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é plus élevés de l'équilibreur de charge, du routeur et du processeur de messages. Configurez donc d'autres proxys d'API qui ne nécessitent pas de délais d'inactivité plus longs afin d'utiliser des délais d'inactivité plus courts. Par exemple, la commande suivante définit le délai d'inactivité d'un proxy d'API au bout d'une minute :
   <Property name="api.timeout">60000</Property>

Les clients Cloud, qui ne peuvent pas modifier les délais d'inactivité Edge, peuvent également configurer un délai d'inactivité du proxy d'API, tant que ce délai est inférieur au délai d'inactivité du processeur de messages Edge standard de 57 secondes.

Vous ne pouvez pas remplir la valeur avec une variable. Cette propriété est décrite dans la documentation de référence sur les propriétés des points de terminaison. (APIRT-1778)

Règle TLS/SSL pour la journalisation des messages

<KeyStore> et <TrustStore> peuvent être définis dans la configuration SSLInfo de la règle de journalisation des messages, ce qui permet d'utiliser TLS/SSL unidirectionnel et bidirectionnel avec un service de journalisation. Vous configurez SSLInfo dans la règle Message Logging de la même manière que dans un TargetEndpoint de proxy. Toutefois, le protocole TLS/SSL de la journalisation des messages 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.