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

Vers quelles versions d'Edge pouvez-vous effectuer la mise à niveau ? 4.15.07.00

Selon votre version actuelle d'Edge, vous pouvez :

• Mise à niveau directe vers la version 4.15.07.00
• Mettez à niveau de manière incrémentielle. Cela 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 sont les versions d'Edge pour le cloud privé vers lesquelles vous pouvez migrer ? 4.15.07.00.

Avant de mettre à niveau à partir de la version 4.15.01.x ou d'une version antérieure

1. Vérifiez la version SSTable de Cassandra :
   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 cette commande find :
      > 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 n'apparaît, vous avez terminé et vous 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 que tous les fichiers *.db ont é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 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. Après avoir résolu les éventuels problèmes de mise à niveau, vous pouvez réessayer. (OPDK-1275)

Options du script d'installation abrégé

Les scripts d'installation n'acceptent plus les options au format long, telles que "--help". Ils 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

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

OpenJDK 1.7 compatible avec Edge pour le cloud privé

Cette version d'Edge est compatible avec Oracle JDK 1.7 et OpenJDK 7, mais plus 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)

Compatibilité avec 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 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, tout en conservant l'ancien hachage pour 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) permettait le hachage SHA1 automatique des jetons OAuth. Cette propriété est désormais obsolète.

Si vous avez précédemment 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 vous. Pour vérifier 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 à l'aide des nouvelles propriétés, consultez la section "Hacher les 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 simple pour les fichiers journaux

Vous pouvez configurer Edge pour stocker les fichiers journaux dans une structure de répertoire à plat 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 MessageLogging. (APIRT-1394)

Performances du cache d'environnement

Pour une meilleure gestion et 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, la mémoire totale allouée à 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 sont supprimés du cache en mémoire que lorsque la mémoire cache est insuffisante ou que les éléments expirent.

Pour revenir à l'ancien comportement d'utilisation de la propriété "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

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'interface utilisateur de gestion. Le nouvel éditeur inclut de nombreuses améliorations en termes d'usabilité, y compris des vues plus complètes des flux conditionnels et des points de terminaison sur la page "Présentation", toute la configuration 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 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. Cette règle remplace la fonctionnalité précédemment fournie par l'API de gestion. Pour en savoir plus, consultez 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, les jetons d'accès et les codes de validation OAuth v1.0. Cette 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 d'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.

Si la vérification de plusieurs adresses IP est activée dans l'en-tête (contactez l'assistance pour définir feature.enableMultipleXForwardCheckForACL), un nouvel élément <ValidateBasedOn> dans 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 Règle de contrôle des accès.

Nouvelles entités dans la règle AccessEntity

La règle "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 collecte de données analytiques personnalisée dans l'éditeur de proxy d'API (page "Développer" > Outils > Collecte de données analytiques personnalisée), le nom de la variable (statistique) du collecteur doit être en minuscules. Si vous saisissez le nom en majuscules, l'outil le convertit automatiquement 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 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'UI de gestion :

• L'interface utilisateur de gestion permet de regrouper et d'afficher tous les messages d'erreur de l'interface utilisateur pour l'ensemble de la session de connexion, sauf si vous les avez fermés. Avec cette mise à jour, les messages d'erreur sont effacés automatiquement 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'UI

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

Hyperliens vers les rôles sur la page "Utilisateurs de l'organisation" de l'interface utilisateur de gestion

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

Nouvelles variables cibles dans le flux de messages

De nouvelles variables dans les flux de messages fournissent des informations plus complètes sur les URL pour les points de terminaison cibles et les serveurs cibles :

• TargetEndpoint : request.url remplace target.basepath.with.query.
• Remplacement de targetserver.name par loadbalancing.targetserver pour TargetServer. 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 est compatible avec l'utilisation de l'indication du nom du serveur en direction du backend (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 aient besoin d'utiliser le même certificat.

Aucune configuration spécifique à Edge n'est requise. Si votre environnement est configuré pour le SNI en aval (le cloud Edge l'est par défaut), 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 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 SNI, consultez http://en.wikipedia.org/wiki/Server_Name_Indication.

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

Un champ "Algorithme de signature" a été ajouté aux détails du certificat SSL. Il est visible dans l'interface utilisateur de gestion (Admin > Certificats SSL) et dans 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.

Afficher les certificats SSL qui expirent bientôt

La page "Certificats SSL" de l'interface utilisateur de gestion (Admin > Certificats SSL) indique quand les certificats SSL expirent dans 10, 15, 30 ou 90 jours, selon 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 HTTP 500 indiquant une erreur interne du serveur et une 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 Edge 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.

Schémas mis à jour 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 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 :

• Prise en charge de Swagger 2.0, y compris l'importation par fichier ou URL, et prise en charge des objets de sécurité personnalisés.
• Améliorations de la conception visuelle dans les modèles qui génèrent 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 "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 en savoir plus sur les fonctionnalités, consultez cet article de blog.

Pour la documentation SmartDocs, consultez Utiliser SmartDocs pour documenter les API.

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

Dans Edge, les applications pour les développeurs ont un nom interne qui ne change pas et un nom à afficher que vous pouvez modifier. Sur la page d'une application de développeur dans l'interface utilisateur de gestion (Publier > Applications de développeur > nom de l'application), le "Nom" interne de l'application est affiché avec le "Nom à afficher". Il est ainsi plus facile d'identifier visuellement 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.

Délai de conservation des données

Lorsque vous générez des rapports d'analyse avec l'interface utilisateur 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'UI de gestion.

Performances du widget "Engagement des développeurs"

Le widget d'entonnoir du tableau de bord principal des données analytiques (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 sur les plans tarifaires vous permet d'informer les développeurs lorsqu'ils atteignent une certaine limite de transactions ou de montant dans les plans tarifaires groupés ou à bandes de volume 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 pouvaient être en vigueur :

• Période de frais récurrents, configurée dans l'onglet "Frais" d'un plan tarifaire, qui détermine la date à laquelle les développeurs sont facturés pour des frais récurrents.
• Période de base de l'agrégation, définie sur la fiche tarifaire des forfaits à bandes de volume ou groupés, qui déterminait quand l'utilisation des forfaits était réinitialisée pour les développeurs.

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

S'il n'existe pas de frais récurrents, les forfaits sont réinitialisés en fonction de la base d'agrégation définie dans la grille tarifaire. Par exemple, si un développeur commence à utiliser un tarif le 19 du mois et que la base d'agrégation est mensuelle, l'utilisation du forfait 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 forfait de la grille tarifaire.

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 (facultatif). 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 pour le cloud privé 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 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 que vous mettiez à niveau SmartDocs dans votre portail de développeur.

Toutes les pages SmartDocs déjà publiées dans votre portail des développeurs continueront de fonctionner, mais vous devez suivre la procédure 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 documents 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 d'API Edge d'Apigee. Toutes les modifications que vous apportez à un modèle d'API dans Edge sont les mêmes dans tous vos environnements Pantheon (comme les développeurs dans les environnements Pantheon).

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

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 avez utilisé.
   • 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 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 tous les modèles personnalisés pour utiliser 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 les modèles SmartDocs, consultez Utiliser SmartDocs pour documenter les API.
6. Rendez à nouveau votre révision de 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 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 un aperçu des modifications et améliorations prévues pour les fonctionnalités :

Modification du comportement de la règle de réponse du cache

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 "Cache de réponse".

Comportement futur : l'élément <ExcludeErrorResponse> de la règle de mise en cache des réponses sera défini sur "true" par défaut. 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 devrez 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 les réponses uniquement avec les codes d'état 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