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

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

Le mardi 8 septembre 2015, nous avons lancé une version majeure d'Apigee Edge pour Private Cloud.

Depuis la précédente version trimestrielle d'Edge pour Private Cloud (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
• Cloud privé : 4.15.04.01

Quelles versions d'Edge pouvez-vous mettre à niveau vers la version 4.15.07.00 ?

Selon votre version actuelle d'Edge, vous pouvez :

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

Pour en savoir plus, consultez Quelles versions d'Edge for Private Cloud pouvez-vous mettre à niveau vers la version 4.15.07.00.

Avant de passer de la version 4.15.01.x ou d'une version antérieure à une version plus récente

1. Vérifiez la version de Cassandra SSTable :
   1. Accédez au répertoire /<install-root>/apigee4/data/cassandra/data.
   2. Exécutez une commande de recherche,
      > find . -name *-ic-*
      Les résultats doivent renvoyer un ensemble de fichiers .db si vous exécutez Cassandra 1.2 SSTable.
   3. Exécutez la commande find suivante :
      > find . -name *-hf-*
      Les résultats doivent être vides, ce qui signifie qu'aucun fichier .db n'est au format hf. Si vous ne voyez aucun fichier au format hf, vous avez terminé et pouvez passer à la version 4.15.07.00.
      
      Le format hf est destiné aux SSTables Cassandra 1.0. Si vous avez des fichiers *.db au format hf, vous devez mettre à niveau SSTable comme décrit dans le reste 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 1.2 de Cassandra.
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 le style sstable 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 de 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, elle 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 effectuer un rollback de la mise à niveau. Après avoir résolu les problèmes de mise à niveau, vous pouvez réessayer de mettre à niveau. (OPDK-1275)

Options de script d'installation raccourcies

Les scripts d'installation n'acceptent plus les options sous leur forme longue, comme --help. Elles n'acceptent désormais que les 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 invites

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

Voici 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 Private Cloud a étendu sa compatibilité avec les systèmes 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)

Compatibilité avec SHA2 pour le hachage des jetons OAuth

Pour mieux protéger les jetons OAuth en cas de faille de sécurité de la base de données, Edge est compatible avec les algorithmes SHA2 pour le hachage des jetons OAuth (en plus de SHA1). Grâce aux nouvelles propriétés au niveau de l'organisation, vous pouvez activer et configurer le hachage pour les nouveaux jetons, et conserver l'ancien hachage sur tous les jetons existant avant cette nouvelle fonctionnalité. Auparavant, dans Edge for 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) permettait le hachage SHA1 automatique des jetons OAuth. Cette propriété est désormais obsolète.

Si vous avez déjà utilisé 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 l'API suivante : https://{host}:{port}/v1/o/{your_org}.

• Pour en savoir plus sur l'activation du hachage de jetons dans votre organisation avec les nouvelles propriétés, consultez la section "Hachage de 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 for Private Cloud. (APIRT-1389)

Structure de répertoire plate pour les fichiers journaux

Vous pouvez configurer Edge pour qu'il stocke les fichiers journaux dans une structure de répertoires 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 règle de journalisation des messages. (APIRT-1394)

Performances du cache de l'environnement

Pour améliorer la gestion et l'utilisation du cache en mémoire, les paramètres "Nombre maximal d'éléments en mémoire" des ressources de cache d'environnement ont été abandonnés. 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, l'allocation de mémoire totale pour la mise en cache en mémoire sur un processeur de messages donné correspond à 40 % de la mémoire totale disponible, déterminée par les paramètres de propriété du cache dans le fichier cache.properties de votre processeur de messages. Les éléments ne seront supprimés du cache en mémoire que si la mémoire cache est insuffisante ou si les éléments expirent.

Pour rétablir l'ancien comportement consistant à utiliser la propriété "Maximum Elements in Memory" (Nombre maximal d'éléments 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

Voici 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'interface utilisateur de gestion. Le nouvel éditeur inclut de nombreuses améliorations de l'ergonomie, y compris des vues plus complètes des flux conditionnels et des points de terminaison sur la page "Présentation", toutes les configurations sur la page "Développer", l'ajout plus intuitif de flux conditionnels, de points de terminaison et de 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 Delete OAuth v2.0 Info

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 la fonctionnalité précédemment fournie par l'API de gestion. Pour en savoir plus, consultez Supprimer la règle d'informations OAuthV2. (MGMT-2257)

