Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.
Le mercredi 29 janvier 2014, nous avons lancé une nouvelle version sur site d'Apigee Edge.
Pour toute question, contactez l'assistance Apigee Edge.
Cette version contient des fonctionnalités et des corrections de bugs des versions cloud suivantes :
Nouvelles fonctionnalités et améliorations
- Mise à jour des attributs personnalisés des jetons OAuth 2.0
Une nouvelle règle "Set OAuth v2.0 Info" vous permet de mettre à jour les attributs personnalisés des jetons OAuth 2.0.
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info
-
Mises à jour des règles OAuth 1.0a
Cette version inclut les mises à jour suivantes des règles OAuth 1.0a :- Comme pour les jetons OAuth 2.0, vous pouvez désormais définir des attributs personnalisés sur les jetons OAuth 1.0a.
- Une nouvelle opération GenerateVerifier vous permet de générer et de renvoyer un vérificateur OAuth 1.0a (semblable à un code d'autorisation dans OAuth 2.0).
- Informations SSL dans les variables de flux
Apigee Edge vous permet désormais de propager et d'accéder aux informations SSL dans les variables de flux. En définissant une nouvelle propriété "propagate.additional.ssl.headers" sur un ProxyEndpoint, vous avez accès aux mêmes informations SSL que celles disponibles sur un serveur Web Apache.
http://apigee.com/docs/api-services/api/variables-reference
- En-têtes JMS en tant qu'en-têtes HTTP
Tous les en-têtes JMS sont désormais propagés en tant qu'en-têtes HTTP pour le traitement en aval.
- Mise à jour du module Node.js
Le module Node.js intégré d'Apigee a été mis à jour pour inclure les modules suivants : argo 0.4.9, async 0.2.9, express 3.4.8, underscore 1.5.2, usergrid 0.10.7, volos-cache-memory 0.0.3, volos-oauth-apigee 0.0.2, volos-quota-apigee 0.0.2.
-
Rôles personnalisés dans l'interface utilisateur de gestion (BÊTA)
En plus des rôles utilisateur existants ("Utilisateur professionnel", "Administrateur des opérations", "Administrateur de l'organisation" et "Utilisateur"), cette version inclut une fonctionnalité bêta qui vous permet de créer des rôles personnalisés dans l'interface utilisateur de gestion. Vous pouvez contrôler l'accès à diverses fonctionnalités Edge à l'aide de rôles personnalisés. - Programme d'installation des services d'API avancés (anciennement App Services)
Les services d'API avancés (anciennement App Services) d'Apigee Edge sont désormais disponibles pour une utilisation sur site. Le programme d'installation Edge existant vous permet de déployer et de configurer les services d'API avancés dans votre propre environnement sur site.
- Programme d'installation des services de développement pour la monétisation (anciennement Services de monétisation)
La fonctionnalité de monétisation fait partie des services de développement Edge. Le programme d'installation Edge sur site inclut désormais un programme d'installation de la monétisation amélioré et intégré. La monétisation nécessite une licence payante supplémentaire.
- Plusieurs processeurs de messages sur un même hôte : installation silencieuse
Cette amélioration est compatible avec la topologie de déploiement de plusieurs processeurs de messages installés sur un même hôte, ce qui nécessite de lier chaque processeur de messages à une adresse IP spécifique. Vous pouvez désormais ajouter un paramètre de propriétéBIND_ON_ALL_INTERFACES=ndans le fichier de configuration de l'installation silencieuse, ce qui permet à un processeur de messages d'écouter une adresse IP spécifique, spécifiée par la propriétéHOSTIPdans le même fichier. Pour en savoir plus sur cette propriété et sur la configuration de l'installation silencieuse, consultez le Guide d'installation et de configuration du kit de déploiement Apigee On-Premises.
-
Mises à jour JMS
Cette version inclut diverses mises à jour de la compatibilité JMS d'Apigee, y compris :- Tous les en-têtes JMS sont désormais propagés en tant qu'en-têtes HTTP pour le traitement en aval.
- Vous pouvez désormais spécifier ExpiryTime et DeliveryMode pour les messages placés dans ResponseQueue utilisés par le proxy JMS. Tous les en-têtes HTTP correspondant aux en-têtes JMS standards sont définis "tels quels", et les autres en-têtes HTTP sont définis en tant que propriétés JMS dans le message de réponse utilisé par le proxy JMS.
Bugs résolus
| Sujet | Description |
|---|---|
| Autorisations des rôles personnalisés | Les autorisations définies à l'aide de rôles personnalisés fonctionnent désormais comme prévu. |
| Analyse de la latence des API | Dans un flux de proxy d'API, lorsqu'un appel au système cible entraîne un délai avant expiration (tel qu'un délai avant expiration de lecture HTTP), les temps de latence cible sont inclus dans les analyses d'API. |
| Attribut "type" sur les règles | L'attribut "type" fonctionne désormais correctement dans toutes les règles Apigee. |
| Invalider des jetons OAuth 2.0 | La fonctionnalité d'invalidation des jetons pour les règles OAuth 2.0 d'Apigee correspond désormais à la spécification OAuth. Vous n'avez plus besoin de fournir de "type" lorsque vous définissez le paramètre "token". |
| RBAC avec des mappages clé-valeur | Le contrôle des accès basé sur les rôles fonctionne désormais pour les mappages clé/valeur créés au niveau de l'environnement. |
| Format de réponse des règles OAuth 1.0a | Lorsque vous envoyez des requêtes à une API avec une règle OAuth 1.0a, la réponse est désormais renvoyée au format de l'en-tête Accept. |
Problèmes connus
| Sujet | Description |
|---|---|
| Requête HTTP 1.0, Réponse HTTP 1.1 |
Ce problème se produit lorsqu'un client envoie une requête à l'aide de HTTP 1.0 avec la propriété
content-length dans l'en-tête, mais que le service de backend est configuré pour utiliser HTTP 1.1 et renvoie une propriété transfer-encoding pour l'encodage par blocs.
Pour gérer correctement ce scénario, vous pouvez supprimer la propriété
transfer-encoding de la réponse HTTP 1.1 à l'aide de la règle AssignMessage. Dans la règle suivante, qui serait associée au flux de réponse du proxy d'API, la propriété transfer-encoding est supprimée de l'en-tête HTTP, ce qui permet au client de recevoir la réponse sans segmentation.
<AssignMessage name="RemoveChunkedEncoding">
<AssignTo createNew="false" type="response"></AssignTo>
<Remove>
<Headers>
<Header name="Transfer-Encoding"/>
<Header name="transfer-encoding"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>
|