4.15.07.00 : notes de version d'Apigee Edge pour le cloud privé

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Le mardi 8 septembre 2015, nous avons lancé une version majeure de fonctionnalités d'Apigee Edge pour un cloud privé.

Depuis la précédente version trimestrielle d'Edge pour le cloud privé (4.15.04.00), les versions suivantes ont été publiées et sont incluses dans cette version trimestrielle:

• Cloud: 15.04.15, 15.04.29, 15.05.27, 15.06.10 et 15.06.24
• Private Cloud: 4.15.04.01

Versions d'Edge vers lesquelles vous pouvez effectuer la mise à niveau : 4.15.07.00

Selon la version actuelle d'Edge, vous pouvez:

• Passer directement à la version 4.15.07.00
• Mise à niveau incrémentielle, ce qui signifie que vous devez passer de votre version actuelle à une autre version d'Edge, puis passer à la version 4.15.07.00.

Pour en savoir plus, consultez Quelles versions d'Edge pour le cloud privé pouvez-vous mettre à niveau vers la version 4.15.07.00 ?

Avant de passer à la version 4.15.01.x ou à une version antérieure

1. Vérifiez la version de la table SS de Cassandra :
   1. Définissez le répertoire sur /<install-root>/apigee4/data/cassandra/data.
   2. Exécutez une commande de recherche,
      > find . -name *-ic-*
      Les résultats devraient renvoyer un ensemble de fichiers .db si vous exécutez SSTable Cassandra 1.2.
   3. Exécutez cette commande de recherche:
      > find . -name *-hf-*
      Les résultats doivent être vides, ce qui signifie qu'aucun fichier .db n'est au format hf. Si aucun fichier au format hf ne s'affiche, vous avez terminé et pouvez passer à la version 4.15.07.00.
      
      Le format hf est destiné aux SSTables Cassandra 1.0. Si vous disposez de fichiers *.db au format hf, vous devez mettre à niveau SSTable comme décrit dans la suite de cette procédure.
2. Si vous trouvez des fichiers *.db au format hf, mettez à niveau SSTable en exécutant la commande suivante sur chaque nœud Cassandra jusqu'à ce que vous ayez mis à niveau tous les nœuds Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a
3. Répétez l'étape 1 pour vérifier que tous les fichiers *.db sont au format ic pour la version Cassandra 1.2.
4. Répétez les étapes 1 à 3 sur chaque nœud Cassandra de votre installation Edge.
5. Passez à Edge 4.15.07.00.
6. Après la mise à niveau vers la version 4.15.07.00, vérifiez les fichiers *.db pour vous assurer qu'ils ont tous été mis à niveau vers la version stable de style C* 2.0:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   Cette commande doit renvoyer un ensemble de fichiers .db si vous exécutez Cassandra 2.0.

Nouvelles fonctionnalités et améliorations

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Installation et mise à niveau

Mise à niveau et désinstallation sélectives des composants

Les scripts apigee-upgrade.sh et apigee-uninstall.sh vous permettent désormais de sélectionner les composants Edge à mettre à niveau ou à désinstaller. Auparavant, il mettait à niveau ou désinstallait tous les composants du nœud. (OPDK-1377, OPDK-1175)

Rollback de la mise à niveau

Si le script apigee-upgrade.sh échoue lors d'une mise à niveau, vous pouvez désormais utiliser le script apigee-rollback.sh pour annuler la mise à niveau. Une fois les problèmes de mise à niveau résolus, vous pouvez réessayer. (OPDK-1275)

Options de script d'installation abrégées

Les scripts d'installation n'acceptent plus les options longues, telles que --help. Elles n'acceptent désormais que des options à une seule lettre, comme -h. (OPDK-1356)

Installation de SmartDocs

Lorsque vous installez SmartDocs avec le script setup-smartdocs.sh, vous êtes invité à saisir l'organisation, l'environnement et l'hôte virtuel, ce qui garantit que SmartDocs est installé à l'emplacement prévu. Auparavant, ces valeurs étaient codées en dur dans le script. (OPDK-1310)

Exécuter update-cass-pwd-in-config.sh sans invite

Le script update-cass-pwd-in-config.sh peut s'exécuter sans invite si vous définissez les variables d'environnement ENABLE_CASS_AUTH, CASS_USERNAME et CASS_PASSWORD. (OPDK-1309)

