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

On Wednesday, January 25, 2017, we released a new version of Apigee Edge for Private
Cloud.

> [!NOTE]
> **Note:** **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)

Since the previous Edge for Private Cloud Feature Release, the following releases have
occurred and are included in this Feature Release:

- Cloud: [16.08.24.01 (UI)](https://docs.apigee.com/release/notes/160824-ui-apigee-edge-public-cloud-release-notes), [16.10.05
  (UI)](https://docs.apigee.com/release/notes/161005-ui-apigee-edge-public-cloud-release-notes), [16.09.21](https://docs.apigee.com/release/notes/160921-apigee-edge-public-cloud-release-notes), [16.09.21_9](https://docs.apigee.com/release/notes/1609219-apigee-edge-public-cloud-release-notes), [16.10.26 (UI)](https://docs.apigee.com/release/notes/161026-ui-apigee-edge-public-cloud-release-notes)

See [About release
numbering](https://docs.apigee.com/release/apigee-edge-release-process) to understand how you can figure out whether a specific cloud release is
included in your version of Edge for Private 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.

## Release overview

This release includes a number notable features that help you better control and secure your
APIs.

Shared Flows and Flow Hooks let you create a reusable set of policies and behaviors across
multiple API proxies.

Key value maps (KVMs), which were already an Edge feature for long-term persistence of
key-value pairs, can now be encrypted for stronger data security.

For more flexible control over developer access to your APIs, the Edge management UI provides
more options for creating and managing API keys and secrets (credentials), revoking developer
apps, and deactivating developers. These enhancements let you more easily implement strategies
such as API key rotation and let you disable multiple API keys by revoking a developer app (all
its keys are disabled) or deactivating a developer (all of the developer's apps and keys
are disabled).

On the deprecation front, the Monetization Limits feature was retired.

The remainder of this topic contains details on all the new features, updates, and bug fixes
contained in the release.

## Deprecations and retirements

The following features were deprecated or retired in this release. See the [Edge deprecation policy](https://docs.apigee.com/release/deprecation) for more information.

### Retired: Monetization
Limits (Cloud 16.10.26 UI)

The monetization Limits feature has been removed from the management UI (**Admin \>
Limits** ). See the deprecation notice for more details, including what to use instead:
[http://docs.apigee.com/monetization/content/limit-feature-deprecation-notice](https://docs.apigee.com/api-platform/monetization/limit-feature-deprecation-notice).
(DEVRT-3259)

### Support for
RedHat/CentOS version 6.5 removed

If you are currently using RedHat/CentOS version 6.5, you must update your operating
system to version 6.6 or later before you update to Edge 4.17.01.

## New features and updates

Following are the new features and enhancements in this release. In addition to the following
enhancements, this release also contains multiple usability, performance, security, and stability
enhancements.

For further details and instructions, see the Edge for Private Cloud documentation.

### Private Cloud

#### Can now display a consent banner on the Edge UI

You can display a consent banner when a user first accesses the Edge UI. The consent banner
displays HTML-formatted text and a button that the user selects to proceed to the log in screen.
See [Enabling the consent
banner](https://docs.apigee.com/private-cloud/v4.17.01/enabling-consent-banner) for more.

#### API BaaS supports multiple data centers

You can now install API BaaS in multiple data centers.
See [Multiple Data Center
Installation for API BaaS](https://docs.apigee.com/private-cloud/v4.17.01/multiple-data-center-installation-api-baas) for more.

#### New API BaaS installation configuration parameters

Two new configuration parameters have been added to the API BaaS configuration file:

- BAAS_CASS_DC_LIST - specifies the region names of the BaaS data centers. For a single data center, specify the same value as BAAS_CASS_LOCALDC.
- BAAS_CLUSTER_SEEDS - specifies the BaaS Stack nodes used to define the seeds of the BaaS cluster.

See [Update Apigee Edge 4.16.09
to 4.17.01](https://docs.apigee.com/private-cloud/v4.17.01/update-apigee-edge-41701) for more.

#### No longer run "deploy" option with apigee-service command for API BaaS

The deploy option for
the apigee-service command
is no longer supported for API BaaS Stack and Portal. Instead, you use the configure and restart options.
See [API BaaS Installation](https://docs.apigee.com/private-cloud/v4.17.01/api-baas-installation)
for more.

#### New port requirement for API BaaS

All BaaS Stack nodes must now open port 2551 for access from all other Stack nodes. If you
have multiple BaaS Data Centers, the port must be accessible from all Stack nodes in all Data
Centers.

See [API BaaS Installation](https://docs.apigee.com/private-cloud/v4.17.01/api-baas-installation) and
[Installation Requirements](https://docs.apigee.com/private-cloud/v4.17.01/installation-requirements)
for more.

#### Developer Services portal now uses Postgres as its database and Nginx as its web server

For all new installations, the portal uses Postgres as its database instead of MySQL and
MariaDB. Customers upgrading to 4.17.01 from a previous version continue to use MySQL or
MariaDB.

New installations for 4.17.01 also install Nginx as the web server. Customers upgrading to
4.17.01 from a previous version continue to use Apache.

#### Developer Services portal no longer enables SmartDocs by default

You must enable SmartDocs on the portal. For more information on SmartDocs, see [Using SmartDocs to document
APIs](https://docs.apigee.com/api-platform/publish/drupal/using-smartdocs-document-apis).

#### Developer Services portal now installed from RPMs

The 4.17.01 version of the Developer Services portal is installed from RPMs using the same
repo and tools as Edge and API BaaS. See [Developer Services portal
installation](https://docs.apigee.com/private-cloud/v4.17.01/developer-services-portal-installation) for more.

> [!NOTE]
> **Note:** Upgrades from a previous version of the portal use a .tar file to perform the upgrade. All upgrades continue to use Apache as the web server, and either MySQL or MariaDB, depending on what is currently installed.

The RPM-based install and the .tar-based updater use different components:

|   | **RPM-based install** | **.tar-based install** |
|---|---|---|
| **Web server** | Nginx | Apache |
| **Web root** | /opt/apigee/apigee-drupal | /var/www/html |
| **Port** | 8079 | 80 |
| **Database** | PostgreSQL | MySQL |
| **PHP** | php-fpm (FastCGI) | mod_php (in-process with Apache) |

#### Qpid upgraded to version 1.35

This release includes Qpid version 1.35.

#### Cassandra upgraded to version 2.1.16

This release includes Cassandra version 2.1.16.

#### Play upgraded to version 2.4

This release includes the Play 2.4 UI framework.

#### Support for RedHat/CentOS version 7.3 added

Edge now supports RedHat/CentOS version 7.3.

#### Updates to Beta Monitoring Dashboard

The Beta version of the Edge Monitoring Dashboard has been updated to:

- Include new dashboards for Cassandra, Zookeeper, OpenLDAP, Postgres, and Qpid.
- Upgraded Influx version in 4.16.09 from 0.11 to 1.0.2.
- Added a number of stability fixes.

See [Apigee
Monitoring Dashboard Beta Overview](https://docs.apigee.com/private-cloud/v4.17.01/apigee-monitoring-dashboard-beta-overview) for more.

#### Can now set Postgres password in installation config file

Use the PG_PWD property
to set the Postgres password in the installation config file.
See [Edge Configuration File
Reference](https://docs.apigee.com/private-cloud/v4.17.01/edge-configuration-file-reference) for more.

#### Enable EPEL repo

You must enable [Extra Packages for
Enterprise Linux (or EPEL)](https://fedoraproject.org/wiki/EPEL) to install or update Edge.
See [Installation Requirements](https://docs.apigee.com/private-cloud/v4.17.01/installation-requirements) for
more.

The command you use depends on your version of RedHat/CentOS:

- For RedHat/CentOS 7.x:  
  \> wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; rpm -ivh epel-release-latest-7.noarch.rpm
- For RedHat/CentOS 6.x:  
  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm; rpm -ivh epel-release-latest-6.noarch.rpm

#### Disable DNS lookup on IPv6 when using NSCD (Name Service Cache Daemon)

If you have installed and enabled NSCD (Name Service Cache Daemon) the Message Processors
makes two DNS lookups: one for IPv4 and one for IPv6. You must disable DNS lookup on IPv6 when
using NSCD. See [Installation Requirements](https://docs.apigee.com/private-cloud/v4.17.01/installation-requirements)
for more.

To disable the DNS lookup on IPv6:

1. On every Message Processor node, edit /etc/nscd.conf.
2. Set the following property:  
   enable-cache hosts no

### API Services

#### Shared Flows and Flow Hooks to operationalize API proxies (Cloud 16.09.21)

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:

  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**).
  - **Request**: Before the ProxyEndpoint PreFlow, after the TargetEndpoint PostFlow
  - **Response**: Before the TargetEndpoint PreFlow, after the ProxyEndpoint PostFlow

For more information, see [Reusable
shared flows](https://docs.apigee.com/api-platform/fundamentals/shared-flows) and [Attaching a shared flow
using a flow hook](https://docs.apigee.com/api-platform/fundamentals/flow-hooks).

#### Encrypted key value maps (Cloud 16.09.21)

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 management 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 generates an encryption key that has the same scope as the KVM and encrypts the KVM using that key.
- You cannot use the Key Value Map Operations policy to create an encrypted KVM. You have to create an encrypted KVM using the KVM management APIs before using it in the policy.
- 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 the keyword "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, the following gets an `apiproxy`-scoped KVM called `VerySecureKVM` and retrieves the encrypted value of `key1`:

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

> [!NOTE]
> **Note:** Encrypted KVMs are supported in Edge for Private Cloud version 4.17.01 and later. However, support for encrypted KVMs in the Edge UI is disabled by default. To enable the Edge UI to support encrypted KVMs, see [Creating and editing
> environment key value maps](https://docs.apigee.com/api-platform/cache/creating-and-editing-environment-keyvalue-maps).

For more information, see [Working with key
value maps](https://docs.apigee.com/api-platform/cache/key-value-maps) and [Accessing
key value maps in Node.js](https://docs.apigee.com/api-platform/nodejs/accessing-key-value-maps-nodejs).

(APIRT-1197)

#### Create encrypted key value maps in the UI (16.10.26 UI)

When creating an environment-scoped key value map (KVM) in the management UI (**APIs
\> Environment Configuration \> Key Value Maps** ), a
new **Encrypted** checkbox lets you create an encrypted KVM. After you add
keys to the KVM, the encrypted values appear in the management UI as asterisks (\*\*\*\*\*). You add
keys/values to an encrypted KVM exactly as you do for non-encrypted KVMs. Full backend support
for encrypted KVMs was available in cloud release [160921](https://docs.apigee.com/release/notes/160921-apigee-edge-public-cloud-release-notes). (EDGEUI-764)

> [!WARNING]
> **Warning:**
>
> #### KVM PUT operations with null keys (Cloud 16.09.21)
>
> 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 and DefaultFaultRule steps prior to deployment (Cloud
> 16.09.21)
>
> During API proxy deployment, Edge now validates policies listed in FaultRule and DefaultFaultRule steps before deployment. Prior to this fix, deployment succeeded with an HTTP status code of 200 even if policies listed in FaultRule or DefaultFaultRule 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 or the DefaultFaultRule references policies that don't exist. (MGMT-3354)

#### OpenAPI Spec URLs included in API proxy metadata (Cloud 16.09.21)

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() (Cloud 16.09.21)
>
> 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)

#### OpenAPI Spec generation for SOAP proxies (Cloud 16.10.05 UI)

When you create a "REST to SOAP to REST" proxy based on a WSDL, Edge automatically generates a
hosted OpenAPI Spec based on the proxy resources. You can access the spec at
`http(s)://[edge_domain]/[proxy_base_path]/openapi.json`. However, the conversion is
not always accurate, since not all the rules of an XML schema can be represented in an OpenAPI
Spec. (EDGEUI-718)

#### Edge-hosted WSDL for passthrough SOAP proxies (Cloud 16.10.05 UI)

When you create a "Pass-Through SOAP" proxy based on a WSDL, Edge hosts the WSDL and creates a
flow in the proxy to let you access it. You can access the hosted WSDL at
`http(s)://[edge_domain]/[proxy_base_path]?wsdl`, which is the new service endpoint
URL for clients calling the SOAP service through the proxy. (EDGEUI-718)

#### New sample stock quote WSDL in API proxy wizard (Cloud 16.08.24.01)

When creating a SOAP service API with the API proxy wizard, a replacement stock quote WSDL is
available in the examples: https://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?WSDL.
(EDGEUI-655)

### Developer Services

#### Developer app management goodness in the UI (Cloud 16.10.05 UI)

Developer app management in the Edge UI has gotten more powerful with a number of
enhancements:

- You can revoke and approve apps (in edit mode) in a new "App Status" field. In view mode, the field also displays the current app status. If an app is revoked, none of its API keys are valid for API calls. They keys themselves aren't revoked and are available again for use if the developer is re-approved. The "Approved" label for API keys is displayed in strikethrough text while an app is in a revoked state.
- API key expiry dates are now shown on the Developer App Details page, and keys are organized by expiry dates in a "Credentials" section. For example, a key with no expiration is shown in one group with its associated API products, and a key that expires in 90 days is shown in another group with its associated products. You can't change the expiration of an existing credential.
- With a new add Credential button in Developer App edit mode, you can generate API keys with specific expiration times or dates (or no expiration). As (or after) you create a credential, you can add API products to it.  
  This functionality replaces the "Regenerate Key" button on the Developer App Details page. That button has been removed.

These enhancements add features in the UI that were already available in the management API.
(EDGEUI-104)

#### Activate/Deactivate app developer in the UI (Cloud 16.10.05 UI)

You can change the status of an app developer between active and inactive in the Edge UI
(Developer Details page, edit mode, Activate/Deactivate button). When a developer is inactive,
none of her developer app API keys or OAuth tokens generated with those keys are valid in calls
to API proxies. (EDGEUI-304)

#### Inactive developer indicators in the UI (16.10.26 UI)

When an app developer is set to "Inactive," the developer's apps and credentials are no longer
valid even though they remain in an "Approved" state. Now when viewing an inactive developer's
apps and credentials in the management UI, the "Approved" status label on apps and credentials is
displayed in strikethrough text, and a mouseover tooltip on the label indicates that the
developer is inactive. If the developer is restored to "Active," her approved apps and
credentials are once again valid, and the strikethrough text on the "Approved" label is removed.
(EDGEUI-728)

### Analytics Services

#### Renamed "Error Code Analysis" dashboard (16.10.26 UI)

The "Error Analysis" dashboard has been renamed to "Error Code Analysis." The dashboard
includes API calls with HTTP status codes of 4xx and 5xx. (EDGEUI-738)

#### TPS data on proxy dashboards (16.10.26 UI)

Data for average transactions per second ("Average TPS") has been added to the main Proxy
Traffic dashboard. In addition, when you hover over individual data points on the Proxy Traffic
and Proxy Performance charts, TPS for that time interval is displayed in the tooltip.
(EDGEUI-668)

#### Analytics error display (16.10.26 UI)

When an analytics dashboard received a 500 error, the management UI displayed "Report timed
out" regardless of the error. To provide better troubleshooting capabilities, the UI now displays
the actual error. (EDGEUI-753)

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

### Edge for Private Cloud 4.17.01

| Issue ID | Description |
|---|---|
| APIBAAS-1990 | **API BaaS Stack no longer tries to authenticate to SMTP when smtp.auth is false** |
| APIRT-3032 | **Running the "apigee-service baas-usergrid restart" command now also runs "configure"** You no longer have to run "apigee-service baas-usergrid configure" followed by "apigee-service baas-usergrid restart" for the BaaS Stack. |
| APIRT-3032 | **Do not perform DNS lookup if the host name is an IP address.** |
| DOS-4070 | **"apigee-all -version" now shows version of edge-mint-\* RPMs** |
| DOS-4359 | **Added "pdb" option to install Postgres database only.** Used only when installing the Developer Services portal. See [Developer Services portal installation](https://docs.apigee.com/private-cloud/v4.17.01/developer-services-portal-installation). |

### Cloud 16.10.26 (UI)

| Issue ID | Description |
|---|---|
| EDGEUI-768 | **Proxy creation with StockQuote WSDL is failing** |

### Cloud 16.09.21_9

| Issue ID | Description |
|---|---|
| MGMT-3674 | **Unable to create encrypted KVM or Vaults for HIPAA-enabled orgs** |
| MGMT-3647 | **Userrole access for users with Capitalized email throws 403** |

### Cloud 16.09.21

| 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): > `{"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** |

### Cloud 16.10.05 (UI)

| Issue ID | Description |
|---|---|
| EDGEUI-697 | **Reports page export button** The Export button has been removed from the Custom Reports home page. Report export is available on each custom reports page. |

### Cloud 16.08.24.01

| Issue ID | Description |
|---|---|
| EDGEUI-663 | **Proxy generated for WeatherHttpGet port of Weather.wsdl fails at runtime with 500 error** When generating an API proxy for a SOAP service, WSDL ports without a SOAP protocol binding are no longer visible in the API proxy wizard. This is by design, as the wizard only generates SOAP requests. |
| EDGEUI-658 | **SOAP WSDL passthrough operation name issue** |
| EDGEUI-653 | **Error in creating node.js API Proxy when Enable Cors option is selected** |
| EDGEUI-648 | **Calls From the UI that take between 2 and 3 minutes time out** |
| EDGEUI-623 | **Organization history Change date button does not work on Firefox** |