You're viewing **Apigee Edge** documentation.  
[Go to the
**Apigee X** documentation](http://cloud.google.com/apigee/docs). info

On Thursday, October 13, 2016, we began releasing a new version of Apigee Edge for Public
Cloud.

> [!WARNING]
> **Warning:** **Caution:** This release includes updates and bug fixes that may affect your API implementations. As always, we strive to introduce updates that are backwards compatible and don't break your code. However, it's possible that one or more updates may affect the behavior of your solution in places, including workarounds. Using the icon in this note, we've marked specific updates below that you may want to review to ensure your APIs behave as expected.

> [!NOTE]
> **Note:** **Private Cloud customers** : Is this cloud release included in your Private Cloud version? See your version's release notes to see which cloud releases it contains. Also, see [About release
> numbering](https://docs.apigee.com/release/apigee-edge-release-process) to understand how you can figure it out by comparing release numbers.
>
> **Questions or issues?** Contact [Apigee Edge Support](https://docs.apigee.com/api-platform/troubleshoot/support)
>
> **Release notifications** : See [Get Apigee Edge release notifications](https://docs.apigee.com/release/get-release-notifications).
>
> [Release notes home page](https://docs.apigee.com/release/notes/apigee-release-notes)

## New features and updates

Following are the new features and updates in this release.

### Shared
Flows and Flow Hooks to operationalize API proxies (beta-by-request only)

A new "Shared Flows" feature lets you operationalize functionality in API proxies. By
combining conditionalized policies and resources into a Shared Flow, you can reference it from
any API proxy to execute single-source, reusable logic. For example, a Shared Flow might verify
the API key, protect against spike arrests, and log data.

You define Shared Flows in the management UI (**APIs \> Shared Flows**), then
reference them in two different ways:

- With a new Flow Callout policy in an API proxy  
  or
- On a new artifact called Flow Hooks, which are in the following locations:

  - **Request**: Before the ProxyEndpoint PreFlow, after the TargetEndpoint PostFlow
  - **Response**: Before the TargetEndpoint PreFlow, after the ProxyEndpoint PostFlow

  These attachment points let you execute operational logic before or after the main flow
  points of the individual proxy. You assign Shared Flows to these Flow Hook locations in the
  management UI (**APIs \> Environment Configuration \> Flow Hooks**).

### Encrypted key value maps

You can create encrypted key value maps (KVMs) for storing sensitive information such as
credentials or PII/HIPAA data. This feature is different than the existing Edge secure store
(vault) and is designed to supplant it, as vault values can be accessed only with Node.js (in
addition to the management API). You can access encrypted KVM values with Node.js or the Key
Value Map Operations policy.

**Creating encrypted KVMs**

- Use the existing [KVM APIs](https://docs.apigee.com/api-reference/content/keyvalue-maps-management-api). When you include `"encrypted":
  "true"` in the payload definition when creating a KVM, Edge encrypts the KVM and generates an encryption key that has the same scope as the KVM.
- You cannot use the Key Value Map Operations policy to create an encrypted KVM.
- You cannot encrypt an existing unencrypted KVM.

**Using encrypted KVMs**

- Use the Key Value Map Operations policy to get and update encrypted KVM values.
- When getting an encrypted key value, prefix the variable to hold the value with "private." For example: `<Get assignTo="private.secretVar">`. That `private.secretVar` variable holds the decrypted value.
- When updating a value with the policy, you don't need to do anything special. The value will be encrypted automatically in encrypted KVMs.
- You can also access the decrypted value using the apigee-access module in Node.js code. Use the function `getKeyValueMap()` to retrieve a KVM based on the name and scope. Two functions are available on the returned object: `getKeys(callback)` to get an array of key names and `get(key, callback)` to get the value for a particular key. For example:

  ```
  var apigee = require('apigee-access');
    var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy');
    encryptedKVM.get('secret1', function(err, secretValue) {
    // use the secret value here
  });
  ```

(APIRT-1197)

> [!WARNING]
> **Warning:**
>
> ### KVM PUT operations with null keys
>
> If a Key Value Map Operations policy tries to PUT a new key/value in a key value map (KVM) using a null key, the following key is auto-created: `__$$_EDGE_KVM_EMPTY_KEY_$$__`
>
> This situation would happen, for example, if you're populating a key using a variable
> reference and the referenced variable is null. As new PUTs with null keys are attempted, only
> that key is used, so existing values for that key are potentially overwritten each time the
> policy is executed.
>
> The previous behavior for a null key was that the key/value was not added to the KVM.
> Instead, the entry remained in the message processor's in-memory cache and was temporarily
> available for subsequent Get operations. If your KVM policy implementation relies on the
> previous behavior, Get operations on null keys will now fail because they're not referencing
> the new key name (above) that gets created for null keys. (APIRT-3530)

> [!WARNING]
> **Warning:**
>
> ### Validation of policies in FaultRule steps prior to deployment
>
> During API proxy deployment, Edge now validates policies listed in FaultRule steps before deployment. Prior to this fix, deployment succeeded with an HTTP status code of 200 even if policies listed in FaultRule steps didn't exist, and the InvalidPolicyReference error didn't occur until runtime. Now an HTTP status of 400 is returned along with an InvalidPolicyReference error during deployment. If you are using scripts to deploy API proxies, you'll now see deployment failures if FaultRules reference policies that don't exist. (MGMT-3354)

### OpenAPI Spec URLs
included in API proxy metadata

When you create an API proxy based on an OpenAPI Specification, the location of the OpenAPI
Spec is stored in the API proxy metadata. For example, if you use the management API to get the
details of a proxy revision, the metadata includes the path to the OpenAPI Spec in the following
format:

`"spec" :
"https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"`

This enhancement supports the next-generation version of Edge, which links OpenAPI Specs to
API proxies, API products, and API reference docs in the new developer portal. (MGMT-2913)

> [!WARNING]
> **Warning:**
>
> ### New prefix parameter for Node.js getCache()
>
> When getting an Edge cache in Node.js using the apigee-access module's getCache() function, a new prefix parameter lets you specify the cache's prefix (if the cache is configured to use \<CacheKey\>/\<Prefix\>, as described in [Populate Cache
> policy](https://docs.apigee.com/api-platform/reference/policies/populate-cache-policy)). For example:
>
> ```
> var cache = apigee.getCache('Cache1', {resource: 'Cache1', scope: 'global', prefix: 'UserToken__'});
> ```
>
> Previously, if a cache included a cache key prefix, the getCache() function was unable to
> retrieve the cache. (APIRT-3262)

### Client IP control with Sense

In order to more accurately control where to find IP addresses for Sense bot detection when
using routing products such as Akamai, Sense lets you define the location of the client IP with
an `additionalIPVars` variable. For example, you can set `additionalIPVars`
to use the `true-client-ip` header, which contains the correct IP from Akamai to
evaluate in bot rules. (APIRT-3332)

## Bugs fixed

The following bugs are fixed in this release. This list is primarily for users checking to see
if their support tickets have been fixed. It's not designed to provide detailed information for
all users.

| Issue ID | Description |
|---|---|
| APIRT-3507 | **Intermittent errors (such as SNI errors) on JavaScript service callouts** |
| APIRT-3408 | **MP release 160817 apigee-access analytics module processing messages differently** |
| APIRT-3390 | **Change in fault response returned by refresh access token policy** > [!WARNING] > **Warning:** **Change in OAuthV2 error code "invalid_client".** > Note the following change to an error code thrown by the [OAuthV2 policy](https://docs.apigee.com/api-platform/reference/policies/oauthv2-policy) operations > [GenerateAccessToken](https://docs.apigee.com/api-platform/reference/policies/oauth-http-status-code-reference#generateaccesstoken) and [RefreshAccessToken](https://docs.apigee.com/api-platform/reference/policies/oauth-http-status-code-reference#refreshtoken) when > the OAuthV2 policy's **\<GenerateResponse\>** property is set to > **false**: > `{"ErrorCode" : "invalid_client", "Error" :"Client identifier > is required"}` > has been changed to: > `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client > identifier is required"}` > **It is recommended that you change any fault rule conditions that trap > "`invalid_client`" to catch both the old and new codes.** For > example, in your fault rule, change: > `(fault.name = "invalid_client")` > to this: > `(fault.name = "invalid_client") OR (fault.name = > "InvalidClientIdentifier")` |
| APIRT-3389 | > [!WARNING] > **Warning:** **Error uploading Node.js payloads over > 25KB** > Uploading Node.js payloads over 25KB is now allowed. |
| APIRT-3381 | **High latencies on customer production proxies** |
| APIRT-3366 | **Javascript policies are failing on all new Trial organizations** |
| APIRT-3363 | **Invalid URL parsing returns a 500 status with ApplicationNotFound** |
| APIRT-3356 | **OAuth invalid token message** |
| APIRT-3355 | **Intermittent 403 error on OAuth proxy** |
| APIRT-3285 | > [!WARNING] > **Warning:** **Inconsistent OAuth2 token > expiration** > When generating an OAuth token using the OAuth v2.0 policy, you can set the token expiration either by reference or a hard-coded default. For example: `<ExpiresIn > ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. The first time the token expiration was set by reference, Edge stored and used that value for every new token expiration. This bug has been fixed to use either the reference value or, if no reference value is provided, the default expiration defined in the policy. This fix may change the duration of your token expirations, and you may experience side effects such as more invalid token errors, which may require you to implement more frequent token refreshes or change the default expiration in your OAuth policies. |
| APIRT-3261 | **Credentials are validated against another dev app in production** |
| APIRT-3234 | **Node.js app returns NPE** |
| APIRT-3223 | **Apigee stale cache issue** |
| APIRT-3193 | **Node.js target server is hanging after move to ASG** |
| APIRT-3152 | **cachedlogs management call causes log messages to be broken up** |
| APIRT-3117 | **MP reached 100% CPU utilization and stopped serving traffic** |
| APIRT-3064 | **Router - custom 503 error message from router** |
| APIRT-2620 | **Separate thread pool for some blocking steps to improve load handling** |
| CORESERV-774 | **Access using valid key with invalid apiproduct reference causes internal server error** |