Plate-forme Edge

Vous trouverez ci-dessous les nouvelles fonctionnalités de la plate-forme Edge incluses dans cette version.

OpenJDK 1.7 compatible avec le cloud privé Edge

Cette version d'Edge est compatible avec Oracle JDK 1.7 et OpenJDK 7, et n'est plus compatible avec JDK 1.6. (OPDK-1187)

OS compatibles

Apigee Edge pour le cloud privé a étendu la compatibilité de son système d'exploitation pour inclure Red Hat Enterprise Linux 6.6 et 7.0 (64 bits), CentOS 6.5, 6.6 et 7.0 (64 bits) et Oracle Linux 6.5.

Cassandra 2.0.15 inclus dans OPDK 15.07

Cette version installe Cassandra 2.0.15. Si vous effectuez une mise à niveau à partir d'une version précédente, votre version de Cassandra sera mise à jour. (OPDK-1197)

Prise en charge de SHA2 pour le hachage des jetons OAuth

Pour mieux protéger les jetons OAuth en cas de violation de la sécurité de la base de données, Edge prend en charge les algorithmes SHA2 pour le hachage des jetons OAuth (en plus de SHA1). Avec les nouvelles propriétés au niveau de l'organisation, vous pouvez activer et configurer le hachage pour les nouveaux jetons, tout en conservant l'ancien hachage pour tous les jetons qui existaient avant cette nouvelle fonctionnalité. Auparavant, dans Edge pour Private Cloud, une propriété appelée hash.oauth.tokens.enabled dans le fichier keymanagement.properties (sur votre serveur de gestion et vos processeurs de messages) activait le hachage SHA1 automatique des jetons OAuth. Cette propriété est désormais obsolète.

Si vous utilisiez auparavant la propriété hash.oauth.tokens.enabled pour activer le hachage SHA1, le script de mise à niveau de cette version génère automatiquement les nouvelles propriétés au niveau de l'organisation. Pour vérifier après la mise à niveau, effectuez une requête GET en tant qu'administrateur système avec cette API : https://{host}:{port}/v1/o/{your_org}.

• Pour savoir comment activer le hachage des jetons dans votre organisation avec les nouvelles propriétés, consultez la section "Hachage des jetons dans la base de données" de la rubrique Demander des jetons d'accès.
• Pour en savoir plus sur le hachage groupé des jetons existants, consultez le guide des opérations Edge pour le cloud privé. (APIRT-1389)

Structure de répertoire plate pour les fichiers journaux

Vous pouvez configurer Edge pour stocker les fichiers journaux dans une structure de répertoire plate en définissant une nouvelle propriété enable.flat.directory.structure sur "true" dans le fichier message-logging.properties. Pour en savoir plus, consultez la page Règle MessageLogging. (APIRT-1394)

Performances du cache de l'environnement

Pour une meilleure gestion et utilisation du cache en mémoire, les paramètres "Éléments maximum en mémoire" sur les ressources de cache de l'environnement sont obsolètes. Le nombre total d'éléments présents dans toutes les ressources de cache (y compris le cache par défaut) dépend de la mémoire totale allouée au cache. Par défaut, la mémoire totale allouée pour la mise en cache en mémoire sur un processeur de messages donné est de 40% de la mémoire totale disponible, déterminée par les paramètres de propriété de cache dans le fichier cache.properties de votre processeur de messages. Les éléments ne sont supprimés du cache en mémoire que lorsque la mémoire de cache est insuffisante ou que les éléments expirent.

Pour revenir à l'ancien comportement consistant à utiliser la propriété "Éléments maximum en mémoire" pour la gestion du cache, définissez la propriété overrideMaxElementsInCacheResource=false dans le fichier cache.properties. (APIRT-1140)

Services d'API

Vous trouverez ci-dessous les nouvelles fonctionnalités des services d'API incluses dans cette version.

Nouvel éditeur de proxys par défaut

Le nouvel éditeur de proxy d'API est activé par défaut dans l'UI de gestion. Le nouvel éditeur inclut de nombreuses améliorations de l'usabilité, y compris des vues plus complètes des flux conditionnels et des points de terminaison sur la page "Vue d'ensemble", toute la configuration sur la page "Développer", une ajout plus intuitif des flux conditionnels, des points de terminaison et des règles, des vues XML plus complètes plutôt que de petits extraits, une recherche qui explore les noms de fichiers et le texte, et plus encore. (MGMT-2279)