Nouvelle règle Delete OAuth v1.0 Info

Une nouvelle règle "Supprimer les informations OAuth v1.0" vous permet de supprimer les jetons de requête, les jetons d'accès et les codes de vérification OAuth v1.0. La règle remplace la fonctionnalité précédemment fournie par l'API de gestion. Pour en savoir plus, consultez 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 l'ajout à la liste d'autorisation et à la liste de blocage 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 Règle de contrôle des accès.

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

La règle Access Entity permet d'accéder aux nouvelles entités suivantes : consumerkey-scopes, authorizationcode, requesttoken et verifier. Pour en savoir plus, consultez Règle d'accès aux entités.

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

Lorsque vous créez une collecte d'analyses personnalisée dans l'éditeur de proxy d'API (page "Développer" > "Outils" > "Collecte d'analyses personnalisée"), le nom de la variable de collecteur (statistique) 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 du collecteur de statistiques. (MGMT-740)

Suppression de la fonctionnalité 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 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'UI 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 sur l'interface utilisateur pendant toute la session de connexion, sauf si vous les aviez ignorés. Avec cette mise à jour, les messages d'erreur sont automatiquement effacés lorsque vous quittez la page sur laquelle ils se sont produits. (MGMT-2254)
• L'UI 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 aspects de l'interface utilisateur de gestion, y compris les performances d'affichage des pages et le nettoyage des messages d'erreur.

Liens vers les rôles sur la page "Utilisateurs de l'organisation" de l'UI de gestion

Sur la page "Utilisateurs de l'organisation" de l'UI de gestion (Admin > Utilisateurs de l'organisation), les noms des rôles sont désormais 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

De nouvelles variables dans les flux de messages fournissent des informations d'URL plus complètes pour les points de terminaison cibles 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 du TargetEndpoint.

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

Edge est compatible avec l'utilisation de l'indication du nom du serveur (SNI) vers le sud (du processeur de messages aux points de terminaison cibles). Si vous souhaitez utiliser SNI, contactez l'assistance Apigee Edge.

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 n'aient à utiliser le même certificat.

Aucune configuration spécifique à Edge n'est requise. Si votre environnement est configuré pour l'extension SNI vers le sud (Edge Cloud l'est par défaut), Edge est compatible.

Edge extrait automatiquement le nom d'hôte de l'URL de la requête et l'ajoute à la requête de handshake 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 l'indication du nom du serveur, consultez http://en.wikipedia.org/wiki/Server_Name_Indication.

"Algorithme de signature" dans les détails des certificats SSL

Un nouveau champ "Algorithme de signature" a été ajouté aux détails du certificat SSL, visible dans l'interface utilisateur de gestion (Admin > Certificats SSL) et l'API de gestion (Obtenir les détails du certificat à partir d'un keystore ou d'un truststore). Le champ affiche "sha1WithRSAEncryption" ou "sha256WithRSAEncryption", selon le type d'algorithme de hachage utilisé pour générer le certificat.

Affichage des certificats SSL arrivant bientôt à expiration

La page "Certificats SSL" de l'interface utilisateur de gestion (Admin > 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 nouveau champ déroulant d'expiration.

Configuration des erreurs de protection contre les menaces

Par défaut, Edge génère un code d'état d'erreur interne du serveur HTTP 500 et une erreur ExecutionFailed si un message ne passe 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 Edge pour définir la propriété de l'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 autres que les règles, telles que TargetEndpoint, ProxyEndpoint, APIProxy et bien d'autres. Voir https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Services pour les développeurs

Voici 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 quelques-unes des mises à jour et nouvelles fonctionnalités :

• Compatibilité avec Swagger 2.0, y compris l'importation par fichier ou URL, et compatibilité avec les objets de sécurité nommés de manière personnalisée.
• Améliorations de la conception visuelle des modèles qui génèrent des SmartDocs.
• Améliorations de la facilité d'utilisation et du workflow dans le portail des développeurs, disponibles via le menu "Contenu" > "SmartDocs" dans Drupal.
• L'authentification par "jeton personnalisé" est désormais appelée "clé API".
• Objets "security" 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 plus de descriptions de fonctionnalités, consultez cet article de blog.

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

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

Les applications de développeur dans Edge ont à la fois un nom interne qui ne change pas et un nom à afficher que vous pouvez modifier. Sur la page "Developer App" (Application de développeur) de l'UI de gestion (Publish > Developer Apps > nom de l'application), le "Name" (Nom) interne de l'application s'affiche avec le "Display Name" (Nom à afficher), ce qui permet d'identifier visuellement plus facilement les applications par leur nom interne pour le dépannage et la gestion des API.

