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

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 règles Assign Message 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. Les variables peuvent être spécifiées à l'aide d'accolades sans créer de 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 des variables.

Consultez l'élément <Set><Payload> dans les documents de référence sur les règles Assign Message et Raise Fault. (APIRT-1160)

Améliorations de 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 :

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

Pour en savoir plus, consultez la section XML vers JSON. (APIRT-1144)

Caractères génériques multiples dans les chemins d'accès aux 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 d'accès aux ressources. Par exemple, /team/*/invoices/** autorise les appels d'API avec une seule valeur après /team et tous les chemins d'accès aux ressources après invoices/. Un URI autorisé sur un appel d'API serait être proxyBasePath/team/finance/invoices/company/a.

Si, après cette version, les chemins d'accès aux ressources de vos produits d'API existants ne fonctionnent plus comme prévu, définissez la propriété suivante dans votre organisation pour revenir au comportement précédent : features.enableStandardWildCardMatchForAPIProductResources = true

(MGMT-3273)

Fonctions de cryptographie en JavaScript

Un nouvel ensemble de fonctions JavaScript hautes performances crypto est disponible pour créer, obtenir et mettre à jour les objets de hachage suivants : MD5, SHA-1, SHA256, SHA512. L'objet cryptographie vous permet également d'obtenir la date dans différents formats. Pour en savoir plus, consultez la section 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 Java compatible avec Edge, répertorié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 JavaScript ou JAR 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 réussisse la validation. La validation des ressources a désormais lieu au moment du déploiement, et non au moment de l'importation. (MGMT-1430)

Configurer le délai d'inactivité pour des proxy 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. Supposons, par exemple, que vous ayez besoin que des proxys spécifiques expirent au bout de trois minutes. Vous pouvez utiliser une nouvelle api.timeout propriété 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 après 3 minutes.
2. Configurez ensuite les proxys concerné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>
       ...

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 renseigner 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)

TLS/SSL pour la règle 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 permet d'utiliser TLS/SSL unidirectionnel et bidirectionnel avec un service de journalisation. Vous configurez SSLInfo sur la règle de journalisation des messages de la même manière que vous sur un TargetEndpoint de proxy TargetEndpoint. Toutefois, 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.