You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info
On Wednesday, January 29, 2014, we released a new on-premises version of Apigee Edge.
If you have questions, go to Apigee Customer Support.
This release contains features and bug fixes from the following cloud releases:
New features and enhancements
- OAuth 2.0 update custom attributes on tokens
A new "Set OAuth v2.0 Info" policy lets you update custom attributes on OAuth 2.0 tokens.
OAuth 1.0a policy updates
This release includes the following updates to the OAuth 1.0a policy:
- As with OAuth 2.0 tokens, you can now set custom attributes on OAuth 1.0a tokens.
- A new GenerateVerifier operation lets you generate and return an OAuth 1.0a verifier (similar to an authorization code in OAuth 2.0).
- SSL info in flow variables
Apigee Edge now lets you propagate and access SSL information in flow variables. By setting a new "propagate.additional.ssl.headers" property on a ProxyEndpoint, you have access to the same SSL information available on an Apache web server.
- JMS headers as HTTP headers
All JMS headers are now propagated as HTTP headers for downstream processing.
- Node.js module update
Apigee’s built-in Node.js module has been updated to include the following modules: 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.
Custom roles in the management UI - BETA
In addition to the existing user roles of “Business User”, “Operations Administrator”, “Organization Administrator”, and “User”, this release includes a beta feature that lets you create custom roles in the management UI. You can control access to various Edge features using custom roles.
- Advanced API Services (formerly App Services) installer
Apigee Edge Advanced API Services (formerly App Services) is now available for use on premises. The existing Edge installer lets you deploy and configure Advanced API Services in your own on-premises environment.
- Developer Services monetization (formerly Monetization Services)
Monetization capability is part of Edge Developer Services. The Edge on-premises installer now includes an enhanced, integrated monetization installer. Monetization requires an additional paid license.
- Multiple message processors on a single host - silent installation
This enhancement supports the deployment toplology of multiple message processors installed on a single host, which requires binding each message processor to a specific IP address. You can now add a
BIND_ON_ALL_INTERFACES=nproperty setting in the silent installation config file, which makes a message processor listen to a specific IP address, specified by the
HOSTIPproperty in the same file. For more information about this property, and about configuring silent installation, see the Apigee On-premises Deployment Kit Install and Configuration Guide.
This release includes various updates to Apigee’s JMS support, including:
- All JMS headers are now propagated as HTTP headers for downstream processing.
- You can now specify ExpiryTime and DeliveryMode for the messages placed in ResponseQueue used by the JMS proxy. All HTTP headers matching standard JMS headers are set “as is”, and other HTTP headers are set as JMS properties in the response message used by the JMS proxy.
|Custom role permissions
|Permissions set using custom roles now work as expected.
|API latency analytics
|In an API proxy flow, when a call to the target system results in a timeout (such as an HTTP read timeout), the target latency times included in the API analytics.
|“type” attribute on policies
|The “type” attribute now functions correctly in all Apigee policies.
|OAuth 2.0 invalidating tokens
|The invalidating tokens functionality for Apigee OAuth 2.0 policies now matches the OAuth spec. You are no longer required to provide a “type” when setting the “token” parameter.
|RBAC with key/value maps
|Role-based access control now works for key/value maps created at the environment level.
|OAuth 1.0a policy response format
|When making requests to an API with an OAuth 1.0a policy, the response is now returned in the format of the Accept header.
|HTTP 1.0 request,
HTTP 1.1 response
This issue involves a scenario where a client sends a request using HTTP 1.0 with the
content-length property in the header, but the backend
service is configured to use HTTP 1.1 and returns
transfer-encoding property for chunked encoding instead.
To successfully handle this scenario, you can remove the
transfer-encoding property from the HTTP 1.1 response using
the AssignMessage policy. In the following policy, which would be attached to the API
proxy response flow, the
transfer-encoding property is removed
from the HTTP header, which allows the client to receive the response un-chunked.
<AssignTo createNew="false" type="response"></AssignTo>