Services d'analyse

Voici les nouvelles fonctionnalités d'Analytics Services incluses dans cette version.

Délai 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 Edge.

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'interface utilisateur 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 offrir de meilleures performances.

Monétisation

Voici les nouvelles fonctionnalités de monétisation incluses dans cette version.

Notifications par e-mail concernant les plans tarifaires

Un nouveau type de notification par e-mail concernant les plans tarifaires vous permet d'informer les développeurs lorsqu'ils atteignent une certaine limite de transactions ou de dollars dans les plans tarifaires par volume ou 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 plan tarifaire, deux périodes différentes pouvaient être en vigueur :

• Période de frais récurrents, configurée dans l'onglet "Frais" d'un plan tarifaire, qui détermine quand les développeurs sont facturés de frais récurrents.
• Période de base d'agrégation, définie dans le tableau des tarifs pour les forfaits par tranches de volume ou groupés, qui détermine quand l'utilisation du forfait est réinitialisée pour les développeurs.

Ces deux périodes sont désormais synchronisées. Lorsqu'un plan tarifaire comporte à la fois des frais récurrents non nuls et un tableau des tarifs par volume ou par lot, la période des frais récurrents est utilisée pour les deux. Par exemple, s'il existe des frais récurrents mensuels, les lots de tableaux des tarifs sont également réinitialisés tous les mois (par défaut, au début du mois).

Si aucun frais récurrent n'existe, les lots sont réinitialisés en fonction de la base d'agrégation définie dans le tableau des tarifs. Par exemple, si un développeur commence à utiliser un tableau des tarifs 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 d'un tableau des tarifs.

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

Les règles d'enregistrement des transactions vous permettent de capturer 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 qui sont ajoutés aux tables de base de données pour être utilisés dans les rapports.

Les clients Apigee Edge pour Private Cloud peuvent définir l'option à l'aide de l'appel d'API suivant et des 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 avez déjà utilisé SmartDocs pendant la période bêta, les nouvelles fonctionnalités de la version en disponibilité générale nécessitent la mise à niveau de SmartDocs dans votre portail des développeurs.

Toutes les pages SmartDocs déjà publiées sur votre portail des développeurs continueront de fonctionner, mais vous devez suivre le processus de mise à jour avant de modifier ou de publier des modifications sur des pages existantes ou nouvelles.

N'oubliez pas que même si vous pouvez afficher et publier des SmartDocs sur votre portail des développeurs, les SmartDocs 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 existent dans tous les environnements Pantheon).

Pour passer de la version bêta de SmartDocs à la disponibilité générale

1. Mettez à jour et testez la version 15.05.27 dans vos environnements de développement ou de test sur Pantheon.
2. Créez un modèle pour remplacer tout modèle d'API existant que vous utilisez.
   • 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 et 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 révision de votre modèle. Sur la page Contenu > SmartDocs > modèle, sélectionnez Paramètres de sécurité.
   
4. Vérifiez l'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 tous les modèles personnalisés pour utiliser la version 6 des éléments CSS et JS, et apportez des modifications pour refléter les nouveaux noms d'objets, tels que authSchemes et apiSchema. Pour en savoir plus sur la mise à jour des modèles SmartDocs, consultez Utiliser SmartDocs pour documenter les API.
6. Effectuez un nouveau rendu de la révision de votre modèle et publiez-la.
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 doutes 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 un aperçu des modifications et améliorations prévues pour les fonctionnalités :

Modification du comportement de la règle ResponseCache

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

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

Comportement futur : l'élément <ExcludeErrorResponse> de la règle ResponseCache sera défini sur "true" par défaut. Cela signifie que, par défaut, seules les réponses avec les codes d'état HTTP 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 actuelle : pour Private Cloud 4.15.07.00 et les versions antérieures, si vous souhaitez mettre en cache les réponses uniquement avec les codes d'état 200 à 205, vous devez définir explicitement l'élément <ExcludeErrorResponse> sur "true".

Corrections de bugs

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