Nouvelle règle de suppression des informations OAuth v2.0

Une nouvelle règle "Supprimer les informations OAuth v2.0" vous permet de supprimer les jetons d'accès et les codes d'autorisation OAuth v2. La règle remplace les fonctionnalités précédemment fournies par l'API de gestion. Pour en savoir plus, consultez la section Règle de suppression des informations OAuthV2. (MGMT-2257)

Nouvelle règle de suppression des informations OAuth v1.0

Une nouvelle règle "Supprimer les informations OAuth v1.0" vous permet de supprimer les jetons de requête OAuth v1.0, les jetons d'accès et les codes de validation. La règle remplace les fonctionnalités précédemment fournies par l'API de gestion. Pour en savoir plus, consultez la section Supprimer la règle d'informations OAuth V1. (APIRT-1351)

Règle de contrôle des accès

La règle de contrôle des accès a été améliorée pour permettre une évaluation plus précise des adresses IP pour les listes d'autorisation et de refus lorsque les adresses IP sont contenues dans l'en-tête HTTP X-FORWARDED-FOR.

Lorsque la vérification de plusieurs adresses IP est activée dans l'en-tête (contactez l'assistance pour définir la fonctionnalité feature.enableMultipleXForwardCheckForACL), un nouvel élément <ValidateBasedOn> de la règle vous permet de vérifier la première adresse IP, la dernière adresse IP ou toutes les adresses IP de l'en-tête. Pour en savoir plus, consultez la section Règle de contrôle des accès.

Nouvelles entités dans la règle d'entité des accès

La stratégie d'entité d'accès permet d'accéder aux nouvelles entités suivantes: consumerkey-scopes, authorizationcode, requesttoken et verifier. Pour en savoir plus, consultez la section Règle AccessEntity.

Règle StatisticsCollector: conversion automatique du nom des statistiques en minuscules

Lorsque vous créez une collection d'analyse personnalisée dans l'éditeur de proxy d'API (page "Développer" > "Outils" > "Collection d'analyse personnalisée"), la variable de collecteur (statistique) "Nom" doit être en minuscules. Si vous saisissez le nom en majuscules, l'outil convertit automatiquement le nom de la statistique en minuscules dans la règle StatisticsCollector. (MGMT-740)

Suppression de la trace classique dans l'éditeur de proxy d'API

La dernière version de la fonctionnalité Trace dans l'éditeur de proxy d'API est passée de la version bêta à la disponibilité générale. L'accès à la "trace classique" via le lien "Accéder à la version classique de la trace" n'est plus disponible.

Accès à la communauté Apigee depuis le menu d'aide de l'UI de gestion

Vous pouvez accéder à la communauté Apigee depuis le menu d'aide de l'interface utilisateur de gestion.

Messages d'erreur dans l'interface utilisateur de gestion

Voici les améliorations apportées aux messages d'erreur dans l'interface utilisateur de gestion:

• L'interface utilisateur de gestion regroupait et affichait tous les messages d'erreur dans l'interface utilisateur pendant toute la session de connexion, sauf si vous les ignoriez. Avec cette mise à jour, les messages d'erreur sont effacés automatiquement lorsque vous quittez la page sur laquelle ils sont apparus. (MGMT-2254)
• L'interface utilisateur de gestion ne supprime plus les messages d'erreur en double. (MGMT-2242)

Améliorations des performances et des erreurs de l'interface utilisateur

Des améliorations générales ont été apportées à différents domaines de l'interface utilisateur de gestion, y compris les performances d'affichage des pages et le nettoyage des messages d'erreur.

Hyperliens de rôle sur la page "Utilisateurs de l'organisation" dans l'UI de gestion

Sur la page "Utilisateurs de l'organisation" de l'interface utilisateur de gestion (Admin > Utilisateurs de l'organisation), les noms des rôles sont désormais associés à des liens hypertextes, ce qui vous permet d'accéder rapidement aux pages des rôles. (MGMT-1055)

Nouvelles variables cibles dans le flux de messages

Les nouvelles variables des flux de messages fournissent des informations d'URL plus complètes pour les points de terminaison et les serveurs cibles:

• TargetEndpoint: request.url remplace target.basepath.with.query.
• TargetServer: loadbalancing.targetserver remplace targetserver.name. De plus, target.basepath n'est renseigné que lorsque l'élément <Path> est utilisé dans l'élément <LoadBalancer> HTTPTargetConnection de TargetEndpoint.

Compatibilité avec l'indication du nom du serveur (SNI)

Edge prend en charge l'utilisation de l'indication du nom de serveur en direction du sud (du processeur de messages aux points de terminaison cibles). Si vous souhaitez utiliser SNI, contactez l'assistance Apigee.

Java 1.7 est requis.

Avec SNI, qui est une extension de TLS/SSL, plusieurs cibles HTTPS peuvent être diffusées à partir de la même adresse IP et du même port sans que toutes ces cibles aient besoin d'utiliser le même certificat.

Aucune configuration spécifique à Edge n'est requise. Si votre environnement est configuré pour le SNI southbound (par défaut pour le cloud Edge), Edge le prend en charge.

Edge extrait automatiquement le nom d'hôte de l'URL de la requête et l'ajoute à la requête de poignée de main SSL. Par exemple, si l'hôte cible est https://example.com/request/path, Edge ajoute l'extension server_name comme indiqué ci-dessous:

Pour en savoir plus sur le SNI, consultez la page http://en.wikipedia.org/wiki/Server_Name_Indication.

"Signature Algorithm" (Algorithme de signature) dans les détails des certificats SSL

Un nouveau champ "Signature Algorithm" (Algorithme de signature) a été ajouté aux détails du certificat SSL, visible dans l'UI de gestion (Admin > SSL Certificates) et dans l'API de gestion (Get Cert Details from a Keystore or Truststore). Le champ affiche "sha1WithRSAEncryption" ou "sha256WithRSAEncryption", en fonction du type d'algorithme de hachage utilisé pour générer le certificat.

Affichage des certificats SSL qui arrivent à expiration

La page "Certificats SSL" de l'interface utilisateur de gestion (Administration > Certificats SSL) indique quand les certificats SSL expirent dans un délai de 10, 15, 30 ou 90 jours, en fonction de votre sélection dans le champ déroulant "Nouvelle date d'expiration".

Configuration des erreurs de protection contre les menaces

Par défaut, Edge génère un code d'état HTTP 500 indiquant une erreur interne du serveur et un code d'erreur ExecutionFailed si un message ne respecte pas une règle de protection contre les menaces JSON ou XML. Vous pouvez modifier ce comportement en utilisant une nouvelle propriété au niveau de l'organisation. Lorsque vous définissez la propriété d'organisation features.isPolicyHttpStatusEnabled sur "true", le comportement suivant se produit:

• Requête: avec une règle de protection contre les menaces associée à un flux de requêtes, les messages non valides renvoient un code d'état 400, ainsi qu'un message d'erreur de règle correspondant.
• Réponse: avec une règle de protection contre les menaces associée à un flux de réponses, les messages non valides renvoient toujours un code d'état 500, et l'un des messages d'erreur de règle correspondants est généré (plutôt que ExecutionFailed simplement).

Les clients Cloud doivent contacter l'assistance Apigee pour définir la propriété d'organisation. Cette fonctionnalité sera disponible pour les clients Edge Private Cloud lors de la prochaine version trimestrielle de Private Cloud.

Mise à jour des schémas pour les points de terminaison, les proxys et d'autres entités

Les schémas de référence ont été mis à jour pour les entités non liées aux règles, telles que TargetEndpoint, ProxyEndpoint, APIProxy et bien d'autres. Consultez la page https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Services pour les développeurs

Vous trouverez ci-dessous les nouvelles fonctionnalités des services pour les développeurs incluses dans cette version.

Disponibilité générale de SmartDocs

SmartDocs passe de la version bêta à la disponibilité générale. Voici les mises à jour et les nouvelles fonctionnalités:

• Compatibilité avec Swagger 2.0, y compris l'importation par fichier ou URL, y compris la compatibilité avec les objets de sécurité nommés de manière personnalisée.
• Améliorations de la conception visuelle dans les modèles qui génèrent des SmartDocs.
• Améliorations de l'usabilité et du workflow dans le portail des développeurs, disponibles dans le menu "Contenu > SmartDocs" de Drupal.
• L'authentification "Jeton personnalisé" s'appelle désormais "Clé API".
• Objets "sécurité" d'authentification définis au niveau de la révision.
• Configuration de l'authentification du client au niveau du modèle. Les nouvelles révisions ne réinitialisent plus les identifiants client SmartDocs préconfigurés.

Pour en savoir plus sur les fonctionnalités, consultez cet article de blog.

Pour en savoir plus sur SmartDocs, consultez Utiliser SmartDocs pour documenter les API.

Nom de l'application du développeur affiché dans l'UI de gestion

Les applications de développeur dans Edge ont un nom interne qui ne change pas et un nom à afficher que vous pouvez modifier. Sur une page d'application de développeur dans l'UI de gestion (Publier > Applications de développeur > nom de l'application), le nom interne de l'application s'affiche avec le nom à afficher, ce qui permet d'identifier plus facilement les applications par leur nom interne pour le dépannage et la gestion des API.

Services d'analyse

Vous trouverez ci-dessous les nouvelles fonctionnalités des services Analytics incluses dans cette version.

Durée limite de conservation des données

Lorsque vous générez des rapports d'analyse avec l'UI ou l'API de gestion, les données de plus de six mois à compter de la date du jour ne sont pas accessibles par défaut. Si vous souhaitez accéder à des données de plus de six mois, contactez l'assistance Apigee.

Suppression de la version classique des rapports personnalisés de l'interface utilisateur de gestion

La version classique facultative des rapports d'analyse personnalisés n'est plus disponible dans l'UI de gestion.

Performances du widget "Engagement des développeurs"

Le widget d'entonnoir du tableau de bord d'analyse principal (section "Engagement des développeurs") a été amélioré pour améliorer les performances.

Monétisation

Vous trouverez ci-dessous les nouvelles fonctionnalités de monétisation incluses dans cette version.

Notifications par e-mail sur les plans tarifaires

Un nouveau type de notification par e-mail pour les forfaits tarifaires vous permet d'informer les développeurs lorsqu'ils atteignent une certaine limite de transactions ou de montant dans les forfaits tarifaires basés sur le volume ou les forfaits groupés qu'ils ont achetés. Pour en savoir plus, consultez Configurer des notifications à l'aide de modèles de notification.

Synchronisation des périodes de frais récurrents et de base d'agrégation

Dans un forfait, deux périodes différentes étaient potentiellement en vigueur:

• Période des frais récurrents, configurée dans l'onglet "Frais" d'un plan tarifaire, qui déterminait quand les développeurs devaient payer des frais récurrents.
• Période de base d'agrégation, définie sur la grille tarifaire des forfaits Volume Banded ou Bundles, qui détermine quand l'utilisation des bundles est réinitialisée pour les développeurs.

Ces deux périodes sont maintenant synchronisées. Lorsqu'une offre tarifaire comprend à la fois des frais récurrents non nuls et une grille tarifaire basée sur le volume ou un forfait, la période des frais récurrents est utilisée pour les deux. Par exemple, si des frais récurrents mensuels existent, les forfaits de la fiche tarifaire sont également réinitialisés chaque mois (par défaut au début du mois).

Si aucuns frais récurrents ne sont associés, les forfaits sont réinitialisés en fonction de la base d'agrégation définie sur la fiche tarifaire. Par exemple, si un développeur commence à utiliser une grille tarifaire le 19 du mois et que la base d'agrégation est mensuelle, l'utilisation du lot est réinitialisée un mois après le 19.

La base d'agrégation est obsolète et sera supprimée de la monétisation dans une prochaine version. Pour en savoir plus, consultez Spécifier les détails du plan tarifaire.

Attributs personnalisés dans les rapports récapitulatifs sur les revenus

Les règles d'enregistrement des transactions vous permettent d'enregistrer des données d'attributs personnalisés à partir des transactions. Vous pouvez désormais inclure ces attributs de transaction personnalisés dans les rapports récapitulatifs sur les revenus. En ajoutant une propriété MINT.SUMMARY_CUSTOM_ATTRIBUTES à votre organisation, vous pouvez indiquer les attributs personnalisés à ajouter aux tables de base de données pour les utiliser dans les rapports.

Les clients Apigee Edge for Private Cloud peuvent définir l'indicateur avec l'appel d'API suivant et les identifiants d'administrateur système.

curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isMonetizationEnabled">true</Property>
        <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

Notez que le tableau d'attributs personnalisés dans l'appel d'API est encodé au format URL.

Processus de mise à niveau de SmartDocs

Si vous utilisiez déjà SmartDocs pendant la période bêta, vous devez mettre à niveau SmartDocs dans votre portail pour les développeurs pour profiter des nouvelles fonctionnalités de la version disponible pour tous.

Les pages SmartDocs déjà publiées dans votre portail pour les développeurs continueront de fonctionner, mais vous devez suivre la procédure de mise à jour avant de modifier ou de publier des modifications apportées à des pages existantes ou nouvelles.

N'oubliez pas que, même si vous pouvez afficher et publier des SmartDocs dans votre portail des développeurs, ils sont générés à partir du modèle d'API qui se trouve dans les services de gestion des API Edge d'Apigee. Toutes les modifications que vous apportez à un modèle d'API dans Edge seront les mêmes dans tous vos environnements Pantheon (comme les développeurs dans les environnements Pantheon).

Passer de la version bêta de SmartDocs à la version disponible pour tous les utilisateurs

1. Mettez à jour et testez la version 15.05.27 dans vos environnements dev ou test sur Pantheon.
2. Créez un modèle pour remplacer tout modèle d'API existant que vous utilisiez.
   • Si vous avez importé des documents Swagger ou WADL, importez-les à nouveau dans une nouvelle révision.
   • Si vous avez géré votre modèle d'API via le module SmartDocs, exportez-le au format JSON SmartDocs, puis importez-le dans votre nouveau modèle à l'aide d'une pièce jointe.
3. Définissez les propriétés de sécurité de la version de votre modèle. Sur la page Contenu > SmartDocs > modèle, sélectionnez Paramètres de sécurité.
   
4. Vérifiez toute authentification préconfigurée sur la page des paramètres du modèle (Contenu > SmartDocs) en cliquant sur Paramètres dans la colonne "Opérations".
   
5. Mettez à jour les modèles personnalisés pour qu'ils utilisent la version 6 des composants CSS et JS, et apportez les modifications nécessaires pour refléter les nouveaux noms d'objets, tels que authSchemes et apiSchema. Pour savoir comment mettre à jour des modèles SmartDocs, consultez Utiliser SmartDocs pour documenter des API.
6. Réaffichez et publiez la version de votre modèle.
7. Après avoir validé la nouvelle documentation, mettez à jour votre portail de production vers la version 15.05.27.

Si vous êtes un client Edge Enterprise et que vous avez des questions ou des préoccupations concernant le processus de mise à niveau, veuillez envoyer un e-mail à marsh@apigee.com et cnovak@apigee.com. Sinon, veuillez utiliser la communauté Apigee pour obtenir la meilleure réponse.

Modifications et améliorations futures des fonctionnalités

Cette section présente les modifications et améliorations de fonctionnalités à venir:

Modifier le comportement de la règle de cache de réponses

Dans une prochaine version (à déterminer), le comportement par défaut de l'élément <ExcludeErrorResponse> de la règle ResponseCache changera.

Comportement actuel:l'élément <ExcludeErrorResponse> de la règle de mise en cache des réponses est défini sur "false" par défaut. Cela signifie que, par défaut, les réponses avec n'importe quel code d'état HTTP possible (y compris 3xx) sont mises en cache par la règle Response Cache.

Comportement futur:la valeur par défaut de l'élément <ExcludeErrorResponse> dans la règle ResponseCache sera "true". Cela signifie que, par défaut, seules les réponses avec les codes d'état HTTP de 200 à 205 seront mises en cache. Pour remplacer ce comportement et mettre en cache les réponses pour tous les codes d'état, vous devez définir explicitement l'élément <ExcludeErrorResponse> sur "true".

Solution de contournement actuelle : pour Private Cloud 4.15.07.00 et les versions antérieures, si vous souhaitez mettre en cache uniquement les réponses avec les codes d'état de 200 à 205, vous devez définir explicitement l'élément <ExcludeErrorResponse> sur "true".

Bugs résolus

Les bugs suivants sont résolus dans cette version.

Problèmes connus

Cette version présente les problèmes connus suivants.

> source /{install-dir}/apigee4/bin/apigee-env.sh 

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4` 

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh 

> rm /install-dir/apigee4/share/monetization 

************************************** 
In order to complete the monetization upgrade please run: 
sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/
365-create-notification-condition.sh 
************************************** 

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart