- Apigee Edge on-premises release notes

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation.

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) installer
    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=n property setting in the silent installation config file, which makes a message processor listen to a specific IP address, specified by the HOSTIP property 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.
  • JMS updates
    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.

Bugs fixed

Topic Description
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.

Known issues

Topic Description
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 a 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.
<AssignMessage name="RemoveChunkedEncoding">
<AssignTo createNew="false" type="response"></AssignTo>
<Header name="Transfer-Encoding"/>
<Header name="transfer-encoding